<pre>Network Working Group                                     M. Dohler, Ed.
Request for Comments: 5548                                          CTTC
Category: Informational                                 T. Watteyne, Ed.
                                                       BSAC, UC Berkeley
                                                          T. Winter, Ed.
                                                             Eka Systems
                                                         D. Barthel, Ed.
                                                      France Telecom R&amp;D
                                                                May 2009


      <span class="h1">Routing Requirements for Urban Low-Power and Lossy Networks</span>

Status of This Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Abstract

   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 (for example, the data required by applications that perform
   smart-metering or that monitor meteorological, pollution, and allergy
   conditions).  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



<span class="grey">Dohler, et al.               Informational                      [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc5548">RFC 5548</a>            Routing Requirements for U-LLNs             May 2009</span>


   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.

Table of Contents

   <a href="#section-1">1</a>. Introduction ....................................................<a href="#page-3">3</a>
   <a href="#section-2">2</a>. Terminology .....................................................<a href="#page-3">3</a>
      <a href="#section-2.1">2.1</a>. Requirements Language ......................................<a href="#page-4">4</a>
   <a href="#section-3">3</a>. Overview of Urban Low-Power and Lossy Networks ..................<a href="#page-4">4</a>
      <a href="#section-3.1">3.1</a>. Canonical Network Elements .................................<a href="#page-4">4</a>
           <a href="#section-3.1.1">3.1.1</a>. Sensors .............................................<a href="#page-4">4</a>
           <a href="#section-3.1.2">3.1.2</a>. Actuators ...........................................<a href="#page-5">5</a>
           <a href="#section-3.1.3">3.1.3</a>. Routers .............................................<a href="#page-6">6</a>
      <a href="#section-3.2">3.2</a>. Topology ...................................................<a href="#page-6">6</a>
      <a href="#section-3.3">3.3</a>. Resource Constraints .......................................<a href="#page-7">7</a>
      <a href="#section-3.4">3.4</a>. Link Reliability ...........................................<a href="#page-7">7</a>
   <a href="#section-4">4</a>. Urban LLN Application Scenarios .................................<a href="#page-8">8</a>
      <a href="#section-4.1">4.1</a>. Deployment of Nodes ........................................<a href="#page-8">8</a>
      <a href="#section-4.2">4.2</a>. Association and Disassociation/Disappearance of Nodes ......<a href="#page-9">9</a>
      <a href="#section-4.3">4.3</a>. Regular Measurement Reporting ..............................<a href="#page-9">9</a>
      <a href="#section-4.4">4.4</a>. Queried Measurement Reporting .............................<a href="#page-10">10</a>
      <a href="#section-4.5">4.5</a>. Alert Reporting ...........................................<a href="#page-11">11</a>
   <a href="#section-5">5</a>. Traffic Pattern ................................................<a href="#page-11">11</a>
   <a href="#section-6">6</a>. Requirements of Urban-LLN Applications .........................<a href="#page-13">13</a>
      <a href="#section-6.1">6.1</a>. Scalability ...............................................<a href="#page-13">13</a>
      <a href="#section-6.2">6.2</a>. Parameter-Constrained Routing .............................<a href="#page-13">13</a>
      <a href="#section-6.3">6.3</a>. Support of Autonomous and Alien Configuration .............<a href="#page-14">14</a>
      <a href="#section-6.4">6.4</a>. Support of Highly Directed Information Flows ..............<a href="#page-15">15</a>
      <a href="#section-6.5">6.5</a>. Support of Multicast and Anycast ..........................<a href="#page-15">15</a>
      <a href="#section-6.6">6.6</a>. Network Dynamicity ........................................<a href="#page-16">16</a>
      <a href="#section-6.7">6.7</a>. Latency ...................................................<a href="#page-16">16</a>
   <a href="#section-7">7</a>. Security Considerations ........................................<a href="#page-16">16</a>
   <a href="#section-8">8</a>. References .....................................................<a href="#page-18">18</a>
      <a href="#section-8.1">8.1</a>. Normative References ......................................<a href="#page-18">18</a>
      <a href="#section-8.2">8.2</a>. Informative References ....................................<a href="#page-18">18</a>
   <a href="#appendix-A">Appendix A</a>.  Acknowledgements .....................................<a href="#page-20">20</a>
   <a href="#appendix-B">Appendix B</a>.  Contributors .........................................<a href="#page-20">20</a>











<span class="grey">Dohler, et al.               Informational                      [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc5548">RFC 5548</a>            Routing Requirements for U-LLNs             May 2009</span>


<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>.  Introduction</span>

   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.

   <a href="#section-2">Section 2</a> defines terminology useful in describing U-LLNs.

   <a href="#section-3">Section 3</a> provides an overview of U-LLN applications.

   <a href="#section-4">Section 4</a> describes a few typical use cases for U-LLN applications
   exemplifying deployment problems and related routing issues.

   <a href="#section-5">Section 5</a> describes traffic flows that will be typical for U-LLN
   applications.

   <a href="#section-6">Section 6</a> 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 [<a href="#ref-ROLL-HOME" title="&quot;Home Automation Routing Requirements in Low Power and Lossy Networks&quot;">ROLL-HOME</a>] [<a href="#ref-ROLL-INDUS" title="&quot;Industrial Routing Requirements in Low Power and Lossy Networks&quot;">ROLL-INDUS</a>] [<a href="#ref-ROLL-BUILD" title="&quot;Building Automation Routing Requirements in Low Power and Lossy Networks&quot;">ROLL-BUILD</a>].

   <a href="#section-7">Section 7</a> provides an overview of routing security considerations of
   U-LLN implementations.

<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>.  Terminology</span>

   The terminology used in this document is consistent with and
   incorporates that described in "Terminology in Low power And Lossy
   Networks" [<a href="#ref-ROLL-TERM" title="&quot;Terminology in Low power And Lossy Networks&quot;">ROLL-TERM</a>].  This terminology is extended in this document
   as follows:

   Anycast:  Addressing and Routing scheme for forwarding packets to at
             least one of the "nearest" interfaces from a group, as
             described in <a href="./rfc4291">RFC4291</a> [<a href="./rfc4291" title="&quot;IP Version 6 Addressing Architecture&quot;">RFC4291</a>] and <a href="./rfc1546">RFC1546</a> [<a href="./rfc1546" title="&quot;Host Anycasting Service&quot;">RFC1546</a>].

   Autonomous:  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.

   DoS:  Denial of Service, a class of attack that attempts to cause
         resource exhaustion to the detriment of a node or network.







<span class="grey">Dohler, et al.               Informational                      [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc5548">RFC 5548</a>            Routing Requirements for U-LLNs             May 2009</span>


   ISM band:  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.

   U-LLN:  Urban Low-Power and Lossy Network.

   WLAN: Wireless Local Area Network.

<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>.  Requirements Language</span>

   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 <a href="./rfc2119">RFC 2119</a> [<a href="./rfc2119" title="&quot;Key words for use in RFCs to Indicate Requirement Levels&quot;">RFC2119</a>].

<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>.  Overview of Urban Low-Power and Lossy Networks</span>

<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>.  Canonical Network Elements</span>

   A U-LLN is understood to be a network composed of three key elements,
   i.e.,

   1.  sensors,

   2.  actuators, and

   3.  routers

   that communicate wirelessly.  The aim of the following sections
   (3.1.1, 3.1.2, and 3.1.3) 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.

<span class="h4"><a class="selflink" id="section-3.1.1" href="#section-3.1.1">3.1.1</a>.  Sensors</span>

   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, UV
       index, strength and direction of wind, etc.;





<span class="grey">Dohler, et al.               Informational                      [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc5548">RFC 5548</a>            Routing Requirements for U-LLNs             May 2009</span>


   3.  pollution data, such as gases (sulfur dioxide, nitrogen oxide,
       carbon monoxide, ozone), heavy metals (e.g., mercury), pH,
       radioactivity, etc.;

   4.  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).

<span class="h4"><a class="selflink" id="section-3.1.2" href="#section-3.1.2">3.1.2</a>.  Actuators</span>

   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.






<span class="grey">Dohler, et al.               Informational                      [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc5548">RFC 5548</a>            Routing Requirements for U-LLNs             May 2009</span>


<span class="h4"><a class="selflink" id="section-3.1.3" href="#section-3.1.3">3.1.3</a>.  Routers</span>

   Routers generally act to close coverage and routing gaps within the
   interior of the U-LLN; examples of their use are:

   1.  prolong the U-LLN's lifetime,

   2.  balance nodes' energy depletion, and

   3.  build 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).

<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>.  Topology</span>

   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.







<span class="grey">Dohler, et al.               Informational                      [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc5548">RFC 5548</a>            Routing Requirements for U-LLNs             May 2009</span>


<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>.  Resource Constraints</span>

   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:

   1.  non-rechargeable battery;

   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., passive Radio
       Frequency IDentification (RFID));

   5.  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.

<span class="h3"><a class="selflink" id="section-3.4" href="#section-3.4">3.4</a>.  Link Reliability</span>

   The links between the network elements are volatile due to the
   following set of non-exclusive effects:

   1.  packet errors due to wireless channel effects;

   2.  packet errors due to MAC (Medium Access Control) (e.g.,
       collision);

   3.  packet errors due to interference from other systems;

   4.  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.




<span class="grey">Dohler, et al.               Informational                      [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc5548">RFC 5548</a>            Routing Requirements for U-LLNs             May 2009</span>


   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.

<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>.  Urban LLN Application Scenarios</span>

   Urban applications represent a special segment of LLNs with its
   unique set of requirements.  To facilitate the requirements
   discussion in <a href="#section-6">Section 6</a>, this section lists a few typical but not
   exhaustive deployment problems and usage cases of U-LLN.

<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>.  Deployment of Nodes</span>

   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.






<span class="grey">Dohler, et al.               Informational                      [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc5548">RFC 5548</a>            Routing Requirements for U-LLNs             May 2009</span>


   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 [<a href="#ref-Lu2007" title="&quot;FISCO: A Fully Integrated Scheme of Self-Configuration and Self-Organization for WSN&quot;">Lu2007</a>],
   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.

<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>.  Association and Disassociation/Disappearance of Nodes</span>

   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.

<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>.  Regular Measurement Reporting</span>

   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



<span class="grey">Dohler, et al.               Informational                      [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc5548">RFC 5548</a>            Routing Requirements for U-LLNs             May 2009</span>


   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 energy from sunlight.

<span class="h3"><a class="selflink" id="section-4.4" href="#section-4.4">4.4</a>.  Queried Measurement Reporting</span>

   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.



<span class="grey">Dohler, et al.               Informational                     [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc5548">RFC 5548</a>            Routing Requirements for U-LLNs             May 2009</span>


<span class="h3"><a class="selflink" id="section-4.5" href="#section-4.5">4.5</a>.  Alert Reporting</span>

   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.

<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>.  Traffic Pattern</span>

   Unlike traditional ad hoc networks, the information flow in U-LLNs is
   highly directional.  There are three main flows to be distinguished:

   1.  sensed information from the sensing nodes to applications outside
       the U-LLN, going through one or a subset of the LBR(s);

   2.  query requests from applications outside the U-LLN, going through
       the LBR(s) towards the sensing nodes;

   3.  control information from applications outside the U-LLN, going
       through the LBR(s) towards the actuators.

   Some of the flows may need the reverse route for delivering
   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



<span class="grey">Dohler, et al.               Informational                     [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc5548">RFC 5548</a>            Routing Requirements for U-LLNs             May 2009</span>


   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.






<span class="grey">Dohler, et al.               Informational                     [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc5548">RFC 5548</a>            Routing Requirements for U-LLNs             May 2009</span>


<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>.  Requirements of Urban-LLN Applications</span>

   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.

<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>.  Scalability</span>

   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.

<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>.  Parameter-Constrained Routing</span>

   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 energy-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).





<span class="grey">Dohler, et al.               Informational                     [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc5548">RFC 5548</a>            Routing Requirements for U-LLNs             May 2009</span>


   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.

<span class="h3"><a class="selflink" id="section-6.3" href="#section-6.3">6.3</a>.  Support of Autonomous and Alien Configuration</span>

   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






<span class="grey">Dohler, et al.               Informational                     [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc5548">RFC 5548</a>            Routing Requirements for U-LLNs             May 2009</span>


   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).

<span class="h3"><a class="selflink" id="section-6.4" href="#section-6.4">6.4</a>.  Support of Highly Directed Information Flows</span>

   As pointed out in <a href="#section-4.3">Section 4.3</a>, 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
   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.

<span class="h3"><a class="selflink" id="section-6.5" href="#section-6.5">6.5</a>.  Support of Multicast and Anycast</span>

   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 [<a href="#ref-ROLL-HOME" title="&quot;Home Automation Routing Requirements in Low Power and Lossy Networks&quot;">ROLL-HOME</a>].

   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




<span class="grey">Dohler, et al.               Informational                     [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc5548">RFC 5548</a>            Routing Requirements for U-LLNs             May 2009</span>


   network may support the ability to interact with another network
   using a different protocol, for example, by supporting route
   redistribution.

<span class="h3"><a class="selflink" id="section-6.6" href="#section-6.6">6.6</a>.  Network Dynamicity</span>

   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.

<span class="h3"><a class="selflink" id="section-6.7" href="#section-6.7">6.7</a>.  Latency</span>

   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).

<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>.  Security Considerations</span>

   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



<span class="grey">Dohler, et al.               Informational                     [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc5548">RFC 5548</a>            Routing Requirements for U-LLNs             May 2009</span>


   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.





<span class="grey">Dohler, et al.               Informational                     [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc5548">RFC 5548</a>            Routing Requirements for U-LLNs             May 2009</span>


   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.

<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>.  References</span>

<span class="h3"><a class="selflink" id="section-8.1" href="#section-8.1">8.1</a>.  Normative References</span>

   [<a id="ref-RFC2119">RFC2119</a>]     Bradner, S., "Key words for use in RFCs to Indicate
                 Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.

<span class="h3"><a class="selflink" id="section-8.2" href="#section-8.2">8.2</a>.  Informative References</span>

   [<a id="ref-Lu2007">Lu2007</a>]      Lu, JL., Valois, F., Barthel, D., and M. Dohler,
                 "FISCO: A Fully Integrated Scheme of Self-Configuration
                 and Self-Organization for WSN", 11-15 March 2007,
                 pp. 3370-3375, IEEE WCNC 2007, Hong Kong, China.

   [<a id="ref-RFC1546">RFC1546</a>]     Partridge, C., Mendez, T., and W. Milliken, "Host
                 Anycasting Service", <a href="./rfc1546">RFC 1546</a>, November 1993.

   [<a id="ref-RFC4291">RFC4291</a>]     Hinden, R. and S. Deering, "IP Version 6 Addressing
                 Architecture", <a href="./rfc4291">RFC 4291</a>, February 2006.

   [<a id="ref-ROLL-BUILD">ROLL-BUILD</a>]  Martocci, J., Ed., De Mil, P., Vermeylen, W., and N.
                 Riou, "Building Automation Routing Requirements in Low
                 Power and Lossy Networks", Work in Progress,
                 February 2009.

   [<a id="ref-ROLL-HOME">ROLL-HOME</a>]   Brandt, A. and G. Porcu, "Home Automation Routing
                 Requirements in Low Power and Lossy Networks", Work
                 in Progress, November 2008.



<span class="grey">Dohler, et al.               Informational                     [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc5548">RFC 5548</a>            Routing Requirements for U-LLNs             May 2009</span>


   [<a id="ref-ROLL-INDUS">ROLL-INDUS</a>]  Pister, K., Ed., Thubert, P., Ed., Dwars, S., and T.
                 Phinney, "Industrial Routing Requirements in Low Power
                 and Lossy Networks", Work in Progress, April 2009.

   [<a id="ref-ROLL-TERM">ROLL-TERM</a>]   Vasseur, J., "Terminology in Low power And Lossy
                 Networks", Work in Progress, October 2008.













































<span class="grey">Dohler, et al.               Informational                     [Page 19]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-20" ></span>
<span class="grey"><a href="./rfc5548">RFC 5548</a>            Routing Requirements for U-LLNs             May 2009</span>


<span class="h2"><a class="selflink" id="appendix-A" href="#appendix-A">Appendix A</a>.  Acknowledgements</span>

   The in-depth feedback of JP Vasseur, Jonathan Hui, Iain Calder, and
   Pasi Eronen is greatly appreciated.

<span class="h2"><a class="selflink" id="appendix-B" href="#appendix-B">Appendix B</a>.  Contributors</span>

   Christian Jacquenet
   France Telecom R&amp;D
   4 rue du Clos Courtel BP 91226
   35512 Cesson Sevigne
   France

   EMail: christian.jacquenet@orange-ftgroup.com


   Giyyarpuram Madhusudan
   France Telecom R&amp;D
   28 Chemin du Vieux Chene
   38243 Meylan Cedex
   France

   EMail: giyyarpuram.madhusudan@orange-ftgroup.com


   Gabriel Chegaray
   France Telecom R&amp;D
   28 Chemin du Vieux Chene
   38243 Meylan Cedex
   France

   EMail: gabriel.chegaray@orange-ftgroup.com



















<span class="grey">Dohler, et al.               Informational                     [Page 20]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-21" ></span>
<span class="grey"><a href="./rfc5548">RFC 5548</a>            Routing Requirements for U-LLNs             May 2009</span>


Authors' Addresses

   Mischa Dohler (editor)
   CTTC
   Parc Mediterrani de la Tecnologia
   Av. Canal Olimpic S/N
   08860 Castelldefels, Barcelona
   Spain

   EMail: mischa.dohler@cttc.es


   Thomas Watteyne (editor)
   Berkeley Sensor &amp; Actuator Center, University of California, Berkeley
   497 Cory Hall #1774
   Berkeley, CA  94720-1774
   USA

   EMail: watteyne@eecs.berkeley.edu


   Tim Winter (editor)
   Eka Systems
   20201 Century Blvd. Suite 250
   Germantown, MD  20874
   USA

   EMail: wintert@acm.org


   Dominique Barthel (editor)
   France Telecom R&amp;D
   28 Chemin du Vieux Chene
   38243 Meylan Cedex
   France

   EMail: Dominique.Barthel@orange-ftgroup.com














Dohler, et al.               Informational                     [Page 21]
</pre>