Networking Working Group                                  M. Dohler, Ed.
Internet-Draft                                                      CTTC
Intended status: Informational                          T. Watteyne, Ed.
Expires: September 15, December 3, 2008                             France Telecom R&D

                                                          April 16,
                                                          T. Winter, Ed.
                                                             Eka Systems
                                                           June 30, 2008

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

Status of this Memo

   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 September 15, December 3, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2008).

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) etc.) and the
   particularities of the outdoors urban application scenario. scenarios.  As
   such, for a wireless ROLL solution to be competitive with other incumbent
   and emerging solutions, useful, the protocol(s)
   ought to be energy-efficient,
   scalable 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  . . . . . . . . . . . . . . . . . . . . . . . . .  6  4
   3.  Overview of Urban LLN application scenarios. Low Power Lossy Networks . . . . . . . . . .  5
     3.1.  Canonical Network Elements . . . . .  7
     3.1.  Deployment of nodes. . . . . . . . . . . .  5
       3.1.1.  Access Points  . . . . . . . .  7
     3.2.  Association and disassociation/disappearance of nodes. . .  8
     3.3.  Regular measurement reporting. . . . . . . . . . .  5
       3.1.2.  Repeaters  . . . .  8
     3.4.  Queried measurement reporting. . . . . . . . . . . . . . .  9
     3.5.  Alert reporting. . . . .  6
       3.1.3.  Actuators  . . . . . . . . . . . . . . . . .  9
   4.  Requirements of urban LLN applications . . . . .  6
       3.1.4.  Sensors  . . . . . . . 10
     4.1.   Scalability.. . . . . . . . . . . . . . . . .  6
     3.2.  Topology . . . . . . 10
     4.2.   Parameter constrained routing . . . . . . . . . . . . . . 10
     4.3.   Support of autonomous and alien configuration . . . . .  7
     3.3.  Resource Constraints . 10
     4.4.   Support of highly directed information flows. . . . . . . 11
     4.5.   Support of heterogeneous field devices. . . . . . . . . . 11
     4.6.   Support . . .  7
     3.4.  Link Reliability . . . . . . . . . . . . . . . . . . . . .  8
   4.  Urban LLN Application Scenarios  . . . . . . . . . . . . . . .  9
     4.1.  Deployment of multicast Nodes  . . . . . . . . . . . . . . . . . . .  9
     4.2.  Association and implementation Disassociation/Disappearance of groupcast. Nodes  . . 11
     4.7.   Network dynamicity. 10
     4.3.  Regular Measurement Reporting  . . . . . . . . . . . . . . 11
     4.4.  Queried Measurement Reporting  . . . . . . 12
     4.8.   Latency. . . . . . . . . 11
     4.5.  Alert Reporting  . . . . . . . . . . . . . . . . . . . . . .12 12
   5.  Traffic Pattern  . . . . . . . . . . . . . . . . . . . . . . . .13 12
   6.  Security Considerations  Requirements of Urban LLN Applications . . . . . . . . . . . . 14
     6.1.  Scalability  . . . . . . . .13
   7.  Open Issues . . . . . . . . . . . . . . . . 14
     6.2.  Parameter Constrained Routing  . . . . . . . . . .13
   8.  IANA Considerations . . . . . 14
     6.3.  Support of Autonomous and Alien Configuration  . . . . . . 15
     6.4.  Support of Highly Directed Information Flows . . . . . . . 15
     6.5.  Support of Heterogeneous Field Devices . . . .14
   9.  Acknowledgements. . . . . . . . 15
     6.6.  Support of Multicast, Anycast, and Implementation of
           Groupcast  . . . . . . . . . . . . . . . .14
   10.  References. . . . . . . . . . 16
     6.7.  Network Dynamicity . . . . . . . . . . . . . . . . 14
     10.1   Normative References. . . . . 16
     6.8.  Latency  . . . . . . . . . . . . . . 14
     10.2   Informative References. . . . . . . . . . . . 16
   7.  Security Considerations  . . . . . . 14
Authors' Addresses. . . . . . . . . . . . . . 17
   8.  Open Issues  . . . . . . . . . . . . 14
Full Copyright Statement. . . . . . . . . . . . . . 19
   9.  IANA Considerations  . . . . . . . . . 15

1.  Introduction

