Networking Working Group                                  M. Dohler, Ed.
Internet-Draft                                                      CTTC
Intended status: Informational                          T. Watteyne, Ed.
Expires: December 3, 2008                             France Telecom R&D April 23, 2009                            CITI-Lab, INRIA A4RES
                                                          T. Winter, Ed.
                                                             Eka Systems
                                                           June 30,
                                                         D. Barthel, Ed.
                                                      France Telecom R&D
                                                        October 20, 2008

    Urban WSNs Routing Requirements in Low Power and Lossy Networks
                 draft-ietf-roll-urban-routing-reqs-01
                 draft-ietf-roll-urban-routing-reqs-02

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on December 3, 2008. April 23, 2009.

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 the 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 is expected to communicate wirelessly 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 outdoors outdoor urban application scenarios.  As such,
   for a wireless ROLL Routing Over Low power and Lossy networks (ROLL)
   solution to be useful, the protocol(s) ought to be energy-efficient,
   scalable, and autonomous.  This documents aims to specify a set of
   requirements reflecting these and further U-LLNs tailored
   characteristics.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Overview of Urban Low Power Lossy Networks . . . . . . . . . .  5
     3.1.  Canonical Network Elements . . . . . . . . . . . . . . . .  5
       3.1.1.  Access Points  . . . . . . . . . . . . . . . . . . .  Sensors  .  5
       3.1.2.  Repeaters . . . . . . . . . . . . . . . . . . . . . .  6
       3.1.3.  5
       3.1.2.  Actuators  . . . . . . . . . . . . . . . . . . . . . .  6
       3.1.4.  Sensors
       3.1.3.  Routers  . . . . . . . . . . . . . . . . . . . . . . .  6
     3.2.  Topology . . . . . . . . . . . . . . . . . . . . . . . . .  7
     3.3.  Resource Constraints . . . . . . . . . . . . . . . . . . .  7
     3.4.  Link Reliability . . . . . . . . . . . . . . . . . . . . .  8  7
   4.  Urban LLN Application Scenarios  . . . . . . . . . . . . . . .  9  8
     4.1.  Deployment of Nodes  . . . . . . . . . . . . . . . . . . .  9  8
     4.2.  Association and Disassociation/Disappearance of Nodes  . . 10  9
     4.3.  Regular Measurement Reporting  . . . . . . . . . . . . . . 11 10
     4.4.  Queried Measurement Reporting  . . . . . . . . . . . . . . 11 10
     4.5.  Alert Reporting  . . . . . . . . . . . . . . . . . . . . . 12 11
   5.  Traffic Pattern  . . . . . . . . . . . . . . . . . . . . . . . 12 11
   6.  Requirements of Urban LLN Applications . . . . . . . . . . . . 14 13
     6.1.  Scalability  . . . . . . . . . . . . . . . . . . . . . . . 14 13
     6.2.  Parameter Constrained Routing  . . . . . . . . . . . . . . 14 13
     6.3.  Support of Autonomous and Alien Configuration  . . . . . . 15 14
     6.4.  Support of Highly Directed Information Flows . . . . . . . 15
     6.5.  Support of Heterogeneous Field Devices . . . . . . . . . . 15
     6.6.  Support of Multicast, Anycast, and Implementation of
           Groupcast  . . . . . . . . . . . . . . . . . . . . . . . . 16
     6.7. 15
     6.6.  Network Dynamicity . . . . . . . . . . . . . . . . . . . . 16
     6.8.
     6.7.  Latency  . . . . . . . . . . . . . . . . . . . . . . . . . 16
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 17 16
   8.  Open Issues  . . . . . . . . . . . . . . . . . . . . . . . . . 19
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 19
   10. 18
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
   11. 18
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
     11.1.
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 19
     11.2.
     10.2. Informative References . . . . . . . . . . . . . . . . . . 19
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
   Intellectual Property and Copyright Statements . . . . . . . . . . 22

