WDIFF

draft-ietf-roll-urban-routing-reqs-00.txt --> draft-ietf-roll-urban-routing-reqs-01.txt

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.

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

Dohler, et al. Expires Sep 15, 2008 [Page 1]

Internet-Draft draft-ietf-roll-urban-routing-reqs-00 April 2008
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 -

Dohler, et al. Expires December 3, 2008 [Page 1]

Internet-Draft draft-ietf-roll-urban-routing-reqs-01 June 2008

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

Dohler, et al. Expires Sep 15, December 3, 2008 [Page 2]

Internet-Draft draft-ietf-roll-urban-routing-reqs-00 April draft-ietf-roll-urban-routing-reqs-01 June 2008

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 of multicast and implementation of groupcast. . . 11
4.7. Network dynamicity. . 7
3.4. Link Reliability . . . . . . . . . . . . . . . . . . . 12
4.8. Latency. . . 8
4. Urban LLN Application Scenarios . . . . . . . . . . . . . . . 9
4.1. Deployment of Nodes . . . . . . . .12
5. Traffic Pattern . . . . . . . . . . . . 9
4.2. Association and Disassociation/Disappearance of Nodes . . 10
4.3. Regular Measurement Reporting . . . . . . . . . .13
6. Security Considerations . . . . . 11
4.4. Queried Measurement Reporting . . . . . . . . . . . . . . .13
7. Open Issues 11
4.5. Alert Reporting . . . . . . . . . . . . . . . . . . . . . 12
5. Traffic Pattern . . . . .13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . 12
6. Requirements of Urban LLN Applications . . .14
9. Acknowledgements. . . . . . . . . . . 14
6.1. Scalability . . . . . . . . . . . . .14
10. References. . . . . . . . . . . . 14
6.2. Parameter Constrained Routing . . . . . . . . . . . . . . 14
10.1 Normative References.
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
10.2 Informative References. . . . . . 15
6.6. Support of Multicast, Anycast, and Implementation of
Groupcast . . . . . . . . . . . . 14
Authors' Addresses. . . . . . . . . . . . . 16
6.7. Network Dynamicity . . . . . . . . . . . . . 14
Full Copyright Statement. . . . . . . . 16
6.8. Latency . . . . . . . . . . . . . . . 15

Dohler, et al. Expires Sep 15, 2008 [Page 3]

Internet-Draft draft-ietf-roll-urban-routing-reqs-00 April 2008

1. Introduction

We detail here some application specific routing requirements for Urban
Low Power and Lossy Networks (U-LLNs). A U-LLN is understood to be a
network composed of four key elements, i.e.
1) sensors,
2) actuators,
3) repeaters, and
4) access points,
which communicate wirelessly.

The access point can be used as:
1) router . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 19
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 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

Dohler, et al. Expires December 3, 2008 [Page 3]

Internet-Draft draft-ietf-roll-urban-routing-reqs-01 June 2008

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.

Dohler, et al. Expires December 3, 2008 [Page 4]

Internet-Draft draft-ietf-roll-urban-routing-reqs-01 June 2008

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

3.1. Canonical Network Elements

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

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

Dohler, et al. Expires December 3, 2008 [Page 5]

Internet-Draft draft-ietf-roll-urban-routing-reqs-01 June 2008

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.

Dohler, et al. Expires Sep 15, 2008 [Page 4]

Internet-Draft draft-ietf-roll-urban-routing-reqs-00 April 2008

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)

Dohler, et al. Expires December 3, 2008 [Page 6]

Internet-Draft draft-ietf-roll-urban-routing-reqs-01 June 2008

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)

Dohler, et al. Expires December 3, 2008 [Page 7]

Internet-Draft draft-ietf-roll-urban-routing-reqs-01 June 2008

4. capacitive/inductive energy provision (e.g. active RFID).
The active 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 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 to forward of forwarding data.

Unlike traditional ad hoc networks,

3.4. Link Reliability

The links between the information flow in U-LLNs is
highly directional. There network elements are three main flows volatile due to be distinguished:
1) sensed information 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 sensing 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 towards one or 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 subset link outage.

Furthermore, the outdoors deployment of U-LLNs also has implications
for the access point(s);
2) query requests from interference temperature and hence link reliability and range
if ISM bands are to be used. For instance, if the access point(s) towards 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 sensing nodes;
3) control information from functioning of the access point(s) towards U-LLN.

Finally, nodes appearing and disappearing causes dynamics in the actuators.

Dohler, et al. Expires Sep 15, December 3, 2008 [Page 5] 8]

Internet-Draft draft-ietf-roll-urban-routing-reqs-00 April draft-ietf-roll-urban-routing-reqs-01 June 2008

