Urban Wireless Sensor Network (WSN) Routing Requirements in Low&nbhy;Power and Lossy NetworksCTTCParc Mediterrani de la TecnologiaAv. Canal Olimpic S/N08860 Castelldefels, BarcelonaSpainmischa.dohler@cttc.esCITI-Lab, INSA-Lyon, INRIA A4RES21 avenue Jean Capelle69621 LyonFrancethomas.watteyne@ieee.orgEka Systems20201 Century Blvd. Suite 250Germantown20874MDUSAwintert@acm.orgFrance Telecom R&D28 Chemin du Vieux Chene38243 Meylan CedexFranceDominique.Barthel@orange-ftgroup.com
Routing Area
The application-specific routing requirements for Urban
Low-Power and Lossy Networks (U-LLNs) are presented in this
document. In the near future, sensing and actuating nodes will
be placed outdoors in urban environments so as to improve
people's living conditions as well as to monitor compliance with
increasingly strict environmental laws. These field nodes are
expected to measure and report a wide gamut of data, such as
required in smart metering, waste disposal, meteorological,
pollution, and allergy reporting applications.
The majority of
these nodes are expected to communicate wirelessly over a
variety of links such as IEEE 802.15.4, low-power IEEE 802.11,
or IEEE 802.15.1 (Bluetooth), which given the limited radio
range and the large number of nodes requires the use of suitable
routing protocols. The design of such protocols will be mainly
impacted by the limited resources of the nodes (memory,
processing power, battery, etc.) and the particularities of the
outdoor urban application scenarios. As such, for a wireless
solution for Routing Over Low-Power and Lossy (ROLL) networks to
be useful, the protocol(s) ought to be energy-efficient,
scalable, and autonomous. This documents aims to specify a set
of IPv6 routing requirements reflecting these and further
U-LLNs' tailored characteristics.This document details application-specific IPv6 routing requirements
for Urban Low-Power and Lossy Networks (U-LLNs). Note that this document
details the set of IPv6 routing requirements for U-LLNs in strict
compliance with the layered IP architecture. U-LLN use cases and
associated routing protocol requirements will be described. defines terminology useful in
describing U-LLNs. provides an overview of U-LLN
applications. describes a few typical use cases
for U-LLN applications exemplifying deployment problems and related
routing issues. describes traffic flows that will be
typical for U-LLN applications. discusses the routing
requirements for networks comprising such constrained devices in a U-LLN
environment. These requirements may overlap with or be derived
from other application-specific requirements documents . provides an overview of routing
security considerations of U-LLN implementations.The terminology used in this document is consistent with and
incorporates that described in "Terminology in Low power And Lossy
Networks" . This
terminology is extended in this document as follows:Addressing and Routing scheme for forwarding
packets to at least one of the "nearest" interfaces from a group, as
described in RFC4291 and RFC1546
.Refers to the ability of a routing
protocol to independently function without requiring any external
influence or guidance. Includes self-configuration and
self-organization capabilities.Denial of Service, a class of attack that
attempts to cause resource exhaustion to the detriment of a node or
network.Industrial, Scientific, and Medical band.
This is a region of radio spectrum where low-power, unlicensed
devices may generally be used, with specific guidance from an
applicable local radio spectrum authority.Urban Low-Power and Lossy Network.Wireless Local Area Network.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.A U-LLN is understood to be a network composed of three key
elements, i.e.,sensors,actuators, androutersthat communicate wirelessly. The aim of the following
sections (, , and ) is to illustrate the functional
nature of a sensor, actuator, and router in this context. That said,
it must be understood that these functionalities are not exclusive. A
particular device may act as a simple router or may alternatively be a
router equipped with a sensing functionality, in which case it will be
seen as a "regular" router as far as routing is concerned.Sensing nodes measure a wide gamut of physical data, including
but not limited to:municipal consumption data, such as smart-metering of gas,
water, electricity, waste, etc.;meteorological data, such as temperature, pressure, humidity,
UV index, strength and direction of wind, etc.;pollution data, such as gases (sulfur dioxide (SO2),
nitrogen oxide (NOx), carbon monoxide (CO), ozone), heavy
metals (e.g., mercury), pH, radioactivity, etc.;ambient data, such as levels of allergens (pollen, dust),
electromagnetic pollution, noise, etc.Sensor nodes run applications that typically gather the
measurement data and send it to data collection and processing
application(s) on other node(s) (often outside the U-LLN).Sensor nodes are capable of forwarding data. Sensor nodes are
generally not mobile in the majority of near-future roll-outs. In
many anticipated roll-outs, sensor nodes may suffer from long-term
resource constraints.A prominent example is a "smart grid" application that consists of
a city-wide network of smart meters and distribution monitoring
sensors. Smart meters in an urban "smart grid" application will
include electric, gas, and/or water meters typically administered by
one or multiple utility companies. These meters will be capable of
advanced sensing functionalities such as measuring the quality of
electrical service provided to a customer, providing granular
interval data, or automating the detection of alarm conditions. In
addition, they may be capable of advanced interactive
functionalities, which may invoke an actuator component, 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
that 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).Actuator nodes are capable of controlling urban devices; examples
are street or traffic lights. They run applications that receive
instructions from control applications on other nodes (possibly
outside the U-LLN). The amount of actuator points is well below the
number of sensing nodes. Some sensing nodes may include an actuator
component, e.g., an electric meter node with integrated support for
remote service disconnect. Actuators are capable of forwarding data.
Actuators are not likely to be mobile in the majority of near-future
roll-outs. Actuator nodes may also suffer from long-term resource
constraints, e.g., in the case where they are battery powered.Routers generally act to close coverage and routing gaps within
the interior of the U-LLN; examples of their use are:prolong the U-LLN's lifetime,balance nodes' energy depletion, andbuild advanced sensing infrastructures.There can be several routers supporting the same U-LLN;
however, 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-planned location. Routers may, but generally do not, suffer
from any form of (long-term) resource constraint, except that they
need to be small and sufficiently cheap. Routers differ from
actuator and sensing nodes in that they neither control nor sense.
That being said, a sensing node or actuator may also be a router
within the U-LLN.Some routers provide access to wider infrastructures, such as the
Internet, and are named Low-Power and Lossy Network Border Routers
(LBRs) in that context.LBR nodes in particular may also run applications that
communicate with sensor and actuator nodes (e.g., collecting and
processing data from sensor applications, or sending instructions to
actuator applications).Whilst millions of sensing nodes may very well be deployed in an
urban area, they are likely to be associated with more than one
network. These networks may or may not communicate between one
another. 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
to 10^7; this is still very large and unprecedented in current
roll-outs.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.,
placement along a road, river, or at individual residences.The nodes are highly resource constrained, i.e., cheap hardware, low
memory, and no infinite energy source. Different node powering
mechanisms are available, such as:non-rechargeable battery;rechargeable battery with regular recharging (e.g.,
sunlight);rechargeable battery with irregular recharging (e.g.,
opportunistic energy scavenging);capacitive/inductive energy provision (e.g., passive Radio
Frequency IDentification (RFID));always on (e.g., powered electricity meter).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 maximization with battery-powered nodes beyond this lifespan
useless.The physical and electromagnetic distances between the three key
elements, i.e., sensors, actuators, and routers, can generally be very
large, i.e., from several hundreds of meters to one kilometer. Not
every field node is likely to reach the LBR in a single hop, thereby
requiring suitable routing protocols that manage the information flow
in an energy-efficient manner.The links between the network elements are volatile due to the
following set of non-exclusive effects: packet errors due to wireless channel effects;packet errors due to MAC (Medium Access Control) (e.g.,
collision);packet errors due to interference from other systems;link unavailability due to network dynamicity; etc.The wireless channel causes the received power to drop below a
given threshold in a random fashion, thereby causing detection errors
in the receiving node. The underlying effects are path loss, shadowing
and fading.Since the wireless medium is broadcast in nature, nodes in their
communication radios require suitable medium access control protocols
that are capable of resolving any arising contention. Some available
protocols may not be able to prevent packets of neighboring nodes from
colliding, possibly leading to a high Packet Error Rate (PER) and
causing a link outage.Furthermore, the outdoor deployment of U-LLNs also has implications
for the interference temperature and hence link reliability and range
if Industrial, Scientific, and Medical (ISM) bands are to be used. For
instance, if the 2.4 GHz ISM band is used to facilitate communication
between U-LLN nodes, then heavily loaded Wireless Local Area Network
(WLAN) hot-spots may become a detrimental performance factor, leading
to high PER and jeopardizing the functioning of the U-LLN.Finally, nodes appearing and disappearing causes dynamics in the
network that can yield link outages and changes of topologies.Urban applications represent a special segment of LLNs with its
unique set of requirements. To facilitate the requirements discussion in
, this section lists a few typical
but not exhaustive deployment problems and usage cases of U-LLN.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 to 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.If initialization is performed prior to roll-out, all nodes are
likely to be in one another's one-hop radio neighborhood. Pre-programmed
Media Access Control (MAC) and routing protocols may hence fail to
function 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,
zero-configuration and network address allocation needs to be properly
supported, etc.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
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 dependent on critical links to achieve connectivity with the rest
of the network. Any proposed LLN routing protocol ought to support the
autonomous self-organization and self-configuration of the network at
lowest possible energy cost , where
autonomy is understood to be the ability of the network to operate
without external influence. The result of such organization should be
that each node or set of nodes is uniquely addressable so as to
facilitate the set up of schedules, etc.Unless exceptionally needed, broadcast forwarding schemes are not
advised in urban sensor networking environments.After the initialization phase and possibly some operational time,
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
is replaced as part of maintenance, or new nodes are added because
more sensors for denser readings/actuations are needed, or because
routing protocols report connectivity problems. The latter might be
because a node's battery is depleted, the node is removed for
maintenance, the node is stolen or accidentally destroyed, etc.The protocol(s) hence should be able to convey information about
malfunctioning nodes that may affect or jeopardize the overall
routing efficiency, so that self-organization and self-configuration
capabilities of the sensor network might be solicited to facilitate
the appropriate reconfiguration. This information may include, e.g.,
exact or relative geographical position, etc. The reconfiguration may
include the change of hierarchies, routing paths, packet forwarding
schedules, etc. Furthermore, to inform the LBR(s) of the node's
arrival and association with the network as well as freshly associated
nodes about packet forwarding schedules, roles, etc., appropriate
updating mechanisms should be supported.The majority of sensing nodes will be configured to report their
readings on a regular basis. The frequency of data sensing and
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 between
data sensing and reporting frequencies will determine the memory and
data aggregation capabilities of the nodes. Latency of an end-to-end
delivery and acknowledgements of a successful data delivery may not be
vital as sensing outages can be observed at data collection
applications -- when, for instance, there is no reading 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 availability of a sensing
node or sensing cluster.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
unicast flows from the sensing nodes or sensing clusters are likely to
transit through a LBR. Thus, the protocol(s) should be optimized to
support a large number of unicast flows from the sensing nodes or
sensing clusters towards a LBR, or highly directed multicast or
anycast flows from the nodes towards multiple LBRs.Route computation and selection may depend on the transmitted
information, the frequency of reporting, the amount of energy
remaining in the nodes, the recharging pattern of energy-scavenged
nodes, etc. For instance, temperature readings could be reported every
hour via one set of battery-powered nodes, whereas air quality
indicators are reported only during the daytime via nodes powered by solar
energy. More generally, entire routing areas may be avoided (e.g., at
night) but heavily used during the day when nodes are scavenging from
sunlight.Occasionally, network-external data queries can be launched by one
or several applications. For instance, it is desirable to know 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
but rather random, where heavy-tail distributions seem appropriate to
model their behavior. Queries do not necessarily need to be reported
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
of the measured data to a node, are of importance. However, they are
not very stringent where latencies should simply be sufficiently
smaller than typical reporting intervals; for instance, in the order
of seconds or minutes. The routing protocol(s) should consider the
selection of paths with appropriate (e.g., latency) metrics to support
queried measurement reporting. To facilitate the query process, U-LLN
devices should support unicast and multicast routing
capabilities.The same approach is also applicable for schedule update,
provisioning of patches and upgrades, etc. In this case, however, the
provision of acknowledgements and the support of unicast, multicast,
and anycast are of importance.Rarely, the sensing nodes will measure an event that classifies as
an alarm where such a classification is typically done locally within
each node by means of a pre-programmed or prior-diffused threshold.
Note that on approaching the alert threshold level, nodes may wish to
change their sensing and reporting cycles. An alarm is likely being
registered by a plurality of sensing nodes where the delivery of a
single alert message with its location of origin suffices in most, but
not all, cases. One example of alert reporting is if the level of
toxic gases rises above a threshold; thereupon, the sensing nodes in
the vicinity of this event report the danger. Another example of alert
reporting is when a recycling glass container -- equipped with a sensor
measuring its level of occupancy -- reports that the container is full
and hence needs to be emptied.Routes clearly need to be unicast (towards one LBR) or multicast
(towards multiple LBRs). Delays and latencies are important; however,
for a U-LLN deployed in support of a typical application, deliveries
within seconds should suffice in most of the cases.Unlike traditional ad hoc networks, the information flow in U-LLNs is
highly directional. There are three main flows to be distinguished:
sensed information from the sensing nodes to applications outside
the U-LLN, going through one or a subset of the LBR(s);query requests from applications outside the U-LLN, going through
the LBR(s) towards the sensing nodes;control information from applications outside the U-LLN, going
through the LBR(s) towards the actuators.Some of the flows may need the reverse route for delivering
acknowledgements. Finally, in the future, some direct information flows
between field devices without LBRs 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. Schedules
may be driven by, for example, a smart-metering application where data
is expected to be delivered every hour, or an environmental monitoring
application where a battery-powered node is expected to report its
status at a specific time once a day. 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 in the selection of a route when traversing
the network, and that some traffic may be more sensitive to latency.A U-LLN should support occasional large-scale traffic flows from
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
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 be 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 LBR while continuing to forward traffic on behalf of other
devices that are also experiencing an alert condition. The network needs
to be able to manage this sudden large traffic flow.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-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.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 sections.The large and diverse measurement space of U-LLN nodes -- coupled
with the typically large urban areas -- will yield extremely large
network sizes. Current urban roll-outs are composed of sometimes more
than one hundred nodes; future roll-outs, however, may easily reach
numbers in the tens of thousands to millions. One of the utmost
important LLN routing protocol design criteria is hence
scalability.The routing protocol(s) 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.The routing protocol(s) MUST be scalable so as to accommodate a
very large and increasing number of nodes without deteriorating
selected performance parameters below configurable thresholds. The
routing protocols(s) SHOULD support the organization of a large number
of nodes into regions of configurable size.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
as important as of another node; the battery scavenging
methods may recharge the battery at regular or irregular intervals;
some nodes may have a constant power source; some nodes may
have a larger memory and are hence be able to store more
neighborhood information; 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. In other words, the routing
protocol MUST be able to advertise node capabilities that will
be exclusively used by the routing protocol engine for routing
decision. For the sake of example, such a capability could be
related to the node capability itself (e.g., remaining power)
or some application that could influence routing (e.g.,
capability to aggregate data).Routing within urban sensor networks SHOULD require the U-LLN nodes
to dynamically compute, select, and install different paths towards the
same destination, depending on the nature of the traffic. Such
functionality in support of, for example, data aggregation, may imply
use of some mechanisms to mark/tag the traffic for appropriate routing
decision using the IPv6 packet format (e.g., use of Diffserv Code Point (DSCP), Flow Label)
based on an upper-layer marking decision. From this perspective, such
nodes MAY use node capabilities (e.g., to act as an aggregator) in
conjunction with the anycast endpoints and packet marking to route the
traffic.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
that 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 including zero-configuration at network ramp-up,
(network-internal) self-organization and configuration due to
topological changes, and the ability to support
(network-external) patches and configuration updates. For the
latter, the protocol(s) MUST support multicast and anycast
addressing. The protocol(s) SHOULD also support the formation
and identification of groups of field devices in the
network.The routing protocol(s) SHOULD be able to dynamically adapt, e.g.,
through the application of appropriate routing metrics, to
ever-changing conditions of communication (possible degradation of
quality of service (QoS), variable nature of the traffic (real-time versus non-real-time,
sensed data versus alerts), node mobility, a combination thereof,
etc.).The routing protocol(s) SHOULD be able to dynamically compute,
select, and possibly optimize the (multiple) path(s) that will be used
by the participating devices to forward the traffic towards the
actuators and/or a LBR according to the service-specific and
traffic-specific QoS, traffic engineering, and routing security
policies that will have to be enforced at the scale of a routing
domain (that is, a set of networking devices administered by a
globally unique entity), or a region of such domain (e.g., a
metropolitan area composed of clusters of sensors).As pointed out in , it is not uncommon to gather
data on a few servers located outside of the U-LLN. In this case, the
reporting of the data readings by a large amount of spatially
dispersed nodes towards a few LBRs will lead to highly directed
information flows. For instance, a suitable addressing scheme can be
devised that facilitates the data flow. Also, as one gets closer to
the LBR, the traffic concentration increases, which may lead
to high load imbalances in node usage.To this end, the routing protocol(s) SHOULD support and utilize the
fact of a large number of highly directed traffic flows to facilitate
scalability and parameter-constrained routing.The routing protocol MUST be able to accommodate traffic bursts by
dynamically computing and selecting multiple paths towards the same
destination.Routing protocols activated in urban sensor networks MUST support
unicast (traffic is sent to a single field device), multicast (traffic
is sent to a set of devices that are subscribed to the same multicast
group), and anycast (where multiple field devices are configured to
accept traffic sent on a single IP anycast address) transmission
schemes.The support of unicast, multicast, and anycast also has an
implication on the addressing scheme, but it is beyond the scope of this
document that focuses on the routing requirements.Some urban sensing systems may require low-level addressing of a
group of nodes in the same subnet, or for a node representative of a
group of nodes, without any prior creation of multicast groups. Such
addressing schemes, where a sender can form an addressable group of
receivers, are not currently supported by IPv6, and not further
discussed in this specification .The network SHOULD support internetworking when identical protocols
are used, while giving attention to routing security implications of
interfacing, for example, a home network with a utility U-LLN. The
network may support the ability to interact with another network using
a different protocol, for example, by supporting route
redistribution.Although mobility is assumed to be low in urban LLNs, network
dynamicity due to node association, disassociation, and disappearance,
as well as long-term link perturbations is not negligible. This in
turn impacts reorganization and reconfiguration convergence as well as
routing protocol convergence.To this end, local network dynamics SHOULD NOT impact the entire
network to be reorganized or re-reconfigured; however, the network
SHOULD be locally optimized to cater for the encountered changes. The
routing protocol(s) SHOULD support appropriate mechanisms in order to
be informed of the association, disassociation, and disappearance of
nodes. The routing protocol(s) SHOULD support appropriate updating
mechanisms in order to be informed of changes in connectivity. The
routing protocol(s) SHOULD use this information to initiate protocol-specific mechanisms for reorganization and reconfiguration as
necessary to maintain overall routing efficiency. Convergence and
route establishment times SHOULD be significantly lower than the
smallest reporting interval.Differentiation SHOULD be made between node disappearance, where
the node disappears without prior notification, and user- or
node-initiated disassociation ("phased-out"), where the node has
enough time to inform the network about its pending removal.With the exception of alert-reporting solutions and (to a certain
extent) queried reporting, U-LLNs are delay tolerant as long as the
information arrives within a fraction of the smallest reporting
interval, e.g., a few seconds if reporting is done every 4 hours.The routing protocol(s) SHOULD also support the ability to route
according to different metrics (one of which could, e.g., be
latency).As every network, U-LLNs are exposed to routing security threats that
need to be addressed. The wireless and distributed nature of these
networks increases the spectrum of potential routing security threats.
This is further amplified by the resource constraints of the nodes,
thereby preventing resource-intensive routing security approaches from
being deployed. A viable routing security approach SHOULD be
sufficiently lightweight that it may be implemented across all nodes in
a U-LLN. These issues require special attention during the design
process, so as to facilitate a commercially attractive deployment.The U-LLN MUST deny any node that has not been authenticated
to the U-LLN and authorized to participate to the routing decision
process.An attacker SHOULD be prevented from manipulating or disabling the
routing function, for example, by compromising routing control messages.
To this end, the routing protocol(s) MUST support message integrity.Further examples of routing security issues that may arise are the
abnormal behavior of nodes that exhibit an egoistic conduct, such as
not obeying network rules or forwarding no or false packets. Other
important issues may arise in the context of denial-of-service (DoS)
attacks, malicious address space allocations, advertisement of variable
addresses, a wrong neighborhood, etc. The routing protocol(s) SHOULD
support defense against DoS attacks and other attempts to maliciously or
inadvertently cause the mechanisms of the routing protocol(s) to over-consume
the limited resources of LLN nodes, e.g., by constructing forwarding
loops or causing excessive routing protocol overhead traffic, etc.The properties of self-configuration and self-organization that are
desirable in a U-LLN introduce additional routing security
considerations. Mechanisms MUST be in place to deny any node that
attempts to take malicious advantage of self-configuration and
self-organization procedures. Such attacks may attempt, for example, to
cause DoS, 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 the former can take
part in self-configuration or self-organization. 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 that 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 that 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 DoS.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 be able to completely deny service to the
whole network.In general, the routing protocol(s) SHOULD support the implementation
of routing 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 routing security solutions will have an impact on
the routing protocol(s). To this end, routing protocol(s) proposed in the
context of U-LLNs MUST support authentication and integrity measures and
SHOULD support confidentiality (routing security) measures.FISCO: A Fully Integrated Scheme of Self-Configuration and
Self-Organization for WSNBuilding Automation Routing Requirements in Low Power and Lossy NetworksHome Automation Routing Requirements in Low Power and Lossy NetworksIndustrial Routing Requirements in Low Power and Lossy NetworksTerminology in Low power And Lossy NetworksThe in-depth feedback of JP Vasseur, Jonathan Hui, Iain Calder, and
Pasi Eronen is greatly appreciated.