1.  Introduction

   This document details application-specific routing requirements for
   Urban Low Power and Lossy Networks (U-LLNs).  U-LLN use cases and
   associated routing protocol requirements will be described.

   Section 2 defines terminology useful in describing U-LLNs.

   Section 3 provides an overview of U-LLN applications.

   Section 4 describes a few typical use cases for U-LLN applications
   exemplifying deployment problems and related routing issues.

   Section 5 describes traffic flows that will be typical for U-LLN
   applications.

   Section 6 discusses the routing requirements for networks comprising
   such constrained devices in a U-LLN environment.  These requirements
   may be overlapping requirements derived from other application-
   specific requirements documents or as listed in
   [I-D.culler-rl2n-routing-reqs]. [I-D.ietf-roll-home-routing-reqs]
   [I-D.ietf-roll-indus-routing-reqs]
   [I-D.martocci-roll-building-routing-reqs].

   Section 7 provides an overview of routing security considerations of
   U-LLN implementations.

2.  Terminology

   Access Point:

   The access point terminology used in this document is an infrastructure device consistent with and
   incorporates that
         connects the low described in `Terminology in Low power And Lossy
   Networks' [I-D.vasseur-roll-terminology].  This terminology is
   extended in this document as follows:

   Anycast:  Addressing and lossy network system Routing scheme for forwarding packets to at
         least one of the "nearest" interfaces from a backbone
         network.

   Actuator: group, as
         described in RFC4291 [RFC4291] and RFC1546 [RFC1546].

   Autonomous:  Refers to the ability of a field device that moves routing protocol to
         independently function without requiring any external influence
         or controls equipment

   AMI:  Advanced Metering Infrastructure, part of Smart Grid.
         Encompasses smart-metering applications.

   DA:   Distribution Automation, part of Smart Grid.  Encompasses
         technologies for maintenance guidance.  Includes self-configuration and management self-organization
         capabilities.

   ISM band:  Industrial, Scientific and Medical band.  This is a region
         of electrical
         distribution systems.

   Field Device:  physical device placed in the urban operating
         environment.  Field radio spectrum where low power unlicensed devices include sensors, actuators and
         repeaters.

   LLN: may
         generally be used, with specific guidance from an applicable
         local radio spectrum authority.

   U-LLN:  Urban Low power Power and Lossy Network

   ROLL: Routing over network.

   WLAN: Wireless Local Area Network.

3.  Overview of Urban Low power and Lossy networks

   Smart Grid:  a broad class of applications to network and automate
         utility infrastructure.

   Schedule:  An agreed execution, wake-up, transmission, reception,
         etc., time-table between two or more field devices.

   U-LLN:  Urban LLN

3.  Overview of Urban Low Power Power Lossy Networks

3.1.  Canonical Network Elements

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

   1.  access points,  sensors,

   2.  repeaters,

   3.  actuators, and

   4.  sensors

   3.  routers.

   which communicate wirelessly.

3.1.1.  Access Points

   The access point can be used as:

   1.  router to a wider infrastructure (e.g.  Internet),

   2.  data sink (e.g. data collection & processing from sensors), and

   3.  data source (e.g. instructions towards actuators)

   There can be several access points connected to the same U-LLN;
   however, the number of access points is well below the amount of
   sensing nodes.  The access points are mainly static, i.e. fixed to a
   random or pre- planned location, but can be nomadic, i.e. in form of
   a walking supervisor.  Access points may but generally do not suffer
   from any form of (long-term) resource constraint, except that they
   need to be small and sufficiently cheap.

3.1.2.  Repeaters

   Repeaters generally act as relays with the aim to close coverage and
   routing gaps; examples of their use are:

   1.  prolong the U-LLN's lifetime,

   2.  balance nodes' energy depletion,

   3.  build advanced sensing infrastructures.

   There can be several repeaters supporting the same U-LLN; however,
   the number of repeaters is well below the amount of sensing nodes.
   The repeaters are mainly static, i.e. fixed to a random or pre-
   planned location.  Repeaters may but generally do not suffer from any
   form of (long-term) resource constraint, except that they need to be
   small and sufficiently cheap.  Repeaters differ from access points in
   that they do not act as a data sink/source.  They differ from
   actuator and sensing nodes in that they neither control nor sense.

3.1.3.  Actuators

   Actuator nodes control urban devices upon being instructed by
   signaling arriving from or being forwarded by the access point(s);
   examples are street or traffic lights.  The amount of actuator points
   is well below the number of sensing nodes.  Some sensing nodes may
   include an actuator component, e.g. an electric meter node with
   integrated support for remote service disconnect.  Actuators are
   capable to forward data.  Actuators may generally be mobile but are
   likely to be static in the majority of near-future roll-outs.
   Similar to the access points, actuator nodes do not suffer from any
   long-term resource constraints.

3.1.4. wirelessly.

3.1.1.  Sensors

   Sensing nodes measure a wide gamut of physical data, including but
   not limited to:

   1.  municipal consumption data, such as smart-metering of gas, water,
       electricity, waste, etc;

   2.  meteorological data, such as temperature, pressure, humidity, sun UV
       index, strength and direction of wind, etc;

   3.  pollution data, such as polluting gases (SO2, NOx, CO, Ozone), heavy metals
       (e.g.  Mercury), pH, radioactivity, etc;

   4.  ambient data, such as allergic elements (pollen, dust),
       electromagnetic pollution, noise levels, etc.

   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 which 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
   service,
   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 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 which delivers
   energy throughout the urban environment.  Sensor nodes capable of
   providing this type of functionality may sometimes be referred to as
   Advanced Metering Infrastructure (AMI).
   Advanced Metering Infrastructure (AMI).

3.1.2.  Actuators

   Actuator nodes control urban devices upon being instructed by
   signaling traffic; examples are street or traffic lights.  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.

3.1.3.  Routers

   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,

   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.

   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 routers also serve as data sinks (e.g.
   they collect and process data from sensors) and sources (e.g. they
   forward instructions to actuators).

3.2.  Topology

   Whilst millions of sensing nodes may very well be deployed in an
   urban area, they are likely to be associated to with more than one network
   where these
   network.  These networks may or may not communicate between one other.
   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- 10^2 to 10^7; this is still very large and unprecedented in
   current roll-
   outs.  The network MUST be capable of supporting the organization of
   a large number of sensing nodes into regions containing on the order
   of 10^2 to 10^4 sensing nodes each. 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.

3.3.  Resource Constraints

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

   5.  always on (e.g. powered electricity meter).

   In the case of a battery powered sensing node, the battery life-time shelf life
   is usually in the order of 10-15 10 to 15 years, rendering network lifetime
   maximization with battery-powered battery powered nodes beyond this lifespan useless.

   The physical and electromagnetic distances between the four three key
   elements, i.e. sensors, actuators, repeaters and access points, 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 access point LBR in a single hop, thereby
   requiring suitable routing protocols which manage the information
   flow in an energy-efficient manner.  Sensor
   nodes are capable of forwarding data.

3.4.  Link Reliability

   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 medium access control; 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.

   Since the wireless medium is broadcast in nature, nodes in their
   communication radios require suitable medium access control protocols
   which are capable of resolving any arising contention.  Some
   available protocols may cause not be able to prevent packets of neighbouring neighboring
   nodes from colliding, possibly leading to
   collide a high Packet Error Rate
   (PER) and hence cause causing a link outage.

   Furthermore, the outdoors outdoor deployment of U-LLNs also has implications
   for the interference temperature and hence link reliability and range
   if ISM Industrial, Scientific and Medical (ISM) bands are to be used.
   For instance, if the 2.4GHz ISM band is used to facilitate
   communication between U-LLN nodes, then heavily loaded WLAN Wireless Local
   Area Network (WLAN) hot-spots may become a detrimental performance factor
   factor, leading to high PER and jeopardizing the functioning of the
   U-LLN.

   Finally, nodes appearing and disappearing causes dynamics in the
   network which can yield link outages and changes of topologies.

4.  Urban LLN Application Scenarios

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

4.1.  Deployment of Nodes

   Contrary to other LLN applications, deployment of nodes is likely to
   happen in batches out of a box.  Typically, hundreds to thousands of
   nodes are being shipped by the manufacturer with pre-programmed
   functionalities which are then rolled-out by a service provider or
   subcontracted entities.  Prior or after roll-out, the network needs
   to be ramped-up.  This initialization phase may include, among
   others, allocation of addresses, (possibly hierarchical) roles in the
   network, synchronization, determination of schedules, etc.

   If initialization is performed prior to roll-out, all nodes are
   likely to be in one another's 1-hop radio neighborhood.  Pre-
   programmed MAC 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, 0-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- 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 dependant dependent on critical links to achieve connectivity
   with the rest of the network.  Any proposed LLN routing protocol
   ought to support the autonomous organization self-organization and self-
   configuration of the network at lowest possible energy cost [Lu2007], where autonomy is
   understood to be the ability of the network to operate without
   external influence.  For example, nodes in urban sensor nodes SHOULD
   be able to:

   o  Dynamically adapt to ever-changing conditions of communication
      (possible degradation of QoS, variable nature of the traffic (real
      time vs. non real time, sensed data vs. alerts, node mobility, a
      combination thereof, etc.),
   o  Dynamically provision the service-specific (if not traffic-
      specific) resources that will comply with the QoS and security
      requirements of the service,

   o  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 the access point
      according to the service-specific and traffic-specific QoS,
      traffic engineering and 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 cost [Lu2007],
   where autonomy is understood to be the ability of sensors). the network to
   operate without external influence.  The result of such organization SHOULD
   should be that each node or set of nodes is uniquely addressable so
   as to facilitate the set up of schedules, etc.

   The U-LLN routing protocol(s) MUST accommodate both unicast and
   multicast forwarding schemes.  The U-LLN routing protocol(s) SHOULD
   support anycast forwarding schemes.

   Unless exceptionally needed, broadcast forwarding schemes are not
   advised in urban sensor networking environments.

4.2.  Association and Disassociation/Disappearance of Nodes

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

   The protocol(s) hence SHOULD support should be able to convey information about
   malfunctioning nodes which may affect or jeopardize the pinpointing of problematic overall
   routing areas as well as an organization efficiency, so that self-organization and self-configuration
   capabilities of the sensor network which
   facilitates reconfiguration in might be solicited to facilitate
   the case of association and
   disassociation/disappearance of nodes at lowest possible energy and
   delay. appropriate reconfiguration.  This information may e.g. include
   exact or relative geographical position, etc.  The latter reconfiguration
   may include the change of hierarchies, routing paths, packet
   forwarding schedules, etc.  Furthermore, to inform the
   access point(s) 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 (link state) updating mechanisms
   SHOULD should be supported.

4.3.  Regular Measurement Reporting

   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 the
   access point(s)
   LBR(s) - 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.

   The protocol(s) hence MUST should be optimized to support a large number
   of highly directional unicast flows from the sensing nodes or sensing
   clusters towards the access point a LBR, or highly directed multicast or anycast flows
   from the nodes towards multiple access points. 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 battery powered nodes, whereas air quality
   indicators are reported only during daytime via nodes powered by
   solar energy.  More generally, entire routing areas may be avoided
   (e.g. at
   e.g. night night) but heavily used during the day when nodes are
   scavenging from sunlight.

4.4.  Queried Measurement Reporting

   Occasionally, network external data queries can be launched by one or
   several access points. LBRs.  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 access point LBR from where the query was launched.  Round-trip
   times, i.e. from the launch of a query from an access
   point LBR towards the
   delivery of the measured data to an access point, LBR, are of importance.  However,
   they are not very stringent where latencies SHOULD should simply be
   sufficiently smaller than typical reporting intervals; for instance,
   in the order of seconds or minute.  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 network devices SHOULD 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.

4.5.  Alert Reporting

   Rarely, the sensing nodes will measure an event which classifies as
   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 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.

   Routing within urban sensor networks SHOULD require the U-LLN nodes
   to dynamically compute, select and install different paths towards a
   same destination, depending on the nature of the traffic.  From this
   perspective, such nodes SHOULD inspect the contents of traffic
   payload for making routing and forwarding decisions: for example, the
   analysis of the traffic payload SHOULD be derived into aggregation
   capabilities for the sake of forwarding efficiency.

   Routes clearly need to be unicast (towards one access point) LBR) or multicast
   (towards multiple access points). LBRs).  Delays and latencies are important;
   however, again, deliveries within seconds SHOULD should suffice in most of
   the cases.

5.  Traffic Pattern

   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 towards one or a subset
       of the access point(s); LBR(s);

   2.  query requests from the access point(s) LBR(s) towards the sensing nodes;

   3.  control information from the access point(s) 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 access points 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 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.

   An U-LLN SHOULD should support occasional large scale traffic flows from
   sensing nodes to access points, LBRs, such as system-wide alerts.  In the example of
   an AMI U-LLN this could be in response to events such as a city wide
   power outage.  In this scenario all powered devices in a large
   segment of the network may have lost power and are running off of a
   temporary `last gasp' source such as a capacitor or small battery.  A
   node MUST must be able to send its own alerts toward an access
   point LBR while
   continuing to forward traffic on behalf of other devices who are also
   experiencing an alert condition.  The network MUST needs to be able to
   manage this sudden large traffic flow.  It may be useful for the
   routing layer to collaborate with the application layer to perform
   data aggregation, in order to reduce the total volume of a large
   traffic flow, and make more efficient use of the limited energy
   available.

   An U-LLN may also need to support efficient large scale messaging to
   groups of actuators.  For example, an AMI U-LLN supporting a city-
   wide demand response system will need to efficiently broadcast demand
   response control information to a large subset of actuators in the
   system.

   Some scenarios will require internetworking between the U-LLN and
   another network, such as a home network.  For example, an AMI
   application that implements a demand-response system may need to
   forward traffic from a utility, across the U-LLN, into a home
   automation network.  A typical use case would be to inform a customer
   of incentives to reduce demand during peaks, or to automatically
   adjust the thermostat of customers who have enrolled in such a demand
   management program.  Subsequent traffic may be triggered to flow back
   through the U-LLN to the utility.  The network SHOULD support
   internetworking, while giving attention to security implications of
   interfacing, for example, a home network with a utility U-LLN.