Some

network which can yield link outages and changes of topologies.

4. Urban LLN Application Scenarios

Urban applications represent a special segment of LLNs with its
unique set of requirements. To facilitate the requirements
discussion in Section 4, 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 the 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 nodes is likely to be highly correlated
happen in space, time and
observed events; an example batches out of a box. Typically, hundreds to thousands of
nodes are being shipped by the latter is when temperature and
humidity increase as manufacturer with pre-programmed
functionalities which are then rolled-out by a service provider or
subcontracted entities. Prior or after roll-out, the day commences. Data may network needs
to be sensed and delivered
at different rates with both rates being typically fairly low, i.e. ramped-up. This initialization phase may include, among
others, allocation of addresses, (possibly hierarchical) roles in the range
network, synchronization, determination of hours, days, schedules, etc. Data

If initialization is performed prior to roll-out, all nodes are
likely to be in one another's 1-hop radio neighborhood. Pre-
programmed MAC and routing protocols may hence fail to function
properly, thereby wasting a large amount of energy. Whilst the major
burden will be delivered regularly according on resolving MAC conflicts, any proposed U-LLN routing
protocol needs to cater for such a schedule or case. For instance,
0-configuration and network address allocation needs to be properly
supported, etc.

After roll-out, nodes will have a regular query; it finite set of one-hop neighbors,
likely of low cardinality (in the order of 5- 10). However, some
nodes may also be delivered irregularly
after an externally triggered query; it deployed in areas where there are hundreds of
neighboring devices. In the resulting topology there may also be triggered after a
sudden network-internal event or alert. The network hence needs to regions
where many (redundant) paths are possible through the network. Other
regions may 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.),

Dohler, et al. Expires December 3, 2008 [Page 9]

Internet-Draft draft-ietf-roll-urban-routing-reqs-01 June 2008

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

Dohler, et al. Expires Sep 15, 2008 [Page 6]

Internet-Draft draft-ietf-roll-urban-routing-reqs-00 April 2008

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 schedules, etc.

If initialization is performed prior to roll-out, all nodes are likely
to be in each others 1-hop radio neighborhood. Pre-programmed MAC at lowest possible energy and
routing protocols
delay. The latter may hence fail to function properly, thereby wasting a
large amount of energy. Whilst include the major burden will be on resolving MAC
conflicts, any proposed U-LLN change of hierarchies, routing protocol needs
paths, packet forwarding schedules, etc. Furthermore, to cater for such a
case. For instance, 0-configuration inform the
access point(s) of the node's arrival and association with the
network address allocation needs
to as well as freshly associated nodes about packet forwarding
schedules, roles, etc, appropriate (link state) updating mechanisms
SHOULD be properly supported, etc.

If initialization is performed after roll-out, supported.

Dohler, et al. Expires December 3, 2008 [Page 10]

Internet-Draft draft-ietf-roll-urban-routing-reqs-01 June 2008

4.3. Regular Measurement Reporting

The majority of sensing nodes will have a finite
set of one-hop neighbors, likely of low cardinality (in the order of 5-
10). Any proposed LLN routing protocol ought be configured to support the autonomous
organization and configuration report their
readings on a regular basis. The frequency of the network at lowest possible energy
cost [Lu2007], where autonomy data sensing and
reporting may be different but is understood generally expected to be fairly
low, i.e. in the ability range of the
network to operate without external impact. once per hour, per day, etc. The result ratio
between data sensing and reporting frequencies will determine the
memory and data aggregation capabilities of such
organization ought to the nodes. Latency of an
end-to-end delivery and acknowledgements of 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.

Dohler, et al. Expires Sep 15, 2008 [Page 7]

Internet-Draft draft-ietf-roll-urban-routing-reqs-00 April 2008 a sensing node or sensing cluster.

The U-LLN routing protocol(s) hence MUST accommodate both support a large number of highly
directional unicast and flows from the sensing nodes or sensing clusters
towards the access point or highly directed multicast forwarding schemes. Broadcast forwarding schemes are NOT
adviced in urban sensor networking environments.

3.2. Association or anycast
flows from the nodes towards multiple access points.

Route computation and disassociation/disappearance selection may depend on the transmitted
information, the frequency of nodes

After reporting, the initialization phase and possibly some operational time, new 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 daytime via nodes powered by
solar energy. More generally, entire routing areas may be injected into avoided at
e.g. night but heavily used during the network as well as existing day when nodes removed are scavenging
from the network. The former might sunlight.

4.4. Queried Measurement Reporting