We detail here some application specific routing requirements for Urban
Low Power and Lossy . . . . . . . . . . . . 19
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 19
     11.2. Informative References . . . . . . . . . . . . . . . . . . 19
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
   Intellectual Property and Copyright Statements . . . . . . . . . . 22

1.  Introduction

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

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

2.  Terminology

   Access Point:  The access point is an infrastructure device that
         connects the low power and lossy network system to a backbone
         network.

   Actuator:  a field device that moves or controls equipment

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

   DA:   Distribution Automation, part of Smart Grid.  Encompasses
         technologies for maintenance and management of electrical
         distribution systems.

   Field Device:  physical device placed in the urban operating
         environment.  Field devices include sensors, actuators and
         repeaters.

   LLN:  Low power and Lossy Network

   ROLL: Routing over Low power and Lossy networks

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

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

   U-LLN:  Urban LLN

3.  Overview of Urban Low Power Lossy Networks (U-LLNs).

3.1.  Canonical Network Elements

   A U-LLN is understood to be a network composed of four key elements,
   i.e.
1) sensors,
2) actuators,
3) repeaters, and
4)

   1.  access points,

   2.  repeaters,

   3.  actuators, and

   4.  sensors

   which communicate wirelessly.

3.1.1.  Access Points

   The access point can be used as:
1)

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

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

   3.  data source (e.g. instructions towards actuators). 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)

   1.  prolong the U-LLN's lifetime,
2)

   2.  balance nodes' energy depletion,
3)

   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 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
neither do not act as a router nor 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.  Sensors

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

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

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

   3.  pollution data, such as polluting gases (SO2, NOx, CO, Ozone),
       heavy metals (e.g.  Mercury), pH, radioactivity, etc;
4)
   4.  ambient data, such as allergic elements (pollen, dust),
       electromagnetic pollution, noise levels, etc.

   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 quality of
   service, providing granular interval data, or automating the
   detection of alarm conditions.  In addition they may be capable of
   advanced interactive functionalities such as remote service
   disconnect or remote demand reset.  More advanced scenarios include
   demand response systems for managing peak load, and distribution
   automation systems to monitor the infrastructure which delivers
   energy throughout the urban environment.  Sensor nodes capable of
   providing this type of functionality may sometimes be referred to as
   Advanced Metering Infrastructure (AMI).

3.2.  Topology

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

   Deployment of nodes is likely to happen in batches,
i.e. a box e.g. boxes of
   hundreds to thousands of nodes arrives arrive and are deployed.  The location
   of the nodes is random within given topological constraints, e.g.
   placement along a road road, river, or river. 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)

   1.  non-rechargeable battery;
2)

   2.  rechargeable battery with regular recharging (e.g. sunlight);
3)

   3.  rechargeable battery with irregular recharging (e.g.
       opportunistic energy scavenging);
4)
   4.  capacitive/inductive energy provision (e.g. active RFID).
The RFID);

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

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

   The physical and electromagnetic distances between the four key
   elements, i.e. sensors, actuators, repeaters and access points, 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
   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;

   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 packets of neighbouring nodes to
   collide and hence cause a link outage.

   Furthermore, the outdoors deployment of U-LLNs also has implications
   for the interference temperature and hence link reliability and range
   if ISM bands are to be used.  For instance, if the 2.4GHz ISM band is
   used to facilitate communication between U-LLN nodes, then heavily
   loaded WLAN hot-spots become a detrimental performance factor
   jeopardizing the functioning of 10-15 years, rendering
network lifetime maximization with battery-powered the U-LLN.

   Finally, nodes beyond this
lifespan useless.

The physical appearing and electromagnetic distances between disappearing causes dynamics in the four key
elements, i.e. sensors, actuators, repeaters and access points,
   network which can
generally be very large, i.e. from several hundreds yield link outages and changes of meters 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, this section lists a few typical but not
   exhaustive deployment problems and usage cases of U-LLN.

4.1.  Deployment of Nodes

   Contrary to one
kilometer. Not every field node other LLN applications, deployment of nodes is likely to reach the access point
   happen in batches out of a single hop, thereby requiring suitable routing protocols which manage
the information flow in an energy-efficient manner. Sensor box.  Typically, hundreds to thousands of
   nodes are
capable to forward data.

Unlike traditional ad hoc networks, being shipped by the information flow in U-LLNs is
highly directional. There manufacturer with pre-programmed
   functionalities which are three main flows to be distinguished:
1) sensed information from the sensing nodes towards one or then rolled-out by a subset of
the access point(s);
2) query requests from the access point(s) towards the sensing nodes;
3) control information from the access point(s) towards the actuators.

Some of service provider or
   subcontracted entities.  Prior or after roll-out, the flows network needs
   to be ramped-up.  This initialization phase may need the reverse route for delivering
acknowledgements. Finally, include, among
   others, allocation of addresses, (possibly hierarchical) roles in the future, some direct information flows
between field devices without access points may also occur.

Sensed data
   network, synchronization, determination of schedules, etc.

   If initialization is performed prior to roll-out, all nodes are
   likely to be highly correlated in space, time one another's 1-hop radio neighborhood.  Pre-
   programmed MAC and
observed events; an example routing protocols may hence fail to function
   properly, thereby wasting a large amount of energy.  Whilst the latter is when temperature and
humidity increase as the day commences. Data may major
   burden will be sensed on resolving MAC conflicts, any proposed U-LLN routing
   protocol needs to cater for such a case.  For instance,
   0-configuration and delivered
at different rates with both rates being typically fairly low, i.e. in 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 range order of hours, days, etc. Data 5- 10).  However, some
   nodes may be delivered regularly according
to a schedule or a regular query; it deployed in areas where there are hundreds of
   neighboring devices.  In the resulting topology there may also be delivered irregularly
after an externally triggered query; it regions
   where many (redundant) paths are possible through the network.  Other
   regions may also be triggered after a
sudden network-internal event or alert. The network hence needs to be
able to adjust dependant on critical links to achieve connectivity
   with the varying activity duty cycles, as well as rest of the network.  Any proposed LLN routing protocol
   ought to period support the autonomous organization and aperiodic traffic. Also, sensed data ought configuration of the
   network at lowest possible energy cost [Lu2007], where autonomy is
   understood to be secured and
locatable.

Finally, the outdoors deployment ability of U-LLNs has also implications for the
interference temperature and hence link reliability and range if ISM
bands are network to be used. operate without
   external influence.  For instance, if the 2.4GHz ISM band is used example, nodes in urban sensor nodes SHOULD
   be able to:

   o  Dynamically adapt to