6.  Requirements of Urban LLN Applications

   Urban low power and lossy network applications have a number of
   specific requirements related to the set of operating conditions, as
   exemplified in the previous section. sections.

6.1.  Scalability

   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 a
   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 to-be-
   specified selected
   performance parameters below to-be-specified configurable thresholds.  The routing
   protocols(s) SHOULD support the organization of a large number of
   nodes into regions of to-be-specified configurable size.

6.2.  Parameter Constrained Routing

   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.

   Routing within urban sensor networks SHOULD require the U-LLN nodes
   to dynamically compute, select and install different paths towards a
   same destination, depending on the nature of the traffic.  From this
   perspective, such nodes SHOULD inspect the contents of traffic
   payload for making routing and forwarding decisions: for example, the
   analysis of traffic payload should encourage the enforcement of
   forwarding policies based upon aggregation capabilities for the sake
   of efficiency.

6.3.  Support of Autonomous and Alien Configuration

   With the large number of nodes, manually configuring and
   troubleshooting each node is not efficient.  The scale and the large
   number of possible topologies that may be encountered in the U-LLN
   encourages the development of automated management capabilities that
   may (partly) rely upon self-organizing techniques.  The network is
   expected to self-organize and self-configure according to some prior
   defined rules and protocols, as well as to support externally
   triggered configurations (for instance through a commissioning tool
   which may facilitate the organization of the network at a minimum
   energy cost).

   To this end, the routing protocol(s) MUST provide a set of features
   including 0-configuration at network ramp-up, (network-internal)
   self- organization and configuration due to topological changes, and
   the ability to support (network-external) patches support (network-external) patches and configuration
   updates.  For the latter, the protocol(s) MUST support multi- and
   any-cast 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 QoS,
   variable nature of the traffic (real time vs. non real time, sensed
   data vs. alerts), node mobility, a combination thereof, etc.)

   The routing protocol(s) SHOULD be able to dynamically compute, select
   and configuration
   updates.  For possibly optimize the latter, (multiple) path(s) that will be used by the protocol(s) MUST support multi- and
   any-cast addressing.  The protocol(s) SHOULD also support
   participating devices to forward the
   formation traffic towards the actuators
   and/or a LBR according to the service-specific and identification traffic-specific
   QoS, traffic engineering and routing security policies that will have
   to be enforced at the scale of groups a routing domain (that is, a set of field
   networking devices in the
   network. administered by a globally unique entity), or a
   region of such domain (e.g. a metropolitan area composed of clusters
   of sensors).