Occasionally, network external data queries can be because a removed node is replaced
or denser readings/actuations are needed launched by one or routing protocols report
connectivity problems. The latter might be because a node's battery is
depleted, the node
several access points. For instance, it is removed for maintenance, desirable to know the node is stolen
level of pollution at a specific point or
accidentally destroyed, etc. Differentiation should be made between node
disappearance, where along a given road in the node disappears without prior notification, and
user or node-initiated disassociation ("phased-out"),
urban environment. The queries' rates of occurrence are not regular
but rather random, where the node has
enough time heavy-tail distributions seem appropriate to inform the network about its removal.

The protocol(s) hence ought
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 of the network which
facilitates reconfiguration in access
point towards the case delivery of association and
disassociation/disappearance the measured data to an access point,
are of nodes at lowest possible energy and
delay. The latter may include importance. However, they are not very stringent where
latencies SHOULD simply be sufficiently smaller than typical
reporting intervals; for instance, in the change order of hierarchies, seconds or minute.
To facilitate the query process, U-LLN network devices SHOULD support
unicast and multicast routing paths,
packet forwarding schedules, capabilities.

The same approach is also applicable for schedule update,

Dohler, et al. Expires December 3, 2008 [Page 11]

Internet-Draft draft-ietf-roll-urban-routing-reqs-01 June 2008

provisioning of patches and upgrades, etc. Furthermore, to inform In this case, however,
the access
point(s) provision of the node's arrival acknowledgements and association with the network as well
as freshly associated nodes about packet forwarding schedules, roles,
etc, appropriate (link state) updating mechanisms ought to be supported.

3.3. Regular measurement reporting

The majority support of unicast,
multicast, and anycast are of importance.

4.5. Alert Reporting

Rarely, the sensing nodes will be configured to report their
readings on measure an event which classifies as
alarm where such a regular basis. The frequency classification is typically done locally within
each node by means of data a pre-programmed or prior diffused threshold.
Note that on approaching the alert threshold level, nodes may wish to
change their sensing and reporting
may be different but cycles. An alarm is generally expected to be fairly low, i.e. in the
range likely being
registered by a plurality of once per hour, per day, etc. The ratio between data sensing and
reporting frequencies will determine nodes where the memory and data aggregation
capabilities delivery of the nodes. Latency a
single alert message with its location of an end-to-end delivery and
acknowledgements origin suffices in most
cases. One example of alert reporting is if the level of toxic gases
rises above a successful data delivery are not vital as threshold, thereupon the sensing
outages can be observed at nodes in the vicinity
of this event report the access point(s) - when, for instance,
there danger. Another example of alert reporting
is no reading arriving from when a recycling glass container - 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.

Dohler, et al. Expires Sep 15, 2008 [Page 8]

Internet-Draft draft-ietf-roll-urban-routing-reqs-00 April 2008

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
of battery-powered nodes, whereas air quality indicators access point) or
multicast (towards multiple access points). Delays and latencies are reported
only during daytime via nodes powered by solar energy. More generally,
entire routing areas may be avoided at e.g. night but heavily used
during
important; however, again, deliveries within seconds SHOULD suffice
in most of the day when nodes cases.

5. Traffic Pattern

Unlike traditional ad hoc networks, the information flow in U-LLNs is
highly directional. There are scavenging from sunlight.

3.4. Queried measurement reporting

Occasionally, network external data queries can three main flows to be launched by distinguished:

1. sensed information from the sensing nodes towards one or
several a subset
of the access points. For instance, it is desirable to know point(s);

2. query requests from the level
of pollution at a specific point or along a given road in access point(s) towards the urban
environment. The queries' rates sensing
nodes;

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

Dohler, et al. Expires December 3, 2008 [Page 12]

Internet-Draft draft-ietf-roll-urban-routing-reqs-01 June 2008

Some of occurrence are not regular but rather
random, where heavy-tail distributions seem appropriate to model their
behavior. Queries do not necessarily the 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 be reported back to highly correlated in space, time and
observed events; an example of the
same access point from where latter is when temperature
increase and humidity decrease as the query was launched. Round-trip times, day commences. Data may be
sensed and delivered at different rates with both rates being
typically fairly low, i.e. from in the launch range of minutes, hours, days, etc.
Data may be delivered regularly according to a query from schedule or a regular
query; it may also be delivered irregularly after an access point towards the externally
triggered query; it may also be triggered after a sudden network-
internal event or alert. Data delivery of may trigger acknowledgements
or maintenance traffic in the measured 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 an access point, are of importance.
However, they are not very stringent where latencies should simply
be
sufficiently smaller than typical reporting intervals; secured and locatable.

