draft-ietf-roll-urban-routing-reqs-00.txt   draft-ietf-roll-urban-routing-reqs-01.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: September 15, 2008 France Telecom R&D Expires: December 3, 2008 France Telecom R&D
T. Winter, Ed.
April 16, 2008 Eka Systems
June 30, 2008
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-00 draft-ietf-roll-urban-routing-reqs-01
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of 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.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at and may be updated, replaced, or obsoleted by other documents at any
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 September 15, 2008. This Internet-Draft will expire on December 3, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
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 which -
- given the limited radio range and the large number of nodes - given the limited radio range and the large number of nodes -
requires the use of suitable routing protocols. The design of such requires the use of suitable routing protocols. The design of such
protocols will be mainly impacted by the limited resources of the protocols will be mainly impacted by the limited resources of the
nodes (memory, processing power, battery, etc) and the nodes (memory, processing power, battery, etc.) and the
particularities of the outdoors urban application scenario. As such, particularities of the outdoors urban application scenarios. As
for a wireless ROLL solution to be competitive with other incumbent such, for a wireless ROLL solution to be useful, the protocol(s)
and emerging solutions, the protocol(s) ought to be energy-efficient, ought to be energy-efficient, scalable, and autonomous. This
scalable and autonomous. This documents aims to specify a set of documents aims to specify a set of requirements reflecting these and
requirements reflecting these and further U-LLNs tailored further U-LLNs tailored characteristics.
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 . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Urban LLN application scenarios. . . . . . . . . . . . . . . . 7 3. Overview of Urban Low Power Lossy Networks . . . . . . . . . . 5
3.1. Deployment of nodes. . . . . . . . . . . . . . . . . . . . 7 3.1. Canonical Network Elements . . . . . . . . . . . . . . . . 5
3.2. Association and disassociation/disappearance of nodes. . . 8 3.1.1. Access Points . . . . . . . . . . . . . . . . . . . . 5
3.3. Regular measurement reporting. . . . . . . . . . . . . . . 8 3.1.2. Repeaters . . . . . . . . . . . . . . . . . . . . . . 6
3.4. Queried measurement reporting. . . . . . . . . . . . . . . 9 3.1.3. Actuators . . . . . . . . . . . . . . . . . . . . . . 6
3.5. Alert reporting. . . . . . . . . . . . . . . . . . . . . . 9 3.1.4. Sensors . . . . . . . . . . . . . . . . . . . . . . . 6
4. Requirements of urban LLN applications . . . . . . . . . . . . 10 3.2. Topology . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Scalability.. . . . . . . . . . . . . . . . . . . . . . . 10 3.3. Resource Constraints . . . . . . . . . . . . . . . . . . . 7
4.2. Parameter constrained routing . . . . . . . . . . . . . . 10 3.4. Link Reliability . . . . . . . . . . . . . . . . . . . . . 8
4.3. Support of autonomous and alien configuration . . . . . . 10 4. Urban LLN Application Scenarios . . . . . . . . . . . . . . . 9
4.4. Support of highly directed information flows. . . . . . . 11 4.1. Deployment of Nodes . . . . . . . . . . . . . . . . . . . 9
4.5. Support of heterogeneous field devices. . . . . . . . . . 11 4.2. Association and Disassociation/Disappearance of Nodes . . 10
4.6. Support of multicast and implementation of groupcast. . . 11 4.3. Regular Measurement Reporting . . . . . . . . . . . . . . 11
4.7. Network dynamicity. . . . . . . . . . . . . . . . . . . . 12 4.4. Queried Measurement Reporting . . . . . . . . . . . . . . 11
4.8. Latency. . . . . . . . . . . . . . . . . . . . . . . . . .12 4.5. Alert Reporting . . . . . . . . . . . . . . . . . . . . . 12
5. Traffic Pattern . . . . . . . . . . . . . . . . . . . . . . . .13 5. Traffic Pattern . . . . . . . . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . .13 6. Requirements of Urban LLN Applications . . . . . . . . . . . . 14
7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . .13 6.1. Scalability . . . . . . . . . . . . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . .14 6.2. Parameter Constrained Routing . . . . . . . . . . . . . . 14
9. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . .14 6.3. Support of Autonomous and Alien Configuration . . . . . . 15
10. References. . . . . . . . . . . . . . . . . . . . . . . . . . 14 6.4. Support of Highly Directed Information Flows . . . . . . . 15
10.1 Normative References. . . . . . . . . . . . . . . . . . . 14 6.5. Support of Heterogeneous Field Devices . . . . . . . . . . 15
10.2 Informative References. . . . . . . . . . . . . . . . . . 14 6.6. Support of Multicast, Anycast, and Implementation of
Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . . . . . 14 Groupcast . . . . . . . . . . . . . . . . . . . . . . . . 16
Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . . . 15 6.7. Network Dynamicity . . . . . . . . . . . . . . . . . . . . 16
6.8. Latency . . . . . . . . . . . . . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 19
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
11.1. Normative References . . . . . . . . . . . . . . . . . . . 19
11.2. Informative References . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
Intellectual Property and Copyright Statements . . . . . . . . . . 22
1. Introduction 1. Introduction
We detail here some application specific routing requirements for Urban This document details application-specific routing requirements for
Low Power and Lossy Networks (U-LLNs). A U-LLN is understood to be a Urban Low Power and Lossy Networks (U-LLNs). U-LLN use cases and
network composed of four key elements, i.e. associated routing protocol requirements will be described.
1) sensors,
2) actuators, Section 2 defines terminology useful in describing U-LLNs.
3) repeaters, and
4) access points, Section 3 provides an overview of U-LLN applications.
Section 4 describes a few typical use cases for U-LLN applications
exemplifying deployment problems and related routing issues.
Section 5 describes traffic flows that will be typical for U-LLN
applications.
Section 6 discusses the routing requirements for networks comprising
such constrained devices in a U-LLN environment. These requirements
may be overlapping requirements derived from other application-
specific requirements documents or as listed in
[I-D.culler-rl2n-routing-reqs].
Section 7 provides an overview of security considerations of U-LLN
implementations.
2. Terminology
Access Point: The access point is an infrastructure device that
connects the low power and lossy network system to a backbone
network.
Actuator: a field device that moves or controls equipment
AMI: Advanced Metering Infrastructure, part of Smart Grid.
Encompasses smart-metering applications.
DA: Distribution Automation, part of Smart Grid. Encompasses
technologies for maintenance and management of electrical
distribution systems.
Field Device: physical device placed in the urban operating
environment. Field devices include sensors, actuators and
repeaters.
LLN: Low power and Lossy Network
ROLL: Routing over Low power and Lossy networks
Smart Grid: a broad class of applications to network and automate
utility infrastructure.
Schedule: An agreed execution, wake-up, transmission, reception,
etc., time-table between two or more field devices.
U-LLN: Urban LLN
3. Overview of Urban Low Power Lossy Networks
3.1. Canonical Network Elements
A U-LLN is understood to be a network composed of four key elements,
i.e.
1. access points,
2. repeaters,
3. actuators, and
4. sensors
which communicate wirelessly. which communicate wirelessly.
3.1.1. Access Points
The access point can be used as: The access point can be used as:
1) router to a wider infrastructure (e.g. Internet),
2) data sink (e.g. data collection & processing from sensors), and 1. router to a wider infrastructure (e.g. Internet),
3) data source (e.g. instructions towards actuators).
There can be several access points connected to the same U-LLN; however, 2. data sink (e.g. data collection & processing from sensors), and
the number of access points is well below the amount of sensing nodes.
The access points are mainly static, i.e. fixed to a random or pre- 3. data source (e.g. instructions towards actuators)
planned location, but can be nomadic, i.e. in form of a walking
supervisor. Access points may but generally do not suffer from any form There can be several access points connected to the same U-LLN;
of (long-term) resource constraint, except that they need to be small however, the number of access points is well below the amount of
and sufficiently cheap. sensing nodes. The access points are mainly static, i.e. fixed to a
random or pre- planned location, but can be nomadic, i.e. in form of
a walking supervisor. Access points may but generally do not suffer
from any form of (long-term) resource constraint, except that they
need to be small and sufficiently cheap.
3.1.2. Repeaters
Repeaters generally act as relays with the aim to close coverage and Repeaters generally act as relays with the aim to close coverage and
routing gaps; examples of their use are: routing gaps; examples of their use are:
1) prolong the U-LLN's lifetime,
2) balance nodes' energy depletion, 1. prolong the U-LLN's lifetime,
3) build advanced sensing infrastructures.
There can be several repeaters supporting the same U-LLN; however, the 2. balance nodes' energy depletion,
number of repeaters is well below the amount of sensing nodes. The
repeaters are mainly static, i.e. fixed to a random or pre-planned 3. build advanced sensing infrastructures.
location. Repeaters may but generally do not suffer from any form of
(long-term) resource constraint, except that they need to be small and There can be several repeaters supporting the same U-LLN; however,
sufficiently cheap. Repeaters differ from access points in that they the number of repeaters is well below the amount of sensing nodes.
neither act as a router nor as a data sink/source. They differ from The repeaters are mainly static, i.e. fixed to a random or pre-
planned location. Repeaters may but generally do not suffer from any
form of (long-term) resource constraint, except that they need to be
small and sufficiently cheap. Repeaters differ from access points in
that they do not act as a data sink/source. They differ from
actuator and sensing nodes in that they neither control nor sense. actuator and sensing nodes in that they neither control nor sense.
Actuator nodes control urban devices upon being instructed by signaling 3.1.3. Actuators
arriving from or being forwarded by the access point(s); examples are
street or traffic lights.
The amount of actuator points is well below the number of sensing nodes.
Actuators are capable to forward data. Actuators may generally
be mobile but are likely to be static in the majority of near-future
roll-outs. Similar to the access points, actuator nodes do not suffer
from any long-term resource constraints.
Sensing nodes measure a wide gamut of physical data, including but not Actuator nodes control urban devices upon being instructed by
limited to: signaling arriving from or being forwarded by the access point(s);
1) municipal consumption data, such as the smart-metering of gas, examples are street or traffic lights. The amount of actuator points
water, electricity, waste, etc; is well below the number of sensing nodes. Some sensing nodes may
2) meteorological data, such as temperature, pressure, humidity, sun include an actuator component, e.g. an electric meter node with
integrated support for remote service disconnect. Actuators are
capable to forward data. Actuators may generally be mobile but are
likely to be static in the majority of near-future roll-outs.
Similar to the access points, actuator nodes do not suffer from any
long-term resource constraints.
3.1.4. Sensors
Sensing nodes measure a wide gamut of physical data, including but
not limited to:
1. municipal consumption data, such as smart-metering of gas, water,
electricity, waste, etc;
2. meteorological data, such as temperature, pressure, humidity, sun
index, strength and direction of wind, etc; index, strength and direction of wind, etc;
3) pollution data, such as polluting gases (SO2, NOx, CO, Ozone),
3. pollution data, such as polluting gases (SO2, NOx, CO, Ozone),
heavy metals (e.g. Mercury), pH, radioactivity, etc; heavy metals (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 electromagnetic pollution, noise levels, etc.
pollution, noise levels, etc.
Whilst millions of sensing nodes may very well be deployed in an urban A prominent example is a Smart Grid application which consists of a
area, they are likely to be associated to more than one network where city-wide network of smart meters and distribution monitoring
these networks may or may not communicate between each other. The number sensors. Smart meters in an urban Smart Grid application will
of sensing nodes connected to a single network is expected to be in the include electric, gas, and/or water meters typically administered by
order of 10^2-10^4; this is still very large and unprecedented in one or multiple utility companies. These meters will be capable of
current roll-outs. Deployment of nodes is likely to happen in batches, advanced sensing functionalities such as measuring quality of
i.e. a box of hundreds of nodes arrives and are deployed. The location service, providing granular interval data, or automating the
detection of alarm conditions. In addition they may be capable of
advanced interactive functionalities such as remote service
disconnect or remote demand reset. More advanced scenarios include
demand response systems for managing peak load, and distribution
automation systems to monitor the infrastructure which delivers
energy throughout the urban environment. Sensor nodes capable of
providing this type of functionality may sometimes be referred to as
Advanced Metering Infrastructure (AMI).
3.2. Topology
Whilst millions of sensing nodes may very well be deployed in an
urban area, they are likely to be associated to more than one network
where these networks may or may not communicate between one other.
The number of sensing nodes deployed in the urban environment in
support of some applications is expected to be in the order of 10^2-
10^7; this is still very large and unprecedented in current roll-
outs. The network MUST be capable of supporting the organization of
a large number of sensing nodes into regions containing on the order
of 10^2 to 10^4 sensing nodes each.
Deployment of nodes is likely to happen in batches, e.g. boxes of
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 or river. The nodes are highly resource placement along a road, river, or at individual residences.
constrained, i.e. cheap hardware, low memory and no infinite energy
source. Different node powering mechanisms are available, such as: 3.3. Resource Constraints
1) non-rechargeable battery;
2) rechargeable battery with regular recharging (e.g. sunlight); The nodes are highly resource constrained, i.e. cheap hardware, low
3) rechargeable battery with irregular recharging (e.g. opportunistic memory and no infinite energy source. Different node powering
energy scavenging); mechanisms are available, such as:
4) capacitive/inductive energy provision (e.g. active RFID).
The battery life-time is usually in the order of 10-15 years, rendering 1. non-rechargeable battery;
network lifetime maximization with battery-powered nodes beyond this
lifespan useless. 2. rechargeable battery with regular recharging (e.g. sunlight);
3. rechargeable battery with irregular recharging (e.g.
opportunistic energy scavenging);
4. capacitive/inductive energy provision (e.g. active RFID);
5. always on (e.g. powered electricity meter).
In the case of a battery powered sensing node, the battery life-time
is usually in the order of 10-15 years, rendering network lifetime
maximization with battery-powered nodes beyond this lifespan useless.
The physical and electromagnetic distances between the four key The physical and electromagnetic distances between the four key
elements, i.e. sensors, actuators, repeaters and access points, can elements, i.e. sensors, actuators, repeaters and access points, can
generally be very large, i.e. from several hundreds of meters to one generally be very large, i.e. from several hundreds of meters to one
kilometer. Not every field node is likely to reach the access point in kilometer. Not every field node is likely to reach the access point
a single hop, thereby requiring suitable routing protocols which manage in a single hop, thereby requiring suitable routing protocols which
the information flow in an energy-efficient manner. Sensor nodes are manage the information flow in an energy-efficient manner. Sensor
capable to forward data. nodes are capable of forwarding data.
Unlike traditional ad hoc networks, the information flow in U-LLNs is 3.4. Link Reliability
highly directional. There are three main flows to be distinguished:
1) sensed information from the sensing nodes towards one or a subset of
the access point(s);
2) query requests from the access point(s) towards the sensing nodes;
3) control information from the access point(s) towards the actuators.
Some of the flows may need the reverse route for delivering The links between the network elements are volatile due to the
acknowledgements. Finally, in the future, some direct information flows following set of non-exclusive effects:
between field devices without access points may also occur.
Sensed data is likely to be highly correlated in space, time and 1. packet errors due to wireless channel effects;
observed events; an example of the latter is when temperature and
humidity increase as the day commences. Data may be sensed and delivered
at different rates with both rates being typically fairly low, i.e. in
the range of hours, days, etc. Data may be delivered regularly according
to a schedule or a regular query; it may also be delivered irregularly
after an externally triggered query; it may also be triggered after a
sudden network-internal event or alert. The network hence needs to be
able to adjust to the varying activity duty cycles, as well as to period
and aperiodic traffic. Also, sensed data ought to be secured and
locatable.
Finally, the outdoors deployment of U-LLNs has also implications for the 2. packet errors due to medium access control;
interference temperature and hence link reliability and range if ISM
bands are to be used. For instance, if the 2.4GHz ISM band is used to
facilitate communication between U-LLN nodes, then heavily loaded WLAN
hot-spots become a detrimental performance factor jeopardizing the
reliability of the U-LLN.
Section 3 describes a few typical use cases for urban LLN applications 3. packet errors due to interference from other systems;
exemplifying deployment problems and related routing issues.
Section 4 discusses the routing requirements for networks comprising
such constrained devices in a U-LLN environment. These requirements may
be overlapping requirements derived from other application-specific
requirements documents or as listed in [I-D.culler-roll-routing-reqs].
2. Terminology 4. link unavailability due to network dynamicity; etc.
Access Point: The access point is an infrastructure device that The wireless channel causes the received power to drop below a given
connects the low power and lossy network system to a backbone threshold in a random fashion, thereby causing detection errors in
network. the receiving node. The underlying effects are path loss, shadowing
and fading.
Actuator: a field device that moves or controls equipment. Since the wireless medium is broadcast in nature, nodes in their
communication radios require suitable medium access control protocols
which are capable of resolving any arising contention. Some
available protocols may cause packets of neighbouring nodes to
collide and hence cause a link outage.
Field Device: physical device placed in the urban operating Furthermore, the outdoors deployment of U-LLNs also has implications
environment. Field devices include sensors, actuators and repeaters. for the interference temperature and hence link reliability and range
if ISM bands are to be used. For instance, if the 2.4GHz ISM band is
used to facilitate communication between U-LLN nodes, then heavily
loaded WLAN hot-spots become a detrimental performance factor
jeopardizing the functioning of the U-LLN.
LLN: Low power and Lossy Network Finally, nodes appearing and disappearing causes dynamics in the
network which can yield link outages and changes of topologies.
ROLL: Routing over Low power and Lossy networks 4. Urban LLN Application Scenarios
Schedule: An agreed execution, wake-up, transmission, reception, etc.,
time-table between two or more field devices.
Timeslot: A fixed time interval that may be used for the transmission Urban applications represent a special segment of LLNs with its
or reception of a packet between two field devices. A timeslot used unique set of requirements. To facilitate the requirements
for communications is associated with a slotted-link. discussion in Section 4, this section lists a few typical but not
exhaustive deployment problems and usage cases of U-LLN.
U-LLN: Urban LLN 4.1. Deployment of Nodes
3. Urban LLN application scenarios Contrary to other LLN applications, deployment of nodes is likely to
happen in batches out of a box. Typically, hundreds to thousands of
nodes are being shipped by the manufacturer with pre-programmed
functionalities which are then rolled-out by a service provider or
subcontracted entities. Prior or after roll-out, the network needs
to be ramped-up. This initialization phase may include, among
others, allocation of addresses, (possibly hierarchical) roles in the
network, synchronization, determination of schedules, etc.
Urban applications represent a special segment of LLNs with its unique If initialization is performed prior to roll-out, all nodes are
set of requirements. To facilitate the requirements discussion in likely to be in one another's 1-hop radio neighborhood. Pre-
Section 4, this section lists a few typical but not exhaustive programmed MAC and routing protocols may hence fail to function
deployment problems and usage cases of U-LLN. properly, thereby wasting a large amount of energy. Whilst the major
burden will be on resolving MAC conflicts, any proposed U-LLN routing
protocol needs to cater for such a case. For instance,
0-configuration and network address allocation needs to be properly
supported, etc.
3.1. Deployment of nodes After roll-out, nodes will have a finite set of one-hop neighbors,
likely of low cardinality (in the order of 5- 10). However, some
nodes may be deployed in areas where there are hundreds of
neighboring devices. In the resulting topology there may be regions
where many (redundant) paths are possible through the network. Other
regions may be dependant on critical links to achieve connectivity
with the rest of the network. Any proposed LLN routing protocol
ought to support the autonomous organization and configuration of the
network at lowest possible energy cost [Lu2007], where autonomy is
understood to be the ability of the network to operate without
external influence. For example, nodes in urban sensor nodes SHOULD
be able to:
Contrary to other LLN applications, deployment of nodes is likely to o Dynamically adapt to ever-changing conditions of communication
happen in batches out of a box. Typically, hundreds of nodes are being (possible degradation of QoS, variable nature of the traffic (real
shipped by the manufacturer with pre-programmed functionalities which time vs. non real time, sensed data vs. alerts, node mobility, a
are then rolled-out by a service provider or subcontracted entities. combination thereof, etc.),
Prior or after roll-out, the network needs to be ramped-up. This o Dynamically provision the service-specific (if not traffic-
initialization phase may include, among others, allocation of addresses, specific) resources that will comply with the QoS and security
(possibly hierarchical) roles in the network, synchronization, requirements of the service,
determination of schedules, etc.
If initialization is performed prior to roll-out, all nodes are likely o Dynamically compute, select and possibly optimize the (multiple)
to be in each others 1-hop radio neighborhood. Pre-programmed MAC and path(s) that will be used by the participating devices to forward
routing protocols may hence fail to function properly, thereby wasting a the traffic towards the actuators and/or the access point
large amount of energy. Whilst the major burden will be on resolving MAC according to the service-specific and traffic-specific QoS,
conflicts, any proposed U-LLN routing protocol needs to cater for such a traffic engineering and security policies that will have to be
case. For instance, 0-configuration and network address allocation needs enforced at the scale of a routing domain (that is, a set of
to be properly supported, etc. networking devices administered by a globally unique entity), or a
region of such domain (e.g. a metropolitan area composed of
clusters of sensors).
If initialization is performed after roll-out, nodes will have a finite The result of such organization SHOULD be that each node or set of
set of one-hop neighbors, likely of low cardinality (in the order of 5- nodes is uniquely addressable so as to facilitate the set up of
10). Any proposed LLN routing protocol ought to support the autonomous schedules, etc.
organization and configuration of the network at lowest possible energy
cost [Lu2007], where autonomy is understood to be the ability of the
network to operate without external impact. The result of such
organization ought to be that each node or sets of nodes are uniquely
addressable so as to facilitate the set up of schedules, etc.
The U-LLN routing protocol(s) MUST accommodate both unicast and The U-LLN routing protocol(s) MUST accommodate both unicast and
multicast forwarding schemes. Broadcast forwarding schemes are NOT multicast forwarding schemes. The U-LLN routing protocol(s) SHOULD
adviced in urban sensor networking environments. support anycast forwarding schemes. Unless exceptionally needed,
broadcast forwarding schemes are not advised in urban sensor
networking environments.
3.2. Association and disassociation/disappearance of nodes 4.2. Association and Disassociation/Disappearance of Nodes
After the initialization phase and possibly some operational time, new After the initialization phase and possibly some operational time,
nodes may be injected into the network as well as existing nodes removed new nodes may be injected into the network as well as existing nodes
from the network. The former might be because a removed node is replaced removed from the network. The former might be because a removed node
or denser readings/actuations are needed or routing protocols report is replaced or denser readings/actuations are needed or routing
connectivity problems. The latter might be because a node's battery is protocols report connectivity problems. The latter might be because
depleted, the node is removed for maintenance, the node is stolen or a node's battery is depleted, the node is removed for maintenance,
accidentally destroyed, etc. Differentiation should be made between node the node is stolen or accidentally destroyed, etc. Differentiation
disappearance, where the node disappears without prior notification, and SHOULD be made between node disappearance, where the node disappears
user or node-initiated disassociation ("phased-out"), where the node has without prior notification, and user or node-initiated disassociation
enough time to inform the network about its removal. ("phased-out"), where the node has enough time to inform the network
about its removal.
The protocol(s) hence ought to support the pinpointing of problematic The protocol(s) hence SHOULD support the pinpointing of problematic
routing areas as well as an organization of the network which routing areas as well as an organization of the network which
facilitates reconfiguration in the case of association and facilitates reconfiguration in the case of association and
disassociation/disappearance of nodes at lowest possible energy and disassociation/disappearance of nodes at lowest possible energy and
delay. The latter may include the change of hierarchies, routing paths, delay. The latter may include the change of hierarchies, routing
packet forwarding schedules, etc. Furthermore, to inform the access paths, packet forwarding schedules, etc. Furthermore, to inform the
point(s) of the node's arrival and association with the network as well access point(s) of the node's arrival and association with the
as freshly associated nodes about packet forwarding schedules, roles, network as well as freshly associated nodes about packet forwarding
etc, appropriate (link state) updating mechanisms ought to be supported. schedules, roles, etc, appropriate (link state) updating mechanisms
SHOULD be supported.
3.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 reporting readings on a regular basis. The frequency of data sensing and
may be different but is generally expected to be fairly low, i.e. in the reporting may be different but is generally expected to be fairly
range of once per hour, per day, etc. The ratio between data sensing and low, i.e. in the range of once per hour, per day, etc. The ratio
reporting frequencies will determine the memory and data aggregation between data sensing and reporting frequencies will determine the
capabilities of the nodes. Latency of an end-to-end delivery and memory and data aggregation capabilities of the nodes. Latency of an
acknowledgements of a successful data delivery are not vital as sensing end-to-end delivery and acknowledgements of a successful data
outages can be observed at the access point(s) - when, for instance, delivery may not be vital as sensing outages can be observed at the
there is no reading arriving from a given sensor or cluster of sensors access point(s) - when, for instance, there is no reading arriving
within a day. In this case, a query can be launched to check upon the from a given sensor or cluster of sensors within a day. In this
state and availability of a sensing node or sensing cluster. case, a query can be launched to check upon the state and
availability of a sensing node or sensing cluster.
The protocol(s) hence ought to support a large number of highly The protocol(s) hence MUST support a large number of highly
directional unicast flows from the sensing nodes or sensing clusters directional unicast flows from the sensing nodes or sensing clusters
towards the access point or highly directed multicast or anycast flows towards the access point or highly directed multicast or anycast
from the nodes towards multiple access points. flows from the nodes towards multiple access points.
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 remaining information, the frequency of reporting, the amount of energy
in the nodes, the recharging pattern of energy-scavenged nodes, etc. For remaining in the nodes, the recharging pattern of energy-scavenged
instance, temperature readings could be reported every hour via one set nodes, etc. For instance, temperature readings could be reported
of battery-powered nodes, whereas air quality indicators are reported every hour via one set of battery-powered nodes, whereas air quality
only during daytime via nodes powered by solar energy. More generally, indicators are reported only during daytime via nodes powered by
entire routing areas may be avoided at e.g. night but heavily used solar energy. More generally, entire routing areas may be avoided at
during the day when nodes are scavenging from sunlight. e.g. night but heavily used during the day when nodes are scavenging
from sunlight.
3.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 access points. For instance, it is desirable to know the level several access points. For instance, it is desirable to know the
of 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 rather urban environment. The queries' rates of occurrence are not regular
random, where heavy-tail distributions seem appropriate to model their but rather random, where heavy-tail distributions seem appropriate to
behavior. Queries do not necessarily need to be reported back to the model their behavior. Queries do not necessarily need to be reported
same access point from where the query was launched. Round-trip times, back to the same access point from where the query was launched.
i.e. from the launch of a query from an access point towards the Round-trip times, i.e. from the launch of a query from an access
delivery of the measured data to an access point, are of importance. point towards the delivery of the measured data to an access point,
However, they are not very stringent where latencies should simply be are of importance. However, they are not very stringent where
sufficiently smaller than typical reporting intervals; for instance, in latencies SHOULD simply be sufficiently smaller than typical
the order of seconds or minute. To facilitate the query process, U-LLN reporting intervals; for instance, in the order of seconds or minute.
network devices should support unicast and multicast routing To facilitate the query process, U-LLN network devices SHOULD support
capabilities. unicast and multicast routing capabilities.
The same approach is also applicable for schedule update, provisioning The same approach is also applicable for schedule update,
of patches and upgrades, etc. In this case, however, the provision of provisioning of patches and upgrades, etc. In this case, however,
acknowledgements and the support of broadcast (in addition to unicast the provision of acknowledgements and the support of unicast,
and multicast) are of importance. multicast, and anycast are of importance.
3.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 each alarm where such a classification is typically done locally within
node by means of a pre-programmed or prior diffused threshold. Note that each node by means of a pre-programmed or prior diffused threshold.
on approaching the alert threshold level, nodes may wish to change their Note that on approaching the alert threshold level, nodes may wish to
sensing and reporting cycles. An alarm is likely being registered by a change their sensing and reporting cycles. An alarm is likely being
plurality of sensing nodes where the delivery of a single alert message registered by a plurality of sensing nodes where the delivery of a
with its location of origin suffices in most cases. One example of alert single alert message with its location of origin suffices in most
reporting is if the level of toxic gases rises above a threshold, cases. One example of alert reporting is if the level of toxic gases
thereupon the sensing nodes in the vicinity of this event report the rises above a threshold, thereupon the sensing nodes in the vicinity
danger. Another example of alert reporting is when a glass container - of this event report the danger. Another example of alert reporting
equipped with a sensor measuring its level of occupancy - reports that is when a recycling glass container - equipped with a sensor
the container is full and hence needs to be emptied. measuring its level of occupancy - reports that the container is full
and hence needs to be emptied.
Routing within urban sensor networks SHOULD require the U-LLN nodes
to dynamically compute, select and install different paths towards a
same destination, depending on the nature of the traffic. From this
perspective, such nodes SHOULD inspect the contents of traffic
payload for making routing and forwarding decisions: for example, the
analysis of the traffic payload SHOULD be derived into aggregation
capabilities for the sake of forwarding efficiency.
Routes clearly need to be unicast (towards one access point) or Routes clearly need to be unicast (towards one access point) or
multicast (towards multiple access points). Delays and latencies are multicast (towards multiple access points). Delays and latencies are
important; however, again, deliveries within seconds should suffice in important; however, again, deliveries within seconds SHOULD suffice
most of the cases. in most of the cases.
4. Requirements of urban LLN applications 5. Traffic Pattern
Urban low power and lossy network applications have a number of specific Unlike traditional ad hoc networks, the information flow in U-LLNs is
requirements related to the set of operating conditions, as exemplified highly directional. There are three main flows to be distinguished:
in the previous section.
4.1. Scalability 1. sensed information from the sensing nodes towards one or a subset
of the access point(s);
2. query requests from the access point(s) towards the sensing
nodes;
3. control information from the access point(s) towards the
actuators.
Some of the flows may need the reverse route for delivering
acknowledgements. Finally, in the future, some direct information
flows between field devices without access points may also occur.
Sensed data is likely to be highly correlated in space, time and
observed events; an example of the latter is when temperature
increase and humidity decrease as the day commences. Data may be
sensed and delivered at different rates with both rates being
typically fairly low, i.e. in the range of minutes, hours, days, etc.
Data may be delivered regularly according to a schedule or a regular
query; it may also be delivered irregularly after an externally
triggered query; it may also be triggered after a sudden network-
internal event or alert. Data delivery may trigger acknowledgements
or maintenance traffic in the reverse direction. The network hence
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
be secured and locatable.
Some data delivery may have tight latency requirements, for example
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
response must arrive within a certain time in order to be useful.
The network SHOULD take into consideration that different application
traffic may require different priorities when traversing the network,
and that some traffic may be more sensitive to latency.
An U-LLN SHOULD support occasional large scale traffic flows from
sensing nodes to access points, such as 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 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 such as a capacitor or small
battery. A node MUST be able to send its own alerts toward an access
point while continuing to forward traffic on behalf of other devices
who are also experiencing an alert condition. The network MUST be
able to manage this sudden large traffic flow. It may be useful for
the routing layer to collaborate with the application layer to
perform 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
groups of actuators. For example, an AMI U-LLN supporting a city-
wide demand response system will need to efficiently broadcast demand
response control information to a large subset of actuators in the
system.
Some scenarios will require internetworking between the U-LLN and
another network, such as a home network. For example, an AMI
application that implements a demand-response system may need to
forward traffic from a utility, across the U-LLN, into a home
automation network. A typical use case would be to inform a customer
of incentives to reduce demand during peaks, or to automatically
adjust the thermostat of customers who have enrolled in such a demand
management program. Subsequent traffic may be triggered to flow back
through the U-LLN to the utility. The network SHOULD support
internetworking, while giving attention to security implications of
interfacing, for example, a home network with a utility U-LLN.
6. Requirements of Urban LLN Applications
Urban low power and lossy network applications have a number of
specific requirements related to the set of operating conditions, as
exemplified in the previous section.
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 with
the typically large urban areas - will yield extremely large network the typically large urban areas - will yield extremely large network
sizes. Current urban roll-outs are composed of sometimes more than a sizes. Current urban roll-outs are composed of sometimes more than a
hundred nodes; future roll-outs, however, may easily reach numbers in hundred nodes; future roll-outs, however, may easily reach numbers in
the tens of thousands. One of the utmost important LLN routing protocol the tens of thousands to millions. One of the utmost important LLN
design criteria is hence scalability. routing protocol design criteria is hence scalability.
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 to-be- large and increasing number of nodes without deteriorating to-be-
specified performance parameters below to-be-specified thresholds. specified performance parameters below to-be-specified thresholds.
The routing protocols(s) SHOULD support the organization of a large
number of nodes into regions of to-be-specified size.
4.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 be existence of one node for the maintenance of a routing path may not
as important as of another node; the battery scavenging methods may be as important as of another node; the battery scavenging methods
recharge the battery at regular or irregular intervals; some nodes may may recharge the battery at regular or irregular intervals; some
have a larger memory and are hence be able to store more neighborhood nodes may have a constant power source; some nodes may have a larger
information; some nodes may have a stronger CPU and are hence able to memory and are hence be able to store more neighborhood information;
perform more sophisticated data aggregation methods; etc. some nodes may have a stronger CPU and are hence able to perform more
sophisticated data aggregation methods; etc.
To this end, the routing protocol(s) MUST support parameter constrained
routing, where examples of such parameters (CPU, memory size, battery
level, etc.) have been given in the
previous paragraph.
4.3. Support of autonomous and alien configuration To this end, the routing protocol(s) MUST support parameter
constrained routing, where examples of such parameters (CPU, memory
size, battery level, etc.) have been given in the previous paragraph.
With the large number of nodes, manually configuring and troubleshooting 6.3. Support of Autonomous and Alien Configuration
each node is not possible. The network is expected to self-organize and
self-configure according to some prior defined rules and protocols, as
well as to support externally triggered configurations (for instance
through a commissioning tool which may facilitate the organization of
the network at a minimum energy cost). With the large number of nodes, manually configuring and
troubleshooting each node is not efficient. The scale and the large
number of possible topologies that may be encountered in the U-LLN
encourages the development of automated management capabilities that
may (partly) rely upon self-organizing techniques. The network is
expected to self-organize and self-configure according to some prior
defined rules and protocols, as well as to support externally
triggered configurations (for instance through a commissioning tool
which may facilitate the organization of the network at a minimum
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) self- including 0-configuration at network ramp-up, (network-internal)
organization and configuration due to topological changes, ability to self- organization and configuration due to topological changes,
support (network-external) patches and configuration updates. For the ability to support (network-external) patches and configuration
latter, the protocol(s) MUST support multi- and broad-cast addressing. updates. For the latter, the protocol(s) MUST support multi- and
The protocol(s) SHOULD also support the formation and identification of any-cast addressing. The protocol(s) SHOULD also support the
groups of field devices in the network. formation and identification of groups of field devices in the
network.
4.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 The reporting of the data readings by a large amount of spatially
dispersed nodes towards a few access points will lead to highly directed dispersed nodes towards a few access points will lead to highly
information flows. For instance, a suitable addressing scheme can be directed information flows. For instance, a suitable addressing
devised which facilitates the data flow. Also, as one gets closer to the scheme can be devised which facilitates the data flow. Also, as one
access point, the traffic concentration increases which may lead to high gets closer to the access point, the traffic concentration increases
load imbalances in node usage. which may lead to high load imbalances in node usage.
To this end, the routing protocol(s) SHOULD support and utilize the fact To this end, the routing protocol(s) SHOULD support and utilize the
of highly directed traffic flow to facilitate scalability and parameter fact of highly directed traffic flow to facilitate scalability and
constrained routing. parameter constrained routing.
4.5. Support of heterogeneous field devices 6.5. Support of Heterogeneous Field Devices
The sheer amount of different field devices will unlikely be provided by The sheer amount of different field devices will unlikely be provided
a single manufacturer. A heterogeneous roll-out with nodes using by a single manufacturer. A heterogeneous roll-out with nodes using
different physical and medium access control layers is hence likely. different physical and medium access control layers is hence likely.
To mandate fully interoperable implementations, the routing protocol(s) To mandate fully interoperable implementations, the routing
proposed in U-LLN MUST support different devices and underlying protocol(s) proposed in U-LLN MUST support different devices and
technologies without compromising the operability and energy efficiency underlying technologies without compromising the operability and
of the network. energy efficiency of the network.
4.6. Support of multicast and implementation of groupcast 6.6. Support of Multicast, Anycast, and Implementation of Groupcast
Some urban sensing systems require low-level addressing of a group of Some urban sensing systems require low-level addressing of a group of
nodes in the same subnet without any prior creation of multicast groups, nodes in the same subnet, or for a node representative of a group of
simply carrying a list of recipients in the subnet [draft-brandt-roll- nodes, without any prior creation of multicast groups, simply
home-routing-reqs-01]. carrying a list of recipients in the subnet
[I-D.brandt-roll-home-routing-reqs].
To this end, the routing protocol(s) MUST support multicast, where the
routing protocol(s) MUST provide the ability to forward a packet towards
a single field device (unicast) or a set of devices explicitly
belonging to the same group/cast (multicast). Routing protocols
activated in urban sensor networks must be able to support unicast
(traffic is sent to a single field device) and multicast (traffic is Routing protocols activated in urban sensor networks MUST support
sent to a set of devices that belong to the same group/cast) forwarding unicast (traffic is sent to a single field device), multicast
schemes. Routing protocols activated in urban sensor networks SHOULD (traffic is sent to a set of devices that are subscribed to the same
accommodate "groupcast" forwarding schemes, where traffic is sent to a multicast group), and anycast (where multiple field devices are
set of devices that implicitly belong to the same group/cast. configured to accept traffic sent on a single IP anycast address)
transmission schemes [RFC4291] [RFC1546]. Routing protocols
activated in urban sensor networks SHOULD accommodate "groupcast"
forwarding schemes, where traffic is sent to a set of devices that
implicitly belong to the same group/cast.
The support of unicast, groupcast and multicast also has an implication The support of unicast, groupcast, multicast, and anycast also has an
on the addressing scheme but is beyond the scope of this document that implication on the addressing scheme but is beyond the scope of this
focuses on the routing requirements aspects. document that focuses on the routing requirements aspects.
Note: with IP multicast, signaling mechanisms are used by a receiver to Note: with IP multicast, signaling mechanisms are used by a receiver
join a group and the sender does not know the receivers of the group. to join a group and the sender does not know the receivers of the
What is required is the ability to address a group of receivers known by group. What is required is the ability to address a group of
the sender even if the receivers do not need to know that they have been receivers known by the sender even if the receivers do not need to
grouped by the sender (since requesting each individual node to join a know that they have been grouped by the sender (since requesting each
multicast group would be very energy-consuming). individual node to join a multicast group would be very energy-
consuming).
4.7. Network dynamicity 6.7. Network Dynamicity
Although mobility is assumed to be low in urban LLNs, network dynamicity Although mobility is assumed to be low in urban LLNs, network
due to node association, disassociation and disappearance is not dynamicity due to node association, disassociation and disappearance,
negligible. This in turn impacts re-organization and re-configuration as well as long-term link perturbations is not negligible. This in
convergence as well as routing protocol convergence. turn impacts re-organization and re-configuration convergence as well
as routing protocol convergence.
To this end, local network dynamics SHOULD NOT impact the entire network To this end, local network dynamics SHOULD NOT impact the entire
to be re-organized or re-reconfigured; however, the network SHOULD be network to be re-organized or re-reconfigured; however, the network
locally optimized to cater for the encountered changes. Convergence and SHOULD be locally optimized to cater for the encountered changes.
route establishment times SHOULD be significantly lower than the inverse Convergence and route establishment times SHOULD be significantly
of the smallest reporting cycle. lower than the smallest reporting interval.
4.8. Latency 6.8. Latency
With the exception of alert reporting solutions and to a certain extent With the exception of alert reporting solutions and to a certain
queried reporting, U-LLN are delay tolerant as long as the information extent queried reporting, U-LLN are delay tolerant as long as the
arrives within a fraction of the inverse of the respective reporting information arrives within a fraction of the smallest reporting
cycle, 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.
To this end, the routing protocol(s) SHOULD support minimum latency for To this end, the routing protocol(s) SHOULD support minimum latency
alert reporting and time-critical data queries. For regular data for alert reporting and time-critical data queries. For regular data
reporting, it SHOULD support latencies not exceeding a fraction of the reporting, it SHOULD support latencies not exceeding a fraction of
inverse of the respective reporting cycle. Due to the different latency the smallest reporting interval. Due to the different latency
requirements, the routing protocol(s) SHOULD support the ability of requirements, the routing protocol(s) SHOULD support the ability of
dealing with different latency requirements. The routing protocol(s) dealing with different latency requirements. The routing protocol(s)
SHOULD also support the ability to route according to different metrics SHOULD also support the ability to route according to different
(one of which could e.g. be latency). metrics (one of which could e.g. be latency).
5. Traffic Pattern
tbd
6. Security Considerations 7. Security Considerations
As every network, U-LLNs are exposed to security threats which, if As every network, U-LLNs are exposed to security threats that MUST be
not properly addressed, exclude them to be deployed in the envisaged addressed. The wireless and distributed nature of these networks
scenarios. The wireless and distributed nature of these networks increases the spectrum of potential security threats. This is
drastically increases the spectrum of potential security threats; this further amplified by the resource constraints of the nodes, thereby
is further amplified by the serious constraints in node battery power, preventing resource intensive security approaches from being
thereby preventing previously known security approaches to be deployed. deployed. A viable security approach SHOULD be sufficiently
Above mentioned issues require special attention during the design lightweight that it may be implemented across all nodes in a U-LLN.
process, so as to facilitate a commercially attractive deployment. These issues require special attention during the design process, so
as to facilitate a commercially attractive deployment.
A secure communication in a wireless network encompasses three main A secure communication in a wireless network encompasses three main
elements, i.e. confidentiality (encryption of data), integrity elements, i.e. confidentiality (encryption of data), integrity
(correctness of data), and authentication (legitimacy of data). Since (correctness of data), and authentication (legitimacy of data).
the majority of measured data in U-LLNs is publicly available, the main
emphasis is on integrity and authenticity of data reports. U-LLN networks SHOULD support mechanisms to preserve the
Authentication can e.g. be violated if external sources insert incorrect confidentiality of the traffic that they forward. The U-LLN network
data packets; integrity can e.g. be violated if nodes start to break SHOULD NOT prevent an application from employing additional
down and hence commence measuring and relaying data incorrectly. confidentiality mechanisms.
Nonetheless, some sensor readings as well as the actuator control
signals need to be confidential. Authentication can e.g. be violated if external sources insert
incorrect data packets; integrity can e.g. be violated if nodes start
to break down and hence commence measuring and relaying data
incorrectly. Nonetheless, some sensor readings as well as the
actuator control signals need to be confidential.
The U-LLN network MUST deny all routing services to any node who has
not been authenticated to the U-LLN and authorized for the use of
routing services.
The U-LLN MUST be protected against attempts to inject false or
modified packets. For example, an attacker SHOULD be prevented from
manipulating or disabling the routing function by compromising
routing update messages. Moreover, it SHOULD NOT be possible to
coerce the network into routing packets which have been modified in
transit. To this end the routing protocol(s) MUST support message
integrity.
Further example security issues which may arise are the abnormal Further example security issues which may arise are the abnormal
behavior of nodes which exhibit an egoistic conduct, such as not obeying behavior of nodes which exhibit an egoistic conduct, such as not
network rules, or forwarding no or false packets. Other important issues obeying network rules, or forwarding no or false packets. Other
may arise in the context of Denial of Service (DoS) attacks, malicious important issues may arise in the context of Denial of Service (DoS)
address space allocations, advertisement of variable addresses, a wrong attacks, malicious address space allocations, advertisement of
neighborhood, external attacks aimed at injecting dummy traffic to drain variable addresses, a wrong neighborhood, external attacks aimed at
the network power, etc. injecting dummy traffic to drain the network power, etc.
The properties of self-configuration and self-organization which are
desirable in a U-LLN introduce additional security considerations.
Mechanisms MUST be in place to deny any rogue node which attempts to
take advantage of self-configuration and self-organization
procedures. Such attacks may attempt, for example, to cause denial
of service, drain the energy of power constrained devices, or to
hijack the routing mechanism. A node MUST authenticate itself to a
trusted node that is already associated with the U-LLN before any
self-configuration or self-organization is allowed to proceed. A
node that has already authenticated and associated with the U-LLN
MUST deny, to the maximum extent possible, the allocation of
resources to any unauthenticated peer. The routing protocol(s) MUST
deny service to any node which has not clearly established trust with
the U-LLN.
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
interface with any external network which has not established trust.
The U-LLN SHOULD be capable of limiting the resources granted in
support of an external network so as not to be vulnerable to denial
of service.
With low computation power and scarce energy resources, U-LLNs 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
generated to the whole network SHOULD be commensurate with the number
of nodes physically compromised. For example, an intruder taking
control over a single node SHOULD not have total access to, or be
able to completely deny service to the whole network.
In general, the routing protocol(s) SHOULD support the implementation
of security best practices across the U-LLN. Such an implementation
ought to include defense against, for example, eavesdropping, replay,
message insertion, modification, and man-in-the-middle attacks.
The choice of the security solutions will have an impact onto routing The choice of the security solutions will have an impact onto routing
protocol(s). To this end, routing protocol(s) proposed in the context of protocol(s). To this end, routing protocol(s) proposed in the
U-LLNs MUST support integrity measures and SHOULD support context of U-LLNs MUST support integrity measures and SHOULD support
confidentiality (security) measures. confidentiality (security) measures.
7. Open Issues 8. Open Issues
Other items to be addressed in further revisions of this document Other items to be addressed in further revisions of this document
include: include:
* node mobility; and
* traffic patterns.
8. IANA Considerations o node mobility
This document includes no request to IANA. 9. IANA Considerations
9. Acknowledgements This document makes no request of IANA.
The in-depth feedback of JP Vasseur, Cisco, and Jonathan Hui, Arch Rock, 10. Acknowledgements
is greatly appreciated.
10. References The in-depth feedback of JP Vasseur, Cisco, and Jonathan Hui, Arch
Rock, is greatly appreciated.
10.1 Normative References 11. References
[RFC2119] 11.1. Normative References
S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels",
BCP 14, RFC 2119, March 1997.
10.2 Informative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[I-D.culler-roll-routing-reqs] 11.2. Informative References
J.P. Vasseur and D. Culler, "Routing Requirements for Low-Power Wireless
Networks", draft-culler-roll-routing-reqs-00 (work in progress), July
2007.
[Lu2007] [I-D.brandt-roll-home-routing-reqs]
J.L. Lu, F. Valois, D. Barthel, M. Dohler, "FISCO: A Fully Integrated Brandt, A., "Home Automation Routing Requirement in Low
Scheme of Self-Configuration and Self-Organization for WSN," IEEE WCNC Power and Lossy Networks",
2007, Hong Kong, China, 11-15 March 2007, pp. 3370-3375. draft-brandt-roll-home-routing-reqs-01 (work in progress),
May 2008.
[draft-brandt-roll-home-routing-reqs-01] [I-D.culler-rl2n-routing-reqs]
A. Brand and J.P. Vasseur, "Home Automation Routing Requirement in Low Vasseur, J. and D. Cullerot, "Routing Requirements for Low
Power and Lossy Networks," draft-brandt-roll-home-routing-reqs-01 (work Power And Lossy Networks",
in progress), July 2007. draft-culler-rl2n-routing-reqs-01 (work in progress),
July 2007.
[Lu2007] J.L. Lu, F. Valois, D. Barthel, M. Dohler, "FISCO: A Fully
Integrated Scheme of Self-Configuration and Self-
Organization for WSN", IEEE WCNC 2007, Hong Kong, China,
11-15 March 2007, pp. 3370-3375.
[RFC1546] Partridge, C., Mendez, T., and W. Milliken, "Host
Anycasting Service", RFC 1546, November 1993.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
Authors' Addresses Authors' Addresses
Mischa Dohler Mischa Dohler (editor)
CTTC CTTC
Parc Mediterrani de la Tecnologia, Av. Canal Olimpic S/N Parc Mediterrani de la Tecnologia, Av. Canal Olimpic S/N
08860 Castelldefels, Barcelona 08860 Castelldefels, Barcelona
Spain Spain
Email: mischa.dohler@cttc.es Email: mischa.dohler@cttc.es
Thomas Watteyne Thomas Watteyne (editor)
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: thomas.watteyne@orange-ftgroup.com Email: thomas.watteyne@orange-ftgroup.com
Tim Winter (editor)
Eka Systems
20201 Century Blvd. Suite 250
Germantown, MD 20874
USA
Email: tim.winter@ekasystems.com
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
Dominique Barthel Dominique Barthel
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: Dominique.Barthel@orange-ftgroup.com Email: Dominique.Barthel@orange-ftgroup.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
skipping to change at page 16, line 36 skipping to change at line 960
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 111 change blocks. 
411 lines changed or deleted 698 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/