6.4.  Support of Highly Directed Information Flows

   The reporting of the data readings by a large amount of spatially
   dispersed nodes towards a few access points LBRs will lead to highly directed
   information flows.  For instance, a suitable addressing scheme can be
   devised which facilitates the data flow.  Also, as one gets closer to
   the access point, 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 flow flows to facilitate
   scalability and parameter constrained routing.

6.5.  Support of Heterogeneous Field Devices

   The sheer amount of different field devices will unlikely be provided
   by a single manufacturer.  A heterogeneous roll-out with nodes using
   different physical and medium access control layers is hence likely.

   To mandate fully interoperable implementations, the routing
   protocol(s) proposed in U-LLN protocol MUST support different devices and
   underlying technologies without compromising the operability be able to accommodate traffic bursts by
   dynamically computing and
   energy efficiency of selecting multiple paths towards the network.

6.6. same
   destination.

6.5.  Support of Multicast, Anycast, and Implementation of Groupcast

   Some urban sensing systems require low-level addressing of a group of
   nodes in the same subnet, or for a node representative of a group of
   nodes, without any prior creation of multicast groups, simply
   carrying a list of recipients in the subnet
   [I-D.brandt-roll-home-routing-reqs].
   [I-D.ietf-roll-home-routing-reqs].

   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 [RFC4291] [RFC1546]. schemes.  Routing protocols activated in urban sensor
   networks SHOULD accommodate "groupcast" forwarding schemes, where
   traffic is sent to a set of devices that implicitly belong to the
   same group/cast.

   The support of unicast, groupcast, multicast, and anycast also has an
   implication on the addressing scheme but is beyond the scope of this
   document that focuses on the routing requirements aspects.

   Note: with IP multicast, signaling mechanisms are used by a receiver
   to join a group and the sender does not know the receivers of the
   group.  What is required is the ability to address a group of
   receivers known by the sender even if the receivers do not need to
   know that they have been grouped by the sender (since requesting each
   individual node to join a multicast group would be very energy-
   consuming).

