doc: Add RFC documents

1 files changed, 1179 insertions, 0 deletions

diff --git a/doc/rfc/rfc5548.txt b/doc/rfc/rfc5548.txt
new file mode 100644
index 0000000..5f5855c
--- /dev/null
+++ b/doc/rfc/rfc5548.txt
@@ -0,0 +1,1179 @@
+
+
+
+
+
+
+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&D
+                                                                May 2009
+
+
+      Routing Requirements for Urban Low-Power and Lossy Networks
+
+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 BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents in effect on the date of
+   publication of this document (http://trustee.ietf.org/license-info).
+   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
+
+
+
+Dohler, et al.               Informational                      [Page 1]
+
+RFC 5548            Routing Requirements for U-LLNs             May 2009
+
+
+   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
+
+   1. Introduction ....................................................3
+   2. Terminology .....................................................3
+      2.1. Requirements Language ......................................4
+   3. Overview of Urban Low-Power and Lossy Networks ..................4
+      3.1. Canonical Network Elements .................................4
+           3.1.1. Sensors .............................................4
+           3.1.2. Actuators ...........................................5
+           3.1.3. Routers .............................................6
+      3.2. Topology ...................................................6
+      3.3. Resource Constraints .......................................7
+      3.4. Link Reliability ...........................................7
+   4. Urban LLN Application Scenarios .................................8
+      4.1. Deployment of Nodes ........................................8
+      4.2. Association and Disassociation/Disappearance of Nodes ......9
+      4.3. Regular Measurement Reporting ..............................9
+      4.4. Queried Measurement Reporting .............................10
+      4.5. Alert Reporting ...........................................11
+   5. Traffic Pattern ................................................11
+   6. Requirements of Urban-LLN Applications .........................13
+      6.1. Scalability ...............................................13
+      6.2. Parameter-Constrained Routing .............................13
+      6.3. Support of Autonomous and Alien Configuration .............14
+      6.4. Support of Highly Directed Information Flows ..............15
+      6.5. Support of Multicast and Anycast ..........................15
+      6.6. Network Dynamicity ........................................16
+      6.7. Latency ...................................................16
+   7. Security Considerations ........................................16
+   8. References .....................................................18
+      8.1. Normative References ......................................18
+      8.2. Informative References ....................................18
+   Appendix A.  Acknowledgements .....................................20
+   Appendix B.  Contributors .........................................20
+
+
+
+
+
+
+
+
+
+
+
+Dohler, et al.               Informational                      [Page 2]
+
+RFC 5548            Routing Requirements for U-LLNs             May 2009
+
+
+1.  Introduction
+
+   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.
+
+   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 overlap with or be derived from other application-specific
+   requirements documents [ROLL-HOME] [ROLL-INDUS] [ROLL-BUILD].
+
+   Section 7 provides an overview of routing security considerations of
+   U-LLN implementations.
+
+2.  Terminology
+
+   The terminology used in this document is consistent with and
+   incorporates that described in "Terminology in Low power And Lossy
+   Networks" [ROLL-TERM].  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 RFC4291 [RFC4291] and RFC1546 [RFC1546].
+
+   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.
+
+
+
+
+
+
+
+Dohler, et al.               Informational                      [Page 3]
+
+RFC 5548            Routing Requirements for U-LLNs             May 2009
+
+
+   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.
+
+2.1.  Requirements Language
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [RFC2119].
+
+3.  Overview of Urban Low-Power and Lossy Networks
+
+3.1.  Canonical Network Elements
+
+   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.
+
+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, UV
+       index, strength and direction of wind, etc.;
+
+
+
+
+
+Dohler, et al.               Informational                      [Page 4]
+
+RFC 5548            Routing Requirements for U-LLNs             May 2009
+
+
+   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).
+
+3.1.2.  Actuators
+
+   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.
+
+
+
+
+
+
+Dohler, et al.               Informational                      [Page 5]
+
+RFC 5548            Routing Requirements for U-LLNs             May 2009
+
+
+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, 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).
+
+3.2.  Topology
+
+   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.
+
+
+
+
+
+
+
+Dohler, et al.               Informational                      [Page 6]
+
+RFC 5548            Routing Requirements for U-LLNs             May 2009
+
+
+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., 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.
+
+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 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.
+
+
+
+
+Dohler, et al.               Informational                      [Page 7]
+
+RFC 5548            Routing Requirements for U-LLNs             May 2009
+
+
+   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.
+
+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 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 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.
+
+
+
+
+
+
+Dohler, et al.               Informational                      [Page 8]
+
+RFC 5548            Routing Requirements for U-LLNs             May 2009
+
+
+   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 [Lu2007],
+   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.
+
+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, 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.
+
+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
+
+
+
+Dohler, et al.               Informational                      [Page 9]
+
+RFC 5548            Routing Requirements for U-LLNs             May 2009
+
+
+   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.
+
+4.4.  Queried Measurement Reporting
+
+   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.
+
+
+
+Dohler, et al.               Informational                     [Page 10]
+
+RFC 5548            Routing Requirements for U-LLNs             May 2009
+
+
+4.5.  Alert Reporting
+
+   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.
+
+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 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
+
+
+
+Dohler, et al.               Informational                     [Page 11]
+
+RFC 5548            Routing Requirements for U-LLNs             May 2009
+
+
+   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.
+
+
+
+
+
+
+Dohler, et al.               Informational                     [Page 12]
+
+RFC 5548            Routing Requirements for U-LLNs             May 2009
+
+
+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 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 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.
+
+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 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).
+
+
+
+
+
+Dohler, et al.               Informational                     [Page 13]
+
+RFC 5548            Routing Requirements for U-LLNs             May 2009
+
+
+   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.
+
+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
+   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
+
+
+
+
+
+
+Dohler, et al.               Informational                     [Page 14]
+
+RFC 5548            Routing Requirements for U-LLNs             May 2009
+
+
+   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).
+
+6.4.  Support of Highly Directed Information Flows
+
+   As pointed out in Section 4.3, 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.
+
+6.5.  Support of Multicast and Anycast
+
+   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 [ROLL-HOME].
+
+   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
+
+
+
+
+Dohler, et al.               Informational                     [Page 15]
+
+RFC 5548            Routing Requirements for U-LLNs             May 2009
+
+
+   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 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.
+
+6.7.  Latency
+
+   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).
+
+7.  Security Considerations
+
+   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
+
+
+
+Dohler, et al.               Informational                     [Page 16]
+
+RFC 5548            Routing Requirements for U-LLNs             May 2009
+
+
+   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.
+
+
+
+
+
+Dohler, et al.               Informational                     [Page 17]
+
+RFC 5548            Routing Requirements for U-LLNs             May 2009
+
+
+   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.
+
+8.  References
+
+8.1.  Normative References
+
+   [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
+                 Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+8.2.  Informative References
+
+   [Lu2007]      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.
+
+   [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.
+
+   [ROLL-BUILD]  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.
+
+   [ROLL-HOME]   Brandt, A. and G. Porcu, "Home Automation Routing
+                 Requirements in Low Power and Lossy Networks", Work
+                 in Progress, November 2008.
+
+
+
+Dohler, et al.               Informational                     [Page 18]
+
+RFC 5548            Routing Requirements for U-LLNs             May 2009
+
+
+   [ROLL-INDUS]  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.
+
+   [ROLL-TERM]   Vasseur, J., "Terminology in Low power And Lossy
+                 Networks", Work in Progress, October 2008.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dohler, et al.               Informational                     [Page 19]
+
+RFC 5548            Routing Requirements for U-LLNs             May 2009
+
+
+Appendix A.  Acknowledgements
+
+   The in-depth feedback of JP Vasseur, Jonathan Hui, Iain Calder, and
+   Pasi Eronen is greatly appreciated.
+
+Appendix B.  Contributors
+
+   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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dohler, et al.               Informational                     [Page 20]
+
+RFC 5548            Routing Requirements for U-LLNs             May 2009
+
+
+Authors' Addresses
+
+   Mischa Dohler (editor)
+   CTTC
+   Parc Mediterrani de la Tecnologia
+   Av. Canal Olimpic S/N
+   08860 Castelldefels, Barcelona
+   Spain
+
+   EMail: mischa.dohler@cttc.es
+
+
+   Thomas Watteyne (editor)
+   Berkeley Sensor & Actuator Center, University of California, Berkeley
+   497 Cory Hall #1774
+   Berkeley, CA  94720-1774
+   USA
+
+   EMail: watteyne@eecs.berkeley.edu
+
+
+   Tim Winter (editor)
+   Eka Systems
+   20201 Century Blvd. Suite 250
+   Germantown, MD  20874
+   USA
+
+   EMail: wintert@acm.org
+
+
+   Dominique Barthel (editor)
+   France Telecom R&D
+   28 Chemin du Vieux Chene
+   38243 Meylan Cedex
+   France
+
+   EMail: Dominique.Barthel@orange-ftgroup.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dohler, et al.               Informational                     [Page 21]
+