draft-ietf-roll-urban-routing-reqs-05.txt   rfc5548.txt 
Networking Working Group M. Dohler, Ed. Network Working Group M. Dohler, Ed.
Internet-Draft CTTC Request for Comments: 5548 CTTC
Intended status: Informational T. Watteyne, Ed. Category: Informational T. Watteyne, Ed.
Expires: October 1, 2009 CITI-Lab, INRIA A4RES BSAC, UC Berkeley
T. Winter, Ed. T. Winter, Ed.
Eka Systems Eka Systems
D. Barthel, Ed. D. Barthel, Ed.
France Telecom R&D France Telecom R&D
March 30, 2009 Routing Requirements for Urban Low-Power and Lossy Networks
Urban WSNs Routing Requirements in Low Power and Lossy Networks
draft-ietf-roll-urban-routing-reqs-05
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at Status of This Memo
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 1, 2009. This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
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
and restrictions with respect to this document. and restrictions with respect to this document.
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 people's living conditions as well as
as to monitor compliance with increasingly strict environmental laws. 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 (for example, the data required by applications that perform
meteorological, pollution and allergy reporting applications. The smart-metering or that monitor meteorological, pollution, and allergy
majority of these nodes is expected to communicate wirelessly over a conditions). The majority of these nodes are expected to communicate
variety of links such as IEEE 802.15.4, Low power IEEE 802.11, IEEE wirelessly over a variety of links such as IEEE 802.15.4, low-power
802.15.1 (Bluetooth), which given the limited radio range and the IEEE 802.11, or IEEE 802.15.1 (Bluetooth), which given the limited
large number of nodes requires the use of suitable routing protocols. radio range and the large number of nodes requires the use of
The design of such protocols will be mainly impacted by the limited suitable routing protocols. The design of such protocols will be
resources of the nodes (memory, processing power, battery, etc.) and mainly impacted by the limited resources of the nodes (memory,
the particularities of the outdoor urban application scenarios. As processing power, battery, etc.) and the particularities of the
such, for a wireless Routing Over Low power and Lossy networks (ROLL) outdoor urban application scenarios. As such, for a wireless
solution to be useful, the protocol(s) ought to be energy-efficient, solution for Routing Over Low-Power and Lossy (ROLL) networks to be
scalable, and autonomous. This documents aims to specify a set of useful, the protocol(s) ought to be energy-efficient, scalable, and
IPv6 routing requirements reflecting these and further U-LLNs autonomous. This documents aims to specify a set of IPv6 routing
tailored characteristics. requirements reflecting these and further U-LLNs' tailored
characteristics.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction ....................................................3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology .....................................................3
3. Overview of Urban Low Power Lossy Networks . . . . . . . . . . 5 2.1. Requirements Language ......................................4
3.1. Canonical Network Elements . . . . . . . . . . . . . . . . 5 3. Overview of Urban Low-Power and Lossy Networks ..................4
3.1.1. Sensors . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Canonical Network Elements .................................4
3.1.2. Actuators . . . . . . . . . . . . . . . . . . . . . . 6 3.1.1. Sensors .............................................4
3.1.3. Routers . . . . . . . . . . . . . . . . . . . . . . . 6 3.1.2. Actuators ...........................................5
3.2. Topology . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1.3. Routers .............................................6
3.3. Resource Constraints . . . . . . . . . . . . . . . . . . . 7 3.2. Topology ...................................................6
3.4. Link Reliability . . . . . . . . . . . . . . . . . . . . . 8 3.3. Resource Constraints .......................................7
4. Urban LLN Application Scenarios . . . . . . . . . . . . . . . 9 3.4. Link Reliability ...........................................7
4.1. Deployment of Nodes . . . . . . . . . . . . . . . . . . . 9 4. Urban LLN Application Scenarios .................................8
4.2. Association and Disassociation/Disappearance of Nodes . . 10 4.1. Deployment of Nodes ........................................8
4.3. Regular Measurement Reporting . . . . . . . . . . . . . . 10 4.2. Association and Disassociation/Disappearance of Nodes ......9
4.4. Queried Measurement Reporting . . . . . . . . . . . . . . 11 4.3. Regular Measurement Reporting ..............................9
4.5. Alert Reporting . . . . . . . . . . . . . . . . . . . . . 11 4.4. Queried Measurement Reporting .............................10
5. Traffic Pattern . . . . . . . . . . . . . . . . . . . . . . . 12 4.5. Alert Reporting ...........................................11
6. Requirements of Urban LLN Applications . . . . . . . . . . . . 13 5. Traffic Pattern ................................................11
6.1. Scalability . . . . . . . . . . . . . . . . . . . . . . . 14 6. Requirements of Urban-LLN Applications .........................13
6.2. Parameter Constrained Routing . . . . . . . . . . . . . . 14 6.1. Scalability ...............................................13
6.3. Support of Autonomous and Alien Configuration . . . . . . 15 6.2. Parameter-Constrained Routing .............................13
6.4. Support of Highly Directed Information Flows . . . . . . . 15 6.3. Support of Autonomous and Alien Configuration .............14
6.5. Support of Multicast and Anycast . . . . . . . . . . . . . 16 6.4. Support of Highly Directed Information Flows ..............15
6.6. Network Dynamicity . . . . . . . . . . . . . . . . . . . . 16 6.5. Support of Multicast and Anycast ..........................15
6.7. Latency . . . . . . . . . . . . . . . . . . . . . . . . . 17 6.6. Network Dynamicity ........................................16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 6.7. Latency ...................................................16
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 7. Security Considerations ........................................16
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 8. References .....................................................18
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 8.1. Normative References ......................................18
10.1. Normative References . . . . . . . . . . . . . . . . . . . 19 8.2. Informative References ....................................18
10.2. Informative References . . . . . . . . . . . . . . . . . . 19 Appendix A. Acknowledgements .....................................20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Appendix B. Contributors .........................................20
1. Introduction 1. Introduction
This document details application-specific IPv6 routing requirements This document details application-specific IPv6 routing requirements
for Urban Low Power and Lossy Networks (U-LLNs). Note that this for Urban Low-Power and Lossy Networks (U-LLNs). Note that this
document details the set of IPv6 routing requirements for U-LLNs in document details the set of IPv6 routing requirements for U-LLNs in
strict compliance with the layered IP architecture. U-LLN use cases strict compliance with the layered IP architecture. U-LLN use cases
and associated routing protocol requirements will be described. 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 overlap with or be derived from other application-specific
specific requirements documents [I-D.ietf-roll-home-routing-reqs] requirements documents [ROLL-HOME] [ROLL-INDUS] [ROLL-BUILD].
[I-D.ietf-roll-indus-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" [ROLL-TERM]. This terminology is extended in this document
in this document as follows: 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
or guidance. Includes self-configuration and self-organization influence or guidance. Includes self-configuration and
capabilities. self-organization 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
of radio spectrum where low power unlicensed devices may region of radio spectrum where low-power, unlicensed
generally be used, with specific guidance from an applicable devices may generally be used, with specific guidance from
local radio spectrum authority. an applicable 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.
3. Overview of Urban Low Power Lossy Networks 2.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
3. Overview of Urban Low-Power and Lossy Networks
3.1. Canonical Network Elements 3.1. Canonical Network Elements
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. The aim of the following sections that communicate wirelessly. The aim of the following sections
(Section 3.1.1, Section 3.1.2, and Section 3.1.3) is to illustrate (3.1.1, 3.1.2, and 3.1.3) is to illustrate the functional nature of a
the functional nature of a sensor, actuator and a router in this sensor, actuator, and router in this context. That said, it must be
context. That said, it must be understood that these functionalities understood that these functionalities are not exclusive. A
are not exclusive. A particular device may act as a simple router or particular device may act as a simple router or may alternatively be
may alternatively be a router equipped with a sensing functionality, a router equipped with a sensing functionality, in which case it will
in which case it will be seen as a "regular" router as far as routing be seen as a "regular" router as far as routing is concerned.
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
index, strength and direction of wind, etc; index, strength and direction of wind, etc.;
3. pollution data, such as gases (sulfur dioxide, nitrogen oxide,
carbon monoxide, ozone), heavy metals (e.g., mercury), pH,
radioactivity, etc.;
3. pollution data, such as gases (SO2, NOx, CO, Ozone), heavy metals 4. ambient data, such as levels of allergens (pollen, dust),
(e.g. Mercury), pH, radioactivity, etc; electromagnetic pollution, noise, etc.
4. ambient data, such as allergic elements (pollen, dust),
electromagnetic pollution, noise levels, etc.
Sensor nodes run applications that typically gather the measurement Sensor nodes run applications that typically gather the measurement
data and send it to data collection and processing application(s) on data and send it to data collection and processing application(s) on
other node(s) (often outside the U-LLN). 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 that 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
advanced sensing functionalities such as measuring the quality of advanced sensing functionalities such as measuring the quality of
electrical service provided to a customer, providing granular electrical service provided to a customer, providing granular
interval data, or automating the detection of alarm conditions. In interval data, or automating the detection of alarm conditions. In
addition they may be capable of advanced interactive functionalities, addition, they may be capable of advanced interactive
which may invoke an Actuator component, such as remote service functionalities, which may invoke an actuator component, such as
disconnect or remote demand reset. More advanced scenarios include remote service disconnect or remote demand reset. More advanced
demand response systems for managing peak load, and distribution scenarios include demand response systems for managing peak load, and
automation systems to monitor the infrastructure which delivers distribution automation systems to monitor the infrastructure that
energy throughout the urban environment. Sensor nodes capable of delivers energy throughout the urban environment. Sensor nodes
providing this type of functionality may sometimes be referred to as capable of providing this type of functionality may sometimes be
Advanced Metering Infrastructure (AMI). referred to as Advanced Metering Infrastructure (AMI).
3.1.2. Actuators 3.1.2. Actuators
Actuator nodes are capable of controlling urban devices; examples are Actuator nodes are capable of controlling urban devices; examples are
street or traffic lights. They run applications that receive street or traffic lights. They run applications that receive
instructions from control applications on other nodes (possibly instructions from control applications on other nodes (possibly
outside the U-LLN). The amount of actuator points is well below the outside the U-LLN). The amount of actuator points is well below the
number of sensing nodes. Some sensing nodes may include an actuator number of sensing nodes. Some sensing nodes may include an actuator
component, e.g. an electric meter node with integrated support for component, e.g., an electric meter node with integrated support for
remote service disconnect. Actuators are capable of forwarding data. remote service disconnect. Actuators are capable of forwarding data.
Actuators are not likely to be mobile in the majority of near-future Actuators are not likely to be mobile in the majority of near-future
roll-outs. Actuator nodes may also suffer from long-term resource roll-outs. Actuator nodes may also suffer from long-term resource
constraints, e.g. in the case where they are battery powered. 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, and
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. That being sensing nodes in that they neither control nor sense. That being
said, a sensing node or actuator may also be a router within the said, a sensing node or actuator may also be a router within the
U-LLN. 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. (LBRs) in that context.
LBR nodes in particular may also run applications that communicate LBR nodes in particular may also run applications that communicate
with sensor and actuator nodes (e.g. collecting and processing data with sensor and actuator nodes (e.g., collecting and processing data
from sensor applications, or sending instructions to actuator from sensor applications, or sending instructions to actuator
applications). 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.
Deployment of nodes is likely to happen in batches, e.g. boxes of Deployment of nodes is likely to happen in batches, e.g., boxes of
hundreds to thousands of nodes arrive and are deployed. The location hundreds to thousands of nodes arrive and are deployed. The location
of the nodes is random within given topological constraints, e.g. of the nodes is random within given topological constraints, e.g.,
placement along a road, river, or at individual residences. placement along a road, river, or at individual residences.
3.3. Resource Constraints 3.3. Resource Constraints
The nodes are highly resource constrained, i.e. cheap hardware, low The nodes are highly resource constrained, i.e., cheap hardware, low
memory and no infinite energy source. Different node powering memory, and no infinite energy source. Different node powering
mechanisms are available, such as: mechanisms are available, such as:
1. non-rechargeable battery; 1. non-rechargeable battery;
2. rechargeable battery with regular recharging (e.g. sunlight); 2. rechargeable battery with regular recharging (e.g., sunlight);
3. rechargeable battery with irregular recharging (e.g. 3. rechargeable battery with irregular recharging (e.g.,
opportunistic energy scavenging); opportunistic energy scavenging);
4. capacitive/inductive energy provision (e.g. passive Radio 4. capacitive/inductive energy provision (e.g., passive Radio
Frequency IDentification (RFID)); Frequency IDentification (RFID));
5. always on (e.g. powered electricity meter). 5. always on (e.g., powered electricity meter).
In the case of a battery powered sensing node, the battery shelf life In the case of a battery-powered sensing node, the battery shelf life
is usually in the order of 10 to 15 years, rendering network lifetime is usually in the order of 10 to 15 years, rendering network lifetime
maximization with battery powered nodes beyond this lifespan useless. maximization with battery-powered nodes beyond this lifespan useless.
The physical and electromagnetic distances between the three key The physical and electromagnetic distances between the three key
elements, i.e. sensors, actuators, and routers, can generally be very elements, i.e., sensors, actuators, and routers, can generally be
large, i.e. from several hundreds of meters to one kilometer. Not very large, i.e., from several hundreds of meters to one kilometer.
every field node is likely to reach the LBR in a single hop, thereby Not every field node is likely to reach the LBR in a single hop,
requiring suitable routing protocols which manage the information thereby requiring suitable routing protocols that manage the
flow in an energy-efficient manner. information flow in an energy-efficient manner.
3.4. Link Reliability 3.4. Link Reliability
The links between the network elements are volatile due to the The links between the network elements are volatile due to the
following set of non-exclusive effects: following set of non-exclusive effects:
1. packet errors due to wireless channel effects; 1. packet errors due to wireless channel effects;
2. packet errors due to MAC (Medium Access Control) (e.g. 2. packet errors due to MAC (Medium Access Control) (e.g.,
collision); collision);
3. packet errors due to interference from other systems; 3. packet errors due to interference from other systems;
4. link unavailability due to network dynamicity; etc. 4. link unavailability due to network dynamicity; etc.
The wireless channel causes the received power to drop below a given The wireless channel causes the received power to drop below a given
threshold in a random fashion, thereby causing detection errors in threshold in a random fashion, thereby causing detection errors in
the receiving node. The underlying effects are path loss, shadowing the receiving node. The underlying effects are path loss, shadowing
and fading. and fading.
Since the wireless medium is broadcast in nature, nodes in their Since the wireless medium is broadcast in nature, nodes in their
communication radios require suitable medium access control protocols communication radios require suitable medium access control protocols
which are capable of resolving any arising contention. Some that are capable of resolving any arising contention. Some available
available protocols may not be able to prevent packets of neighboring protocols may not be able to prevent packets of neighboring nodes
nodes from colliding, possibly leading to a high Packet Error Rate from colliding, possibly leading to a high Packet Error Rate (PER)
(PER) and causing a link outage. and causing a link outage.
Furthermore, the outdoor deployment of U-LLNs also has implications Furthermore, the outdoor deployment of U-LLNs also has implications
for the interference temperature and hence link reliability and range for the interference temperature and hence link reliability and range
if Industrial, Scientific and Medical (ISM) bands are to be used. if Industrial, Scientific, and Medical (ISM) bands are to be used.
For instance, if the 2.4GHz ISM band is used to facilitate For instance, if the 2.4GHz ISM band is used to facilitate
communication between U-LLN nodes, then heavily loaded Wireless Local communication between U-LLN nodes, then heavily loaded Wireless Local
Area Network (WLAN) hot-spots may become a detrimental performance Area Network (WLAN) hot-spots may become a detrimental performance
factor, leading to high PER and jeopardizing the functioning of the factor, leading to high PER and jeopardizing the functioning of the
U-LLN. U-LLN.
Finally, nodes appearing and disappearing causes dynamics in the Finally, nodes appearing and disappearing causes dynamics in the
network which can yield link outages and changes of topologies. network that can yield link outages and changes of topologies.
4. Urban LLN Application Scenarios 4. Urban LLN Application Scenarios
Urban applications represent a special segment of LLNs with its Urban applications represent a special segment of LLNs with its
unique set of requirements. To facilitate the requirements unique set of requirements. To facilitate the requirements
discussion in Section 6, this section lists a few typical but not discussion in Section 6, this section lists a few typical but not
exhaustive deployment problems and usage cases of U-LLN. exhaustive deployment problems and usage cases of U-LLN.
4.1. Deployment of Nodes 4.1. Deployment of Nodes
Contrary to other LLN applications, deployment of nodes is likely to Contrary to other LLN applications, deployment of nodes is likely to
happen in batches out of a box. Typically, hundreds to thousands of happen in batches out of a box. Typically, hundreds to thousands of
nodes are being shipped by the manufacturer with pre-programmed nodes are being shipped by the manufacturer with pre-programmed
functionalities which are then rolled-out by a service provider or functionalities which are then rolled-out by a service provider or
subcontracted entities. Prior or after roll-out, the network needs subcontracted entities. Prior to or after roll-out, the network
to be ramped-up. This initialization phase may include, among needs to be ramped-up. This initialization phase may include, among
others, allocation of addresses, (possibly hierarchical) roles in the others, allocation of addresses, (possibly hierarchical) roles in the
network, synchronization, determination of schedules, etc. network, synchronization, determination of schedules, etc.
If initialization is performed prior to roll-out, all nodes are If initialization is performed prior to roll-out, all nodes are
likely to be in one another's 1-hop radio neighborhood. Pre- likely to be in one another's one-hop radio neighborhood. Pre-
programmed Media Access Control (MAC) and routing protocols may hence programmed Media Access Control (MAC) and routing protocols may hence
fail to function properly, thereby wasting a large amount of energy. fail to function properly, thereby wasting a large amount of energy.
Whilst the major burden will be on resolving MAC conflicts, any Whilst the major burden will be on resolving MAC conflicts, any
proposed U-LLN routing protocol needs to cater for such a case. For proposed U-LLN routing protocol needs to cater for such a case. For
instance, 0-configuration and network address allocation needs to be instance, zero-configuration and network address allocation needs to
properly supported, etc. be properly supported, etc.
After roll-out, nodes will have a finite set of one-hop neighbors, After roll-out, nodes will have a finite set of one-hop neighbors,
likely of low cardinality (in the order of 5 to 10). However, some likely of low cardinality (in the order of 5 to 10). However, some
nodes may be deployed in areas where there are hundreds of nodes may be deployed in areas where there are hundreds of
neighboring devices. In the resulting topology there may be regions neighboring devices. In the resulting topology, there may be regions
where many (redundant) paths are possible through the network. Other where many (redundant) paths are possible through the network. Other
regions may be dependent on critical links to achieve connectivity regions may be dependent on critical links to achieve connectivity
with the rest of the network. Any proposed LLN routing protocol with the rest of the network. Any proposed LLN routing protocol
ought to support the autonomous self-organization and self- ought to support the autonomous self-organization and self-
configuration of the network at lowest possible energy cost [Lu2007], configuration of the network at lowest possible energy cost [Lu2007],
where autonomy is understood to be the ability of the network to where autonomy is understood to be the ability of the network to
operate without external influence. The result of such organization operate without external influence. The result of such organization
should be that each node or set of nodes is uniquely addressable so should be that each node or set of nodes is uniquely addressable so
as to facilitate the set up of schedules, etc. as to facilitate the set up of schedules, etc.
skipping to change at page 10, line 25 skipping to change at page 9, line 34
After the initialization phase and possibly some operational time, After the initialization phase and possibly some operational time,
new nodes may be injected into the network as well as existing nodes new nodes may be injected into the network as well as existing nodes
removed from the network. The former might be because a removed node removed from the network. The former might be because a removed node
is replaced as part of maintenance, or new nodes are added because is replaced as part of maintenance, or new nodes are added because
more sensors for denser readings/actuations are needed, or because more sensors for denser readings/actuations are needed, or because
routing protocols report connectivity problems. The latter might be routing protocols report connectivity problems. The latter might be
because a node's battery is depleted, the node is removed for because a node's battery is depleted, the node is removed for
maintenance, the node is stolen or accidentally destroyed, etc. maintenance, the node is stolen or accidentally destroyed, etc.
The protocol(s) hence should be able to convey information about The protocol(s) hence should be able to convey information about
malfunctioning nodes which may affect or jeopardize the overall malfunctioning nodes that may affect or jeopardize the overall
routing efficiency, so that self-organization and self-configuration routing efficiency, so that self-organization and self-configuration
capabilities of the sensor network might be solicited to facilitate capabilities of the sensor network might be solicited to facilitate
the appropriate reconfiguration. This information may e.g. include the appropriate reconfiguration. This information may include, e.g.,
exact or relative geographical position, etc. The reconfiguration exact or relative geographical position, etc. The reconfiguration
may include the change of hierarchies, routing paths, packet may include the change of hierarchies, routing paths, packet
forwarding schedules, etc. Furthermore, to inform the LBR(s) of the forwarding schedules, etc. Furthermore, to inform the LBR(s) of the
node's arrival and association with the network as well as freshly node's arrival and association with the network as well as freshly
associated nodes about packet forwarding schedules, roles, etc, associated nodes about packet forwarding schedules, roles, etc.,
appropriate updating mechanisms should be supported. appropriate updating mechanisms should be supported.
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 data delivery may not be vital as sensing outages can be observed at data
collection applications - when, for instance, there is no reading collection applications -- when, for instance, there is no reading
arriving from a given sensor or cluster of sensors within a day. In arriving from a given sensor or cluster of sensors within a day. In
this case, a query can be launched to check upon the state and this case, a query can be launched to check upon the state and
availability of a sensing node or sensing cluster. availability of a sensing node or sensing cluster.
It is not uncommon to gather data on a few servers located outside of It is not uncommon to gather data on a few servers located outside of
the U-LLN. In such cases, a large number of highly directional the U-LLN. In such cases, a large number of highly directional
unicast flows from the sensing nodes or sensing clusters are likely unicast flows from the sensing nodes or sensing clusters are likely
to transit through a LBR. Thus, the protocol(s) should be optimized 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 to support a large number of unicast flows from the sensing nodes or
sensing clusters towards a LBR, or highly directed multicast or sensing clusters towards a LBR, or highly directed multicast or
anycast flows from the nodes towards multiple LBRs. 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 the 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 energy 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 applications. For instance, it is desirable to know the several applications. For instance, it is desirable to know the
level of pollution at a specific point or along a given road in the level of pollution at a specific point or along a given road in the
urban environment. The queries' rates of occurrence are not regular urban environment. The queries' rates of occurrence are not regular
but 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 node 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 a node until the delivery times, i.e., from the launch of a query from a node until the
of the measured data to a node, are of importance. However, they are delivery of the measured data to a node, are of importance. However,
not very stringent where latencies should simply be sufficiently they are not very stringent where latencies should simply be
smaller than typical reporting intervals; for instance, in the order sufficiently smaller than typical reporting intervals; for instance,
of seconds or minute. The routing protocol(s) should consider the in the order of seconds or minutes. The routing protocol(s) should
selection of paths with appropriate (e.g. latency) metrics to support consider the selection of paths with appropriate (e.g., latency)
queried measurement reporting. To facilitate the query process, metrics to support queried measurement reporting. To facilitate the
U-LLN network devices should support unicast and multicast routing query process, U-LLN devices should support unicast and multicast
capabilities. routing 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 that classifies as an
alarm where such a classification is typically done locally within alarm where such a classification is typically done locally within
each node by means of a pre-programmed or prior diffused threshold. each node by means of a pre-programmed or prior-diffused threshold.
Note that on approaching the alert threshold level, nodes may wish to Note that on approaching the alert threshold level, nodes may wish to
change their sensing and reporting cycles. An alarm is likely being change their sensing and reporting cycles. An alarm is likely being
registered by a plurality of sensing nodes where the delivery of a registered by a plurality of sensing nodes where the delivery of a
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
sensor measuring its level of occupancy - reports that the container a sensor measuring its level of occupancy -- reports that the
is full and hence needs to be emptied. container 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, for a U-LLN deployed in support of a typical application, however, for a U-LLN deployed in support of a typical application,
deliveries within seconds should suffice in most of 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:
skipping to change at page 12, line 36 skipping to change at page 11, line 44
2. query requests from applications outside the U-LLN, going through 2. query requests from applications outside the U-LLN, going through
the LBR(s) towards the sensing nodes; the LBR(s) towards the sensing nodes;
3. control information from applications outside the U-LLN, going 3. control information from applications outside the U-LLN, going
through the LBR(s) towards the actuators. 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,
Data may be delivered regularly according to a schedule or a regular etc. Data may be delivered regularly according to a schedule or a
query; it may also be delivered irregularly after an externally regular query; it may also be delivered irregularly after an
triggered query; it may also be triggered after a sudden network- externally triggered query; it may also be triggered after a sudden
internal event or alert. Schedules may be driven by, for example, a network-internal event or alert. Schedules may be driven by, for
smart-metering application where data is expected to be delivered example, a smart-metering application where data is expected to be
every hour, or an environmental monitoring application where a delivered every hour, or an environmental monitoring application
battery powered node is expected to report its status at a specific where a battery-powered node is expected to report its status at a
time once a day. Data delivery may trigger acknowledgements or specific time once a day. Data delivery may trigger acknowledgements
maintenance traffic in the reverse direction. The network hence or maintenance traffic in the reverse direction. The network hence
needs to be able to adjust to the varying activity duty cycles, as needs to be able to adjust to the varying activity duty cycles, as
well as to periodic and sporadic traffic. Also, sensed data ought to well as to periodic and sporadic traffic. Also, sensed data ought to
be secured and locatable. be secured and locatable.
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 A U-LLN should support occasional large-scale traffic flows from
sensing nodes through LBRs (to nodes outside the U-LLN), such as sensing nodes through LBRs (to nodes outside the U-LLN), such as
system-wide alerts. In the example of an AMI U-LLN this could be in system-wide alerts. In the example of an AMI U-LLN, this could be in
response to events such as a city wide power outage. In this response to events such as a city-wide power outage. In this
scenario all powered devices in a large segment of the network may scenario, all powered devices in a large segment of the network may
have lost power and are running off of a temporary `last gasp' source have lost power and be running off of a temporary "last gasp" source
such as a capacitor or small battery. A node must be able to send such as a capacitor or small battery. A node must be able to send
its own alerts toward an LBR while continuing to forward traffic on its own alerts toward an LBR while continuing to forward traffic on
behalf of other devices who are also experiencing an alert condition. behalf of other devices that are also experiencing an alert
The network needs to be able to manage this sudden large traffic condition. The network needs to be able to manage this sudden large
flow. traffic flow.
An U-LLN may also need to support efficient large scale messaging to A 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
response control information to a large subset of actuators in the demand-response control information to a large subset of actuators in
system. the 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
forward traffic from a utility, across the U-LLN, into a home forward traffic from a utility, across the U-LLN, into a home
automation network. A typical use case would be to inform a customer automation network. A typical use case would be to inform a customer
of incentives to reduce demand during peaks, or to automatically of incentives to reduce demand during peaks, or to automatically
adjust the thermostat of customers who have enrolled in such a demand adjust the thermostat of customers who have enrolled in such a demand
management program. Subsequent traffic may be triggered to flow back management program. Subsequent traffic may be triggered to flow back
through the U-LLN to the utility. through the U-LLN to the utility.
6. Requirements of Urban LLN Applications 6. Requirements of Urban-LLN Applications
Urban low power and lossy network applications have a number of Urban Low-Power and Lossy Network applications have a number of
specific requirements related to the set of operating conditions, as specific requirements related to the set of operating conditions, as
exemplified in the previous sections. exemplified in the previous sections.
6.1. Scalability 6.1. Scalability
The large and diverse measurement space of U-LLN nodes - coupled with The large and diverse measurement space of U-LLN nodes -- coupled
the typically large urban areas - will yield extremely large network with the typically large urban areas -- will yield extremely large
sizes. Current urban roll-outs are composed of sometimes more than network sizes. Current urban roll-outs are composed of sometimes
one hundred nodes; future roll-outs, however, may easily reach more than one hundred nodes; future roll-outs, however, may easily
numbers in the tens of thousands to millions. One of the utmost reach numbers in the tens of thousands to millions. One of the
important LLN routing protocol design criteria is hence scalability. utmost important LLN routing protocol design criteria is hence
scalability.
The routing protocol(s) MUST be capable of supporting the The routing protocol(s) MUST be capable of supporting the
organization of a large number of sensing nodes into regions organization of a large number of sensing nodes into regions
containing on the order of 10^2 to 10^4 sensing nodes each. containing on the order of 10^2 to 10^4 sensing nodes each.
The routing protocol(s) MUST be scalable so as to accommodate a very The routing protocol(s) MUST be scalable so as to accommodate a very
large and increasing number of nodes without deteriorating selected large and increasing number of nodes without deteriorating selected
performance parameters below configurable thresholds. The routing performance parameters below configurable thresholds. The routing
protocols(s) SHOULD support the organization of a large number of protocols(s) SHOULD support the organization of a large number of
nodes into regions of configurable size. nodes into regions of configurable size.
6.2. Parameter Constrained Routing 6.2. Parameter-Constrained Routing
Batteries in some nodes may deplete quicker than in others; the Batteries in some nodes may deplete quicker than in others; the
existence of one node for the maintenance of a routing path may not existence of one node for the maintenance of a routing path may not
be as important as of another node; the battery scavenging methods be as important as of another node; the energy-scavenging methods may
may recharge the battery at regular or irregular intervals; some recharge the battery at regular or irregular intervals; some nodes
nodes may have a constant power source; some nodes may have a larger may have a constant power source; some nodes may have a larger memory
memory and are hence be able to store more neighborhood information; and are hence be able to store more neighborhood information; some
some nodes may have a stronger CPU and are hence able to perform more nodes may have a stronger CPU and are hence able to perform more
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.
In other words the routing protocol MUST be able to advertise node In other words, the routing protocol MUST be able to advertise node
capabilities that will be exclusively used by the routing protocol capabilities that will be exclusively used by the routing protocol
engine for routing decision. For the sake of example, such engine for routing decision. For the sake of example, such a
capability could be related to the node capability itself (e.g. capability could be related to the node capability itself (e.g.,
remaining power) or some application that could influence routing remaining power) or some application that could influence routing
(e.g. capability to aggregate data). (e.g., capability to aggregate data).
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
same destination, depending on the nature of the traffic. Such the 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
to use some mechanisms to mark/tag the traffic for appropriate use of some mechanisms to mark/tag the traffic for appropriate
routing decision using the IPv6 packet format (e.g. use of DSCP, Flow routing decision using the IPv6 packet format (e.g., use of Diffserv
Label) based on an upper layer marking decision. From this Code Point (DSCP), Flow Label) based on an upper-layer marking
perspective, such nodes MAY use node capabilities (e.g. to act as an decision. From this perspective, such nodes MAY use node
aggregator) in conjunction with the anycast endpoints and packet capabilities (e.g., to act as an aggregator) in conjunction with the
marking to route the traffic. 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
triggered configurations (for instance through a commissioning tool triggered configurations (for instance, through a commissioning tool
which may facilitate the organization of the network at a minimum that may facilitate the organization of the network at a minimum
energy cost). energy cost).
To this end, the routing protocol(s) MUST provide a set of features To this end, the routing protocol(s) MUST provide a set of features
including 0-configuration at network ramp-up, (network-internal) including zero-configuration at network ramp-up, (network-internal)
self- organization and configuration due to topological changes, and self- organization and configuration due to topological changes, and
the ability to support (network-external) patches and configuration the ability to support (network-external) patches and configuration
updates. For the latter, the protocol(s) MUST support multi- and updates. For the latter, the protocol(s) MUST support multicast and
any-cast addressing. The protocol(s) SHOULD also support the anycast addressing. The protocol(s) SHOULD also support the
formation and identification of groups of field devices in the formation and identification of groups of field devices in the
network. network.
The routing protocol(s) SHOULD be able to dynamically adapt, e.g. The routing protocol(s) SHOULD be able to dynamically adapt, e.g.,
through the application of appropriate routing metrics, to ever- through the application of appropriate routing metrics, to ever-
changing conditions of communication (possible degradation of QoS, changing conditions of communication (possible degradation of quality
variable nature of the traffic (real time vs. non real time, sensed of service (QoS), variable nature of the traffic (real-time versus
data vs. alerts), node mobility, a combination thereof, etc.) non-real-time, sensed data versus alerts), node mobility, a
combination thereof, etc.).
The routing protocol(s) SHOULD be able to dynamically compute, select The routing protocol(s) SHOULD be able to dynamically compute,
and possibly optimize the (multiple) path(s) that will be used by the select, and possibly optimize the (multiple) path(s) that will be
participating devices to forward the traffic towards the actuators used by the participating devices to forward the traffic towards the
and/or a LBR according to the service-specific and traffic-specific actuators and/or a LBR according to the service-specific and traffic-
QoS, traffic engineering and routing security policies that will have specific QoS, traffic engineering, and routing security policies that
to be enforced at the scale of a routing domain (that is, a set of will have to be enforced at the scale of a routing domain (that is, a
networking devices administered by a globally unique entity), or a set of networking devices administered by a globally unique entity),
region of such domain (e.g. a metropolitan area composed of clusters or a region of such domain (e.g., a metropolitan area composed of
of sensors). clusters of sensors).
6.4. Support of Highly Directed Information Flows 6.4. Support of Highly Directed Information Flows
As pointed out in section Section 4.3, it is not uncommon to gather As pointed out in Section 4.3, it is not uncommon to gather data on a
data on a few servers located outside of the U-LLN. In this case, few servers located outside of the U-LLN. In this case, the
the reporting of the data readings by a large amount of spatially 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 that 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 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 and Anycast 6.5. Support of Multicast and Anycast
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.
The support of unicast, multicast, and anycast also has an The support of unicast, multicast, and anycast also has an
implication on the addressing scheme but is beyond the scope of this implication on the addressing scheme, but it is beyond the scope of
document that focuses on the routing requirements aspects. this document that focuses on the routing requirements.
Some urban sensing systems may require low-level addressing of a 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 in the same subnet, or for a node representative of a
group of nodes, without any prior creation of multicast groups. Such group of nodes, without any prior creation of multicast groups. Such
addressing schemes, where a sender can form an addressable group addressing schemes, where a sender can form an addressable group of
receivers, are not currently supported by IPv6, and not further receivers, are not currently supported by IPv6, and not further
discussed in this specification [I-D.ietf-roll-home-routing-reqs]. discussed in this specification [ROLL-HOME].
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
dynamicity due to node association, disassociation and disappearance, dynamicity due to node association, disassociation, and
as well as long-term link perturbations is not negligible. This in disappearance, as well as long-term link perturbations is not
turn impacts reorganization and reconfiguration convergence as well negligible. This in turn impacts reorganization and reconfiguration
as routing protocol convergence. convergence as well as routing protocol convergence.
To this end, local network dynamics SHOULD NOT impact the entire To this end, local network dynamics SHOULD NOT impact the entire
network to be re-organized or re-reconfigured; however, the network network to be reorganized or re-reconfigured; however, the network
SHOULD be locally optimized to cater for the encountered changes. SHOULD be locally optimized to cater for the encountered changes.
The routing protocol(s) SHOULD support appropriate mechanisms in The routing protocol(s) SHOULD support appropriate mechanisms in
order to be informed of the association, disassociation, and order to be informed of the association, disassociation, and
disappearance of nodes. The routing protocol(s) SHOULD support disappearance of nodes. The routing protocol(s) SHOULD support
appropriate updating mechanisms in order to be informed of changes in appropriate updating mechanisms in order to be informed of changes in
connectivity. The routing protocol(s) SHOULD use this information to connectivity. The routing protocol(s) SHOULD use this information to
initiate protocol specific mechanisms for reorganization and initiate protocol-specific mechanisms for reorganization and
reconfiguration as necessary to maintain overall routing efficiency. reconfiguration as necessary to maintain overall routing efficiency.
Convergence and route establishment times SHOULD be significantly Convergence and route establishment times SHOULD be significantly
lower than the smallest reporting interval. lower than the smallest reporting interval.
Differentiation SHOULD be made between node disappearance, where the Differentiation SHOULD be made between node disappearance, where the
node disappears without prior notification, and user or node- node disappears without prior notification, and user- or node-
initiated disassociation ("phased-out"), where the node has enough initiated disassociation ("phased-out"), where the node has enough
time to inform the network about its pending removal. time to inform the network about its pending removal.
6.7. Latency 6.7. Latency
With the exception of alert reporting solutions and to a certain With the exception of alert-reporting solutions and (to a certain
extent queried reporting, U-LLNs are delay tolerant as long as the extent) queried reporting, U-LLNs are delay tolerant as long as the
information arrives within a fraction of the smallest reporting information arrives within a fraction of the smallest reporting
interval, e.g. a few seconds if reporting is done every 4 hours. interval, e.g., a few seconds if reporting is done every 4 hours.
The routing protocol(s) SHOULD also support the ability to route The routing protocol(s) SHOULD also support the ability to route
according to different metrics (one of which could e.g. be latency). according to different metrics (one of which could, e.g., be
latency).
7. Security Considerations 7. Security Considerations
As every network, U-LLNs are exposed to routing security threats that As every network, U-LLNs are exposed to routing security threats that
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 any node who has not been authenticated The U-LLN MUST deny any node that has not been authenticated to the
to the U-LLN and authorized to participate to the routing decision U-LLN and authorized to participate to the routing decision process.
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 examples of routing security issues that may arise are the
abnormal behavior of nodes which exhibit an egoistic conduct, such as abnormal behavior of nodes that 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)
attacks, malicious address space allocations, advertisement of attacks, malicious address space allocations, advertisement of
variable addresses, a wrong neighborhood, etc. The routing variable addresses, a wrong neighborhood, etc. The routing
protocol(s) SHOULD support defense against DoS attacks and other protocol(s) SHOULD support defense against DoS attacks and other
attempts to maliciously or inadvertently cause the routing attempts to maliciously or inadvertently cause the mechanisms of the
protocol(s) mechanisms to over consume the limited resources of LLN routing protocol(s) to over-consume the limited resources of LLN
nodes, e.g. by constructing forwarding loops or causing excessive nodes, e.g., by constructing forwarding loops or causing excessive
routing protocol overhead traffic, etc. routing protocol overhead traffic, etc.
The properties of self-configuration and self-organization which are The properties of self-configuration and self-organization that are
desirable in a U-LLN introduce additional routing security desirable in a U-LLN introduce additional routing security
considerations. Mechanisms MUST be in place to deny any node which considerations. Mechanisms MUST be in place to deny any node that
attempts to take malicious advantage of self-configuration and self- attempts to take malicious advantage of self-configuration and self-
organization procedures. Such attacks may attempt, for example, to organization procedures. Such attacks may attempt, for example, to
cause DoS, drain the energy of power constrained devices, or to cause DoS, drain the energy of power-constrained devices, or to
hijack the routing mechanism. A node MUST authenticate itself to a hijack the routing mechanism. A node MUST authenticate itself to a
trusted node that is already associated with the U-LLN before the trusted node that is already associated with the U-LLN before the
former can take part in self-configuration or self-organization. A former can take part in self-configuration or self-organization. A
node that has already authenticated and associated with the U-LLN node that has already authenticated and associated with the U-LLN
MUST deny, to the maximum extent possible, the allocation of MUST deny, to the maximum extent possible, the allocation of
resources to any unauthenticated peer. The routing protocol(s) MUST resources to any unauthenticated peer. The routing protocol(s) MUST
deny service to any node which has not clearly established trust with deny service to any node that has not clearly established trust with
the U-LLN. the U-LLN.
Consideration SHOULD be given to cases where the U-LLN may interface Consideration SHOULD be given to cases where the U-LLN may interface
with other networks such as a home network. The U-LLN SHOULD NOT with other networks such as a home network. The U-LLN SHOULD NOT
interface with any external network which has not established trust. interface with any external network that has not established trust.
The U-LLN SHOULD be capable of limiting the resources granted in The U-LLN SHOULD be capable of limiting the resources granted in
support of an external network so as not to be vulnerable to DoS. support of an external network so as not to be vulnerable to DoS.
With low computation power and scarce energy resources, U-LLNs nodes With low computation power and scarce energy resources, U-LLNs' nodes
may not be able to resist any attack from high-power malicious nodes may not be able to resist any attack from high-power malicious nodes
(e.g. laptops and strong radios). However, the amount of damage (e.g., laptops and strong radios). However, the amount of damage
generated to the whole network SHOULD be commensurate with the number generated to the whole network SHOULD be commensurate with the number
of nodes physically compromised. For example, an intruder taking of nodes physically compromised. For example, an intruder taking
control over a single node SHOULD NOT be able to completely deny control over a single node SHOULD NOT be able to completely deny
service to the whole network. service to the whole network.
In general, the routing protocol(s) SHOULD support the implementation In general, the routing protocol(s) SHOULD support the implementation
of routing security best practices across the U-LLN. Such an of routing security best practices across the U-LLN. Such an
implementation ought to include defense against, for example, implementation ought to include defense against, for example,
eavesdropping, replay, message insertion, modification, and man-in- eavesdropping, replay, message insertion, modification, and man-in-
the-middle attacks. the-middle attacks.
The choice of the routing security solutions will have an impact onto The choice of the routing security solutions will have an impact on
routing protocol(s). To this end, routing protocol(s) proposed in the routing protocol(s). To this end, routing protocol(s) proposed
the context of U-LLNs MUST support authentication and integrity in the context of U-LLNs MUST support authentication and integrity
measures and SHOULD support confidentiality (routing security) measures and SHOULD support confidentiality (routing security)
measures. measures.
8. IANA Considerations 8. References
This document makes no request of IANA.
9. Acknowledgements
The in-depth feedback of JP Vasseur, Jonathan Hui, Iain Calder, and
Pasi Eronen is greatly appreciated.
10. References
10.1. Normative References 8.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 8.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]
Brandt, A., Buron, J., and G. Porcu, "Home Automation
Routing Requirements in Low Power and Lossy Networks",
draft-ietf-roll-home-routing-reqs-06 (work in progress),
November 2008.
[I-D.ietf-roll-indus-routing-reqs]
Networks, D., Thubert, P., Dwars, S., and T. Phinney,
"Industrial Routing Requirements in Low Power and Lossy
Networks", draft-ietf-roll-indus-routing-reqs-04 (work in
progress), January 2009.
[I-D.ietf-roll-terminology]
Vasseur, J., "Terminology in Low power And Lossy
Networks", draft-ietf-roll-terminology-00 (work in
progress), October 2008.
[Lu2007] J.L. Lu, F. Valois, D. Barthel, M. Dohler, "FISCO: A Fully [Lu2007] Lu, JL., Valois, F., Barthel, D., and M. Dohler,
Integrated Scheme of Self-Configuration and Self- "FISCO: A Fully Integrated Scheme of Self-Configuration
Organization for WSN", IEEE WCNC 2007, Hong Kong, China, and Self-Organization for WSN", 11-15 March 2007,
11-15 March 2007, pp. 3370-3375. pp. 3370-3375, IEEE WCNC 2007, Hong Kong, China.
[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.
Authors' Addresses [ROLL-BUILD] Martocci, J., Ed., De Mil, P., Vermeylen, W., and N.
Riou, "Building Automation Routing Requirements in Low
Mischa Dohler (editor) Power and Lossy Networks", Work in Progress,
CTTC February 2009.
Parc Mediterrani de la Tecnologia, Av. Canal Olimpic S/N
08860 Castelldefels, Barcelona
Spain
Email: mischa.dohler@cttc.es [ROLL-HOME] Brandt, A. and G. Porcu, "Home Automation Routing
Requirements in Low Power and Lossy Networks", Work
in Progress, November 2008.
Thomas Watteyne (editor) [ROLL-INDUS] Pister, K., Ed., Thubert, P., Ed., Dwars, S., and T.
CITI-Lab, INSA-Lyon, INRIA A4RES Phinney, "Industrial Routing Requirements in Low Power
21 avenue Jean Capelle and Lossy Networks", Work in Progress, April 2009.
69621 Lyon
France
Email: thomas.watteyne@ieee.org [ROLL-TERM] Vasseur, J., "Terminology in Low power And Lossy
Networks", Work in Progress, October 2008.
Tim Winter (editor) Appendix A. Acknowledgements
Eka Systems
20201 Century Blvd. Suite 250
Germantown, MD 20874
USA
Email: tim.winter@ekasystems.com The in-depth feedback of JP Vasseur, Jonathan Hui, Iain Calder, and
Dominique Barthel (editor) Pasi Eronen is greatly appreciated.
France Telecom R&D
28 Chemin du Vieux Chene
38243 Meylan Cedex
France
Email: Dominique.Barthel@orange-ftgroup.com Appendix B. Contributors
Christian Jacquenet Christian Jacquenet
France Telecom R&D France Telecom R&D
4 rue du Clos Courtel BP 91226 4 rue du Clos Courtel BP 91226
35512 Cesson Sevigne 35512 Cesson Sevigne
France France
Email: christian.jacquenet@orange-ftgroup.com EMail: christian.jacquenet@orange-ftgroup.com
Giyyarpuram Madhusudan Giyyarpuram Madhusudan
France Telecom R&D France Telecom R&D
28 Chemin du Vieux Chene 28 Chemin du Vieux Chene
38243 Meylan Cedex 38243 Meylan Cedex
France France
Email: giyyarpuram.madhusudan@orange-ftgroup.com EMail: giyyarpuram.madhusudan@orange-ftgroup.com
Gabriel Chegaray Gabriel Chegaray
France Telecom R&D France Telecom R&D
28 Chemin du Vieux Chene 28 Chemin du Vieux Chene
38243 Meylan Cedex 38243 Meylan Cedex
France France
Email: gabriel.chegaray@orange-ftgroup.com EMail: gabriel.chegaray@orange-ftgroup.com
Authors' Addresses
Mischa Dohler (editor)
CTTC
Parc Mediterrani de la Tecnologia
Av. Canal Olimpic S/N
08860 Castelldefels, Barcelona
Spain
EMail: mischa.dohler@cttc.es
Thomas Watteyne (editor)
Berkeley Sensor & Actuator Center, University of California, Berkeley
497 Cory Hall #1774
Berkeley, CA 94720-1774
USA
EMail: watteyne@eecs.berkeley.edu
Tim Winter (editor)
Eka Systems
20201 Century Blvd. Suite 250
Germantown, MD 20874
USA
EMail: wintert@acm.org
Dominique Barthel (editor)
France Telecom R&D
28 Chemin du Vieux Chene
38243 Meylan Cedex
France
EMail: Dominique.Barthel@orange-ftgroup.com
 End of changes. 127 change blocks. 
370 lines changed or deleted 309 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/