6.7.

   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.

6.6.  Network Dynamicity

   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 re-organization reorganization and re-configuration reconfiguration convergence as well
   as routing protocol convergence.

   To this end, local network dynamics SHOULD NOT impact the entire
   network to be re-organized or re-reconfigured; however, the network re-organized 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 be locally optimized use this information to cater
   initiate protocol specific mechanisms for the encountered changes. reorganization and
   reconfiguration as necessary to maintain overall routing efficiency.
   Convergence and route establishment times SHOULD be significantly
   lower than the smallest reporting interval.

6.8.

   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.

6.7.  Latency

   With the exception of alert reporting solutions and to a certain
   extent queried reporting, U-LLN 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.

   To this end, the routing protocol(s) SHOULD support minimum latency
   for alert reporting and time-critical data queries.  For regular data
   reporting, it SHOULD support latencies not exceeding a fraction of
   the smallest reporting interval.  Due to the different latency
   requirements, the routing protocol(s) SHOULD support the ability of
   dealing with different latency requirements.

   The routing protocol(s) SHOULD also support the ability to route
   according to different metrics (one of which could e.g. be latency).

7.  Security Considerations

   As every network, U-LLNs are exposed to routing security threats that MUST
   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.

   A secure communication in a wireless network encompasses three main
   elements, i.e. confidentiality (encryption of data), integrity
   (correctness of data), and authentication (legitimacy of data).

   U-LLN networks SHOULD support mechanisms to preserve the
   confidentiality of the traffic that they forward.  The U-LLN network
   SHOULD NOT prevent an application from employing additional
   confidentiality mechanisms.

   Authentication can e.g. be violated if external sources insert
   incorrect data packets; integrity can e.g. be violated if nodes start
   to break down and hence commence measuring and relaying data
   incorrectly.  Nonetheless, some sensor readings as well as the
   actuator control signals need to be confidential.

   The U-LLN network MUST deny all routing services to any node who has
   not been authenticated to the U-LLN and authorized for the use of
   routing services.

   The U-LLN MUST be protected against attempts to inject false or
   modified packets.  For example, an attacker SHOULD be prevented from
   manipulating or disabling the routing function by compromising
   routing update messages.  Moreover, it SHOULD NOT be possible to
   coerce the network into routing packets which have been modified in
   transit.  To this end the routing protocol(s) MUST support message
   integrity.

   Further example routing security issues which may arise are the
   abnormal behavior of nodes which 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, external attacks aimed at
   injecting dummy traffic to drain the network power, etc.

   The properties of self-configuration and self-organization which are
   desirable in a U-LLN introduce additional routing security
   considerations.  Mechanisms MUST be in place to deny any rogue node
   which attempts to take advantage of self-configuration and self-organization self-
   organization procedures.  Such attacks may attempt, for example, to
   cause denial of service, drain the energy of power constrained
   devices, or to hijack the routing mechanism.  A node MUST
   authenticate itself to a trusted node that is already associated with
   the U-LLN before any self-configuration or self-organization is
   allowed to proceed.  A node that has already authenticated and
   associated with the U-LLN MUST deny, to the maximum extent possible,
   the allocation of resources to any unauthenticated peer.  The routing
   protocol(s) MUST deny service to any node which has not clearly
   established trust with the U-LLN.

   Consideration SHOULD be given to cases where the U-LLN may interface
   with other networks such as a home network.  The U-LLN SHOULD NOT
   interface with any external network which has not established trust.
   The U-LLN SHOULD be capable of limiting the resources granted in
   support of an external network so as not to be vulnerable to denial
   of service.

   With low computation power and scarce energy resources, U-LLNs nodes
   may not be able to resist any attack from high-power malicious nodes
   (e.g. laptops and strong radios).  However, the amount of damage
   generated to the whole network SHOULD be commensurate with the number
   of nodes physically compromised.  For example, an intruder taking
   control over a single node SHOULD not have total access to, or be
   able to completely deny service to the whole network.

   In general, the routing protocol(s) SHOULD support the implementation
   of 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 man-in-
   the-middle attacks.

   The choice of the routing security solutions will have an impact onto
   routing protocol(s).  To this end, routing protocol(s) proposed in
   the context of U-LLNs MUST support integrity measures and SHOULD
   support confidentiality (security) (routing security) measures.