facilitate ever-changing conditions of communication between U-LLN nodes, then heavily loaded WLAN
hot-spots become a detrimental performance factor jeopardizing the
reliability
      (possible degradation of QoS, variable nature of the U-LLN.

Section 3 describes traffic (real
      time vs. non real time, sensed data vs. alerts, node mobility, a few typical use cases for urban LLN applications
exemplifying deployment problems and related routing issues.
Section 4 discusses
      combination thereof, etc.),
   o  Dynamically provision the routing requirements for networks comprising
such constrained devices in a U-LLN environment. These requirements may
be overlapping requirements derived from other application-specific
requirements documents or as listed in [I-D.culler-roll-routing-reqs].

2.  Terminology

   Access Point: The access point is an infrastructure device service-specific (if not traffic-
      specific) resources that
   connects will comply with the low power QoS and lossy network system to a backbone
   network.

   Actuator: a field device security
      requirements of the service,

   o  Dynamically compute, select and possibly optimize the (multiple)
      path(s) that moves or controls equipment.

   Field Device: physical device placed in will be used by the urban operating
   environment. Field participating devices include sensors, to forward
      the traffic towards the actuators and/or the access point
      according to the service-specific and repeaters.

   LLN: Low power and Lossy Network

   ROLL: Routing over Low power traffic-specific QoS,
      traffic engineering and Lossy networks
   Schedule: An agreed execution, wake-up, transmission, reception, etc.,
   time-table between two or more field devices.

   Timeslot: A fixed time interval security policies that may will have to be used for
      enforced at the transmission
   or reception scale of a packet between two field devices.  A timeslot used
   for communications is associated with a slotted-link.

   U-LLN: Urban LLN

3.  Urban LLN application scenarios

Urban applications represent routing domain (that is, a special segment set of LLNs with its
      networking devices administered by a globally unique
set entity), or a
      region of requirements.  To facilitate the requirements discussion in
Section 4, this section lists such domain (e.g. a few typical but not exhaustive
deployment problems and usage cases metropolitan area composed of U-LLN.

3.1.   Deployment
      clusters of nodes

Contrary to other LLN applications, deployment sensors).

   The result of such organization SHOULD be that each node or set of
   nodes is likely uniquely addressable so as to
happen in batches out facilitate the set up of a box. Typically, hundreds
   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 are being
shipped by may be injected into the manufacturer with pre-programmed functionalities which network as well as existing nodes
   removed from the network.  The former might be because a removed node
   is replaced or denser readings/actuations are then rolled-out by needed or routing
   protocols report connectivity problems.  The latter might be because
   a service provider node's battery is depleted, the node is removed for maintenance,
   the node is stolen or subcontracted entities.
Prior accidentally destroyed, etc.  Differentiation
   SHOULD be made between node disappearance, where the node disappears
   without prior notification, and user or after roll-out, node-initiated disassociation
   ("phased-out"), where the network needs node has enough time to be ramped-up. This
initialization phase may include, among others, allocation inform the network
   about its removal.

   The protocol(s) hence SHOULD support the pinpointing of addresses,
(possibly hierarchical) roles problematic
   routing areas as well as an organization of the network which
   facilitates reconfiguration in the network, synchronization,
determination case of association and
   disassociation/disappearance of nodes at lowest possible energy and
   delay.  The latter may include the change of hierarchies, routing
   paths, packet forwarding schedules, etc.

If initialization is performed prior  Furthermore, to roll-out, all inform the
   access point(s) of the node's arrival and association with the
   network as well as freshly associated nodes are likely
to about packet forwarding
   schedules, roles, etc, appropriate (link state) updating mechanisms
   SHOULD be in each others 1-hop radio neighborhood. Pre-programmed MAC and
routing protocols may hence fail to function properly, thereby wasting a
large amount supported.

4.3.  Regular Measurement Reporting

   The majority of energy. Whilst the major burden sensing nodes will be on resolving MAC
conflicts, any proposed U-LLN routing protocol needs configured to cater for such report their
   readings on a
case. For instance, 0-configuration regular basis.  The frequency of data sensing and network address allocation needs
to
   reporting may be properly supported, etc.

If initialization different but is performed after roll-out, nodes will have a finite
set of one-hop neighbors, likely of low cardinality (in generally expected to be fairly
   low, i.e. in the order range of 5-
10). Any proposed LLN routing protocol ought to support once per hour, per day, etc.  The ratio
   between data sensing and reporting frequencies will determine the autonomous
organization
   memory and configuration data aggregation capabilities of the network at lowest possible energy
cost [Lu2007], where autonomy is understood to be the ability nodes.  Latency of the
network to operate without external impact. The result an
   end-to-end delivery and acknowledgements of such
organization ought to a successful data
   delivery may not be that each node vital as sensing outages can be observed at the
   access point(s) - when, for instance, there is no reading arriving
   from a given sensor or sets cluster of nodes are uniquely
addressable so as sensors within a day.  In this
   case, a query can be launched to facilitate check upon the set up state and
   availability of schedules, etc. a sensing node or sensing cluster.

   The U-LLN routing protocol(s) hence MUST accommodate both unicast and
multicast forwarding schemes. Broadcast forwarding schemes are NOT
adviced in urban sensor networking environments.

3.2.   Association and disassociation/disappearance support a large number of highly
   directional unicast flows from the sensing nodes

After or sensing clusters
   towards the access point or highly directed multicast or anycast
   flows from the initialization phase and possibly some operational time, new nodes towards multiple access points.

   Route computation and selection may be injected into depend on the network as well as existing nodes removed
from transmitted
   information, the network. The former might 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 because a removed node is replaced
or denser readings/actuations reported
   every hour via one set of battery-powered nodes, whereas air quality
   indicators are needed or reported only during daytime via nodes powered by
   solar energy.  More generally, entire routing protocols report
connectivity problems. The latter might areas may be because a node's battery is
depleted, the node is removed for maintenance, avoided at
   e.g. night but heavily used during the node is stolen or
accidentally destroyed, etc. Differentiation should day when nodes are scavenging
   from sunlight.

4.4.  Queried Measurement Reporting

   Occasionally, network external data queries can 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 launched by one or
   several access points.  For instance, it is desirable to inform know the network about its removal.
   level of pollution at a specific point or along a given road in the
   urban environment.  The protocol(s) hence ought 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 support the pinpointing same access point from where the query was launched.
   Round-trip times, i.e. from the launch of problematic
routing areas as well as a query from an organization access
   point towards the delivery of the network which
facilitates reconfiguration measured data to an access point,
   are of importance.  However, they are not very stringent where
   latencies SHOULD simply be sufficiently smaller than typical
   reporting intervals; for instance, in the case of association and
disassociation/disappearance order of nodes at lowest possible energy seconds or minute.
   To facilitate the query process, U-LLN network devices SHOULD support
   unicast and
delay. multicast routing capabilities.

   The latter may include the change same approach is also applicable for schedule update,
   provisioning of hierarchies, routing paths,
packet forwarding schedules, patches and upgrades, etc. Furthermore, to inform  In this case, however,
   the access
point(s) provision of acknowledgements and the node's arrival support of unicast,
   multicast, and association with anycast are of importance.

4.5.  Alert Reporting

   Rarely, the network as well
as freshly associated sensing nodes about packet forwarding schedules, roles,
etc, appropriate (link state) updating mechanisms ought 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 be supported.

3.3.   Regular measurement
   change their sensing and reporting

The majority cycles.  An alarm is likely being
   registered by a plurality of sensing nodes will be configured to report their
readings on where the delivery of a regular basis. The frequency
   single alert message with its location of data sensing and origin suffices in most
   cases.  One example of alert reporting
may be different but is generally expected to be fairly low, i.e. in if the
range level of once per hour, per day, etc. The ratio between data toxic gases
   rises above a threshold, thereupon the sensing and
reporting frequencies will determine nodes in the memory and data aggregation
capabilities vicinity
   of this event report the nodes. Latency of an end-to-end delivery and
acknowledgements danger.  Another example of alert reporting
   is when a successful data delivery are not vital as sensing
outages can be observed at the access point(s) recycling glass container - when, for instance,
there is no reading arriving from equipped with a given sensor or cluster
   measuring its level of sensors
within a day. In this case, a query can be launched to check upon occupancy - reports that the
state container is full
   and availability of a sensing node or sensing cluster.

The protocol(s) hence ought needs to support a large number of highly
directional unicast flows from be emptied.

   Routing within urban sensor networks SHOULD require the sensing U-LLN nodes or sensing clusters
   to dynamically compute, select and install different paths towards a
   same destination, depending on the access point or highly directed multicast or anycast flows
from nature of the traffic.  From this
   perspective, such nodes towards multiple access points.

Route computation and selection may depend on the transmitted
information, SHOULD inspect the frequency contents of reporting, traffic
   payload for making routing and forwarding decisions: for example, the amount
   analysis of energy remaining
in the nodes, traffic payload SHOULD be derived into aggregation
   capabilities for the recharging pattern sake of energy-scavenged nodes, etc. For
instance, temperature readings could forwarding efficiency.

   Routes clearly need to be reported every hour via unicast (towards one set access point) or
   multicast (towards multiple access points).  Delays and latencies are
   important; however, again, deliveries within seconds SHOULD suffice
   in most of battery-powered nodes, whereas air quality indicators the cases.

5.  Traffic Pattern

   Unlike traditional ad hoc networks, the information flow in U-LLNs is
   highly directional.  There are reported
only during daytime via nodes powered by solar energy. More generally,
entire routing areas may three main flows to be avoided at e.g. night but heavily used
during distinguished:

   1.  sensed information from the day when sensing nodes are scavenging from sunlight.

3.4.   Queried measurement reporting

Occasionally, network external data queries can be launched by towards one or
several access points. 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 subset
       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 from where the point(s);

   2.  query was launched. Round-trip times,
i.e. requests from the launch of a query access point(s) towards the sensing
       nodes;

   3.  control information from an the access point point(s) towards the
delivery
       actuators.

   Some of the measured flows may need the reverse route for delivering
   acknowledgements.  Finally, in the future, some direct information
   flows between field devices without access points may also occur.

   Sensed data is likely to an access point, are of importance.
However, they are not very stringent where latencies should simply be
sufficiently smaller than typical reporting intervals; for instance, highly correlated in
the order space, time and
   observed events; an example of seconds or minute. To facilitate the query process, U-LLN
network devices should support unicast and multicast routing
capabilities.

The same approach latter is also applicable for schedule update, provisioning
of patches when temperature
   increase and upgrades, etc. In this case, however, humidity decrease as the provision of
acknowledgements day commences.  Data may be
   sensed and delivered at different rates with both rates being
   typically fairly low, i.e. in the support range of broadcast (in addition minutes, hours, days, etc.
   Data may be delivered regularly according to unicast
and multicast) are of importance.

3.5.   Alert reporting

Rarely, the sensing nodes will measure 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 which classifies or alert.  Data delivery may trigger acknowledgements
   or maintenance traffic in the reverse direction.  The network hence
   needs to be able to adjust to the varying activity duty cycles, as
alarm where
   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 classification is typically done locally within each
node by means of live meter reading for customer service in a pre-programmed
   smart-metering application, or prior diffused threshold. Note 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
on approaching different application
   traffic may require different priorities when traversing the alert threshold level, nodes network,
   and that some traffic may wish be more sensitive to change their
sensing and reporting cycles. latency.

   An alarm is likely being registered by a
plurality of U-LLN SHOULD support occasional large scale traffic flows from
   sensing nodes where to access points, such as system-wide alerts.  In the delivery
   example of an AMI U-LLN this could be in response to events such as a single alert message
with its location of origin suffices
   city wide power outage.  In this scenario all powered devices in most cases. One example a
   large segment of alert
reporting is if the level network may have lost power and are running off
   of toxic gases rises above a threshold,
thereupon temporary `last gasp' source such as a capacitor or small
   battery.  A node MUST be able to send its own alerts toward an access
   point while continuing to forward traffic on behalf of other devices
   who are also experiencing an alert condition.  The network MUST be
   able to manage this sudden large traffic flow.  It may be useful for
   the sensing nodes routing layer to collaborate with the application layer to
   perform data aggregation, in order to reduce the vicinity total volume of a
   large traffic flow, and make more efficient use of this event report the
danger. Another example limited energy
   available.

   An U-LLN may also need to support efficient large scale messaging to
   groups of alert reporting is when actuators.  For example, an AMI U-LLN supporting a glass container -
equipped with city-
   wide demand response system will need to efficiently broadcast demand
   response control information to a sensor measuring its level large subset of occupancy - reports that actuators in the container is full
   system.

   Some scenarios will require internetworking between the U-LLN and hence needs to be emptied.

Routes clearly
   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 unicast (towards one access point) to inform a customer
   of incentives to reduce demand during peaks, or
multicast (towards multiple access points). Delays and latencies are
important; however, again, deliveries within seconds should suffice in
most 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 cases.

4. 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 Urban LLN applications 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.

4.1.

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
   hundred nodes; future roll-outs, however, may easily reach numbers in
   the tens of thousands. thousands to millions.  One of the utmost important LLN
   routing protocol design criteria is hence scalability.

   The routing protocol(s) MUST be scalable so as to accommodate a very
   large and increasing number of nodes without deteriorating to-be-
   specified performance parameters below to-be-specified thresholds.

4.2.   Parameter constrained
   The routing protocols(s) SHOULD support the organization of a large
   number of nodes into regions of to-be-specified 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.

4.3.

6.3.  Support of autonomous Autonomous and alien configuration Alien Configuration

   With the large number of nodes, manually configuring and
   troubleshooting each node is not possible. 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,
   ability to support (network-external) patches and configuration
   updates.  For the latter, the protocol(s) MUST support multi- and broad-cast
   any-cast addressing.  The protocol(s) SHOULD also support the
   formation and identification of groups of field devices in the
   network.

4.4.

6.4.  Support of highly directed information flows Highly Directed Information Flows

   The reporting of the data readings by a large amount of spatially
   dispersed nodes towards a few access points 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, 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 highly directed traffic flow to facilitate scalability and
   parameter constrained routing.

4.5.

6.5.  Support of heterogeneous field devices 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 MUST support different devices and
   underlying technologies without compromising the operability and
   energy efficiency of the network.

4.6.

6.6.  Support of multicast Multicast, Anycast, and implementation Implementation of groupcast Groupcast

   Some urban sensing systems require low-level addressing of a group of
nodes in 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].

   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].  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 same subnet without any prior creation of multicast groups,
simply carrying a list scope of recipients in the subnet [draft-brandt-roll-
home-routing-reqs-01].

To this end,
   document that focuses on the routing protocol(s) MUST support requirements aspects.

   Note: with IP multicast, where signaling mechanisms are used by a receiver
   to join a group and the
routing protocol(s) MUST provide sender does not know the receivers of the
   group.  What is required is the ability to forward a packet towards
a single field device (unicast) or address a set group of devices explicitly
belonging
   receivers known by the sender even if the receivers do not need to
   know that they have been grouped by the same group/cast (multicast). Routing protocols
activated sender (since requesting each
   individual node to join a multicast group would be very energy-
   consuming).

6.7.  Network Dynamicity

   Although mobility is assumed to be low in urban sensor networks must be able LLNs, network
   dynamicity due to support unicast

(traffic node association, disassociation and disappearance,
   as well as long-term link perturbations is sent not negligible.  This in
   turn impacts re-organization and re-configuration convergence as well
   as routing protocol convergence.

   To this end, local network dynamics SHOULD NOT impact the entire
   network to a single field device) be re-organized or re-reconfigured; however, the network
   SHOULD be locally optimized to cater for the encountered changes.
   Convergence and route establishment times SHOULD be significantly
   lower than the smallest reporting interval.

6.8.  Latency

   With the exception of alert reporting solutions and multicast (traffic is
sent to a set certain
   extent queried reporting, U-LLN are delay tolerant as long as the
   information arrives within a fraction of devices that belong to the same group/cast) forwarding
schemes. Routing protocols activated in urban sensor networks smallest reporting
   interval, e.g. a few seconds if reporting is done every 4 hours.

   To this end, the routing protocol(s) SHOULD
accommodate "groupcast" forwarding schemes, where traffic is sent to support minimum latency
   for alert reporting and time-critical data queries.  For regular data
   reporting, it SHOULD support latencies not exceeding a
set fraction of devices that implicitly belong
   the smallest reporting interval.  Due to the same group/cast.

The different latency
   requirements, the routing protocol(s) SHOULD support the ability of unicast, groupcast and multicast
   dealing with different latency requirements.  The routing protocol(s)
   SHOULD also has an implication
on the addressing scheme but is beyond support the scope ability to route according to different
   metrics (one of this document that
focuses on the routing requirements aspects.

Note: with IP multicast, signaling mechanisms which could e.g. be latency).

7.  Security Considerations

   As every network, U-LLNs are used by a receiver exposed to
join a group security threats that MUST be
   addressed.  The wireless and distributed nature of these networks
   increases the sender does not know spectrum of potential security threats.  This is
   further amplified by the receivers resource constraints of the group.
What is required is nodes, thereby
   preventing resource intensive security approaches from being
   deployed.  A viable 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 ability design process, so
   as to address facilitate a group commercially attractive deployment.

   A secure communication in a wireless network encompasses three main
   elements, i.e. confidentiality (encryption of receivers known by
the sender even if the receivers do not need data), integrity
   (correctness of data), and authentication (legitimacy of data).

   U-LLN networks SHOULD support mechanisms to know preserve the
   confidentiality of the traffic that they have been
grouped by the sender (since requesting each individual node to join a
multicast group would forward.  The U-LLN network
   SHOULD NOT prevent an application from employing additional
   confidentiality mechanisms.

   Authentication can e.g. be very energy-consuming).

4.7.   Network dynamicity

Although mobility is assumed to violated if external sources insert
   incorrect data packets; integrity can e.g. be low in urban LLNs, network dynamicity
due violated if nodes start
   to node association, disassociation break down and disappearance is not
negligible. This in turn impacts re-organization hence commence measuring and re-configuration
convergence relaying data
   incorrectly.  Nonetheless, some sensor readings as well as routing protocol convergence.

To this end, local network dynamics SHOULD NOT impact the entire
   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 re-organized prevented from
   manipulating or re-reconfigured; however, disabling the network routing function by compromising
   routing update messages.  Moreover, it SHOULD NOT be
locally optimized possible to cater for
   coerce the encountered changes. Convergence and
route establishment times SHOULD be significantly lower than network into routing packets which have been modified in
   transit.  To this end the routing protocol(s) MUST support message
   integrity.

   Further example security issues which may arise are the inverse 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 smallest reporting cycle.

4.8.   Latency

With 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 exception network power, etc.

   The properties of alert reporting solutions self-configuration and to a certain extent
queried reporting, U-LLN self-organization which are delay tolerant as long as the information
arrives within
   desirable in a fraction U-LLN introduce additional security considerations.
   Mechanisms MUST be in place to deny any rogue node which attempts to
   take advantage of self-configuration and self-organization
   procedures.  Such attacks may attempt, for example, to cause denial
   of service, drain the inverse energy of power constrained devices, or to
   hijack the respective reporting
cycle, e.g. routing mechanism.  A node MUST authenticate itself to a few seconds if reporting
   trusted node that is done every 4 hours.

To this end, already associated with the routing protocol(s) SHOULD support minimum latency for
alert reporting U-LLN before any
   self-configuration or self-organization is allowed to proceed.  A
   node that has already authenticated and time-critical data queries. For regular data
reporting, it SHOULD support latencies not exceeding a fraction of the
inverse of associated with the respective reporting cycle. Due U-LLN
   MUST deny, to the different latency
requirements, the routing protocol(s) SHOULD support maximum extent possible, the ability allocation of
dealing with different latency requirements.
   resources to any unauthenticated peer.  The routing protocol(s)
SHOULD also support the ability to route according MUST
   deny service to different metrics
(one of any node which could e.g. be latency).

5.  Traffic Pattern

tbd

6.  Security Considerations

As every network, U-LLNs are exposed to security threats which, if has not properly addressed, exclude them to be deployed in the envisaged
scenarios. The wireless and distributed nature of these networks
drastically increases the spectrum of potential security threats; this
is further amplified by clearly established trust with
   the serious constraints in node battery power,
thereby preventing previously known security approaches to U-LLN.

   Consideration SHOULD be deployed.
Above mentioned issues require special attention during given to cases where the design
process, so U-LLN may interface
   with other networks such 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 home network.  The U-LLN SHOULD NOT
   interface with any external network which has not established trust.
   The U-LLN SHOULD be capable of data). Since limiting the majority of measured data resources granted in U-LLNs is publicly available, the main
emphasis is on integrity and authenticity
   support of data reports.
Authentication can e.g. be violated if an external sources insert incorrect
data packets; integrity can e.g. network so as not to be violated if nodes start vulnerable to break
down denial
   of service.

   With low computation power and hence commence measuring scarce energy resources, U-LLNs nodes
   may not be able to resist any attack from high-power malicious nodes
   (e.g. laptops and relaying data incorrectly.
Nonetheless, some sensor readings as well as strong radios).  However, the actuator control
signals need amount of damage
   generated to the whole network SHOULD be confidential.

Further example security issues which may arise are commensurate with the abnormal
behavior number
   of nodes which exhibit physically compromised.  For example, an egoistic conduct, such as intruder taking
   control over a single node SHOULD not obeying
network rules, or forwarding no have total access to, or false packets. Other important issues
may arise in be
   able to completely deny service to the context of Denial of Service (DoS) attacks, malicious
address space allocations, advertisement whole network.

   In general, the routing protocol(s) SHOULD support the implementation
   of variable addresses, a wrong
neighborhood, external attacks aimed at injecting dummy traffic to drain security best practices across the network power, etc. U-LLN.  Such an implementation
   ought to include defense against, for example, eavesdropping, replay,
   message insertion, modification, and man-in-the-middle attacks.

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

7.

8.  Open Issues

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

   o  node mobility; and
   * traffic patterns.

8. mobility

9.  IANA Considerations

   This document includes makes no request to of IANA.

9.

10.  Acknowledgements

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

10.

11.  References

10.1

11.1.  Normative References

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

10.2

11.2.  Informative References

[I-D.culler-roll-routing-reqs]
J.P. Vasseur

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

   [I-D.culler-rl2n-routing-reqs]
              Vasseur, J. and D. Culler, Cullerot, "Routing Requirements for Low-Power Wireless Low
              Power And Lossy Networks", draft-culler-roll-routing-reqs-00
              draft-culler-rl2n-routing-reqs-01 (work in progress),
              July 2007.

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

[draft-brandt-roll-home-routing-reqs-01]
A. Brand and J.P. Vasseur, "Home Automation Routing Requirement in Low
Power

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

   [RFC4291]  Hinden, R. and Lossy Networks," draft-brandt-roll-home-routing-reqs-01 (work
in progress), July 2007. 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
   France

   Email: thomas.watteyne@orange-ftgroup.com

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

   Email: tim.winter@ekasystems.com

   Christian Jacquenet
   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.

Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).