Some data delivery may have tight latency requirements, for instance, example
in
the order of seconds a case such as a live meter reading for customer service in a
smart-metering application, or minute. To facilitate 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 when traversing the query process, network,
and that some traffic may be more sensitive to latency.

An U-LLN
network devices should SHOULD support unicast and multicast routing
capabilities.

The same approach is also applicable for schedule update, provisioning occasional large scale traffic flows from
sensing nodes to access points, such as system-wide alerts. In the
example of patches and upgrades, etc. an AMI U-LLN this could be in response to events such as a
city wide power outage. In this case, however, the provision scenario all powered devices in a
large segment of
acknowledgements and the support of broadcast (in addition to unicast network may have lost power and multicast) are running off
of importance.

3.5. Alert reporting

Rarely, the sensing nodes will measure an event which classifies as
alarm where such a classification is typically done locally within each
node by means of temporary `last gasp' source such as a pre-programmed capacitor or prior diffused threshold. Note that
on approaching the alert threshold level, nodes may wish small
battery. A node MUST be able to change their
sensing and reporting cycles. An alarm is likely being registered by a
plurality of sensing nodes where the delivery send its own alerts toward an access
point while continuing to forward traffic on behalf of a single other devices
who are also experiencing an alert message condition. The network MUST be
able to manage this sudden large traffic flow. It may be useful for
the routing layer to collaborate with its location of origin suffices the application layer to
perform data aggregation, in most cases. One example of alert
reporting is if order to reduce the level total volume of toxic gases rises above a threshold,
thereupon the sensing nodes in the vicinity
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.

Dohler, et al. Expires Sep 15, December 3, 2008 [Page 9] 13]

Internet-Draft draft-ietf-roll-urban-routing-reqs-00 April draft-ietf-roll-urban-routing-reqs-01 June 2008

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.

Dohler, et al. Expires December 3, 2008 [Page 14]

Internet-Draft draft-ietf-roll-urban-routing-reqs-01 June 2008

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

Dohler, et al. Expires Sep 15, 2008 [Page 10]

Internet-Draft draft-ietf-roll-urban-routing-reqs-00 April 2008 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.

Dohler, et al. Expires December 3, 2008 [Page 15]

Internet-Draft draft-ietf-roll-urban-routing-reqs-01 June 2008

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 the same subnet subnet, or for a node representative of a group of
nodes, without any prior creation of multicast groups, simply
carrying a list of recipients 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 scope of this
document that focuses on the routing requirements aspects.

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

6.7. Network Dynamicity

Although mobility is assumed to be low in the subnet [draft-brandt-roll-
home-routing-reqs-01]. urban LLNs, network
dynamicity due to node association, disassociation and disappearance,
as well as long-term link perturbations is not negligible. This in
turn impacts re-organization and re-configuration convergence as well
as routing protocol convergence.

To this end, local network dynamics SHOULD NOT impact the routing protocol(s) MUST support multicast, where the
routing protocol(s) MUST provide the ability entire
network to forward a packet towards
a single field device (unicast) be re-organized or a set of devices explicitly
belonging re-reconfigured; however, the network
SHOULD be locally optimized to cater for the same group/cast (multicast). Routing protocols
activated in urban sensor networks must encountered changes.
Convergence and route establishment times SHOULD be able significantly
lower than the smallest reporting interval.

6.8. Latency

With the exception of alert reporting solutions and to support unicast a certain
extent queried reporting, U-LLN are delay tolerant as long as the

Dohler, et al. Expires Sep 15, December 3, 2008 [Page 11] 16]

Internet-Draft draft-ietf-roll-urban-routing-reqs-00 April draft-ietf-roll-urban-routing-reqs-01 June 2008

(traffic is sent to

information arrives within a single field device) and multicast (traffic fraction of the smallest reporting
interval, e.g. a few seconds if reporting is
sent to done every 4 hours.

To this end, the routing protocol(s) SHOULD support minimum latency
for alert reporting and time-critical data queries. For regular data
reporting, it SHOULD support latencies not exceeding a set fraction of devices that belong
the smallest reporting interval. Due to the same group/cast) forwarding
schemes. Routing protocols activated in urban sensor networks different latency
requirements, the routing protocol(s) SHOULD
accommodate "groupcast" forwarding schemes, where traffic is sent support the ability of
dealing with different latency requirements. The routing protocol(s)
SHOULD also support the ability to route according to a
set different
metrics (one of devices that implicitly belong which could e.g. be latency).

7. Security Considerations

As every network, U-LLNs are exposed to the same group/cast. security threats that MUST be
addressed. The support of unicast, groupcast wireless and multicast also has an implication
on distributed nature of these networks
increases the addressing scheme but spectrum of potential security threats. This is beyond
further amplified by the scope resource constraints of this document that
focuses on the routing requirements aspects.

Note: with IP multicast, signaling mechanisms are used by 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 receiver U-LLN.
These issues require special attention during the design process, so
as to
join facilitate a group 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 the sender does not know the receivers authentication (legitimacy of the group.
What is required is the ability data).

U-LLN networks SHOULD support mechanisms to address a group of receivers known by preserve the sender even if
confidentiality of the receivers do not need to know 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 violated if external sources insert
incorrect data packets; integrity can e.g. be violated if nodes start
to break down and hence commence measuring and relaying data
incorrectly. Nonetheless, some sensor readings as well as the
actuator control signals need to be low in urban LLNs, confidential.

The U-LLN network dynamicity
due MUST deny all routing services to any node association, disassociation and disappearance is who has
not
negligible. This in turn impacts re-organization been authenticated to the U-LLN and re-configuration
convergence as well as routing protocol convergence.

To this end, local network dynamics SHOULD NOT impact authorized for the entire network
to use of
routing services.

The U-LLN MUST be re-organized protected against attempts to inject false or re-reconfigured; however, the network
modified packets. For example, an attacker SHOULD be
locally optimized to cater for prevented from
manipulating or disabling the encountered changes. Convergence and
route establishment times routing function by compromising
routing update messages. Moreover, it SHOULD NOT be significantly lower than possible to

Dohler, et al. Expires December 3, 2008 [Page 17]

Internet-Draft draft-ietf-roll-urban-routing-reqs-01 June 2008

coerce the inverse
of network into routing packets which have been modified in
transit. To this end the smallest reporting cycle.

4.8. Latency

With routing protocol(s) MUST support message
integrity.

Further example security issues which may arise are the exception abnormal
behavior of alert reporting solutions and to a certain extent
queried reporting, U-LLN are delay tolerant as long 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 information
arrives within a fraction context of the inverse Denial of the respective reporting
cycle, e.g. Service (DoS)
attacks, malicious address space allocations, advertisement of
variable addresses, a few seconds if reporting is done every 4 hours.

To this end, wrong neighborhood, external attacks aimed at
injecting dummy traffic to drain the routing protocol(s) SHOULD support minimum latency for
alert reporting network power, etc.

The properties of self-configuration and time-critical data queries. For regular data
reporting, it SHOULD support latencies not exceeding self-organization which are
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. Due routing mechanism. A node MUST authenticate itself to a
trusted node that is already associated with the different latency
requirements, U-LLN before any
self-configuration or self-organization is allowed to proceed. A
node that has already authenticated and associated with the routing protocol(s) SHOULD support U-LLN
MUST deny, to the ability maximum extent possible, the 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).

Dohler, et al. Expires Sep 15, 2008 [Page 12]

Internet-Draft draft-ietf-roll-urban-routing-reqs-00 April 2008

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 home network. The U-LLN SHOULD NOT
interface with any external network encompasses three main
elements, i.e. confidentiality (encryption of data), integrity
(correctness of data), and authentication (legitimacy 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 vulnerable to denial
of service.

With low computation power and scarce energy resources, U-LLNs nodes start
may not be able to break
down and hence commence measuring 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

Dohler, et al. Expires December 3, 2008 [Page 18]

Internet-Draft draft-ietf-roll-urban-routing-reqs-01 June 2008

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.

8. Open Issues

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

o node mobility; and
* traffic patterns.

Dohler, et al. Expires Sep 15, 2008 [Page 13]

Internet-Draft draft-ietf-roll-urban-routing-reqs-00 April 2008

8. mobility

9. IANA Considerations

This document includes makes no request to of IANA.

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

Dohler, et al. Expires December 3, 2008 [Page 19]

Internet-Draft draft-ietf-roll-urban-routing-reqs-01 June 2008

[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

Dohler, et al. Expires Sep 15, 2008 [Page 14]

Internet-Draft draft-ietf-roll-urban-routing-reqs-00 April 2008

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

Dohler, et al. Expires December 3, 2008 [Page 20]

Internet-Draft draft-ietf-roll-urban-routing-reqs-01 June 2008

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

Dohler, et al. Expires December 3, 2008 [Page 21]

Internet-Draft draft-ietf-roll-urban-routing-reqs-01 June 2008

Full Copyright Statement

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.

Dohler, et al. Expires Sep 15, 2008 [Page 15]

Internet-Draft draft-ietf-roll-urban-routing-reqs-00 April 2008

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

Dohler, et al. Expires Sep 15, December 3, 2008 [Page 16] 22]

----