8.  Open Issues

   Other items to be addressed in further revisions of this document
   include:

   o  node mobility

9.  IANA Considerations

   This document makes no request of IANA.

10.

9.  Acknowledgements

   The in-depth feedback of JP Vasseur, Cisco, and Jonathan Hui, Arch Rock,
   and Iain Calder is greatly appreciated.

11.

10.  References

11.1.

10.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

11.2.

10.2.  Informative References

   [I-D.brandt-roll-home-routing-reqs]

   [I-D.ietf-roll-home-routing-reqs]
              Brandt, A., Buron, J., and G. Porcu, "Home Automation
              Routing Requirement in Low Power and Lossy Networks",
              draft-brandt-roll-home-routing-reqs-01
              draft-ietf-roll-home-routing-reqs-03 (work in progress),
              May
              September 2008.

   [I-D.culler-rl2n-routing-reqs]
              Vasseur, J.

   [I-D.ietf-roll-indus-routing-reqs]
              Networks, D., Thubert, P., Dwars, S., and D. Cullerot, "Routing T. Phinney,
              "Industrial Routing Requirements for in Low Power And and Lossy
              Networks",
              draft-culler-rl2n-routing-reqs-01 draft-ietf-roll-indus-routing-reqs-01 (work in
              progress), July 2007. 2008.

   [I-D.martocci-roll-building-routing-reqs]
              Martocci, J., Riou, N., Mil, P., and W. Vermeylen,
              "Building Automation Routing Requirements in Low Power and
              Lossy Networks",
              draft-martocci-roll-building-routing-reqs-01 (work in
              progress), October 2008.

   [I-D.vasseur-roll-terminology]
              Vasseur, J., "Terminology in Low power And Lossy
              Networks", draft-vasseur-roll-terminology-02 (work in
              progress), September 2008.

   [Lu2007]   J.L. Lu, F. Valois, D. Barthel, M. Dohler, "FISCO: A Fully
              Integrated Scheme of Self-Configuration and Self-
              Organization for WSN", IEEE WCNC 2007, Hong Kong, China,
              11-15 March 2007, pp. 3370-3375.

   [RFC1546]  Partridge, C., Mendez, T., and W. Milliken, "Host
              Anycasting Service", RFC 1546, November 1993.

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, February 2006.

Authors' Addresses

   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)
   France Telecom R&D
   28 Chemin du Vieux Chene
   38243 Meylan Cedex
   CITI-Lab, INSA-Lyon, INRIA A4RES
   21 avenue Jean Capelle
   69621 Lyon
   France

   Email: thomas.watteyne@orange-ftgroup.com thomas.watteyne@ieee.org

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

   Email: tim.winter@ekasystems.com

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

   Email: Dominique.Barthel@orange-ftgroup.com

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

   Email: christian.jacquenet@orange-ftgroup.com
   Giyyarpuram Madhusudan
   France Telecom R&D
   28 Chemin du Vieux Chene
   38243 Meylan Cedex
   France

   Email: giyyarpuram.madhusudan@orange-ftgroup.com

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

   Email: gabriel.chegaray@orange-ftgroup.com

   Dominique Barthel
   France Telecom R&D
   28 Chemin du Vieux Chene
   38243 Meylan Cedex
   France

   Email: Dominique.Barthel@orange-ftgroup.com

Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.