One document matched: draft-dohler-roll-urban-routing-reqs-01.txt
Differences from draft-dohler-roll-urban-routing-reqs-00.txt
Networking Working Group M. Dohler, Ed.
Internet-Draft CTTC
Intended status: Informational T. Watteyne, Ed.
Expires: September 6, 2008 France Telecom R&D
April 7, 2008
Urban WSNs Routing Requirements in Low Power and Lossy Networks
draft-dohler-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 6, 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
Dohler, et al. Expires Sept 6, 2008 [Page 1]
Internet-Draft draft-dohler-roll-urban-routing-reqs-01 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
- given the limited radio range and the large number of nodes -
requires the use of suitable routing protocols. The design of such
protocols will be mainly impacted by the limited resources of the
nodes (memory, processing power, battery, etc) and the
particularities of the outdoors urban application scenario. As such,
for a wireless ROLL solution to be competitive with other incumbent
and emerging solutions, the protocol(s) ought to be energy-efficient,
scalable and autonomous. This documents aims to specify a set of
requirements reflecting these and further U-LLNs tailored
characteristics.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Dohler, et al. Expires Sept 6, 2008 [Page 2]
Internet-Draft draft-dohler-roll-urban-routing-reqs-01 April 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Urban LLN application scenarios. . . . . . . . . . . . . . . . 7
3.1. Deployment of nodes. . . . . . . . . . . . . . . . . . . . 7
3.2. Association and disassociation/disappearance of nodes. . . 8
3.3. Regular measurement reporting. . . . . . . . . . . . . . . 8
3.4. Queried measurement reporting. . . . . . . . . . . . . . . 9
3.5. Alert reporting. . . . . . . . . . . . . . . . . . . . . . 9
4. Requirements of urban LLN applications . . . . . . . . . . . . 10
4.1. Scalability.. . . . . . . . . . . . . . . . . . . . . . . 10
4.2. Parameter constrained routing . . . . . . . . . . . . . . 10
4.3. Support of autonomous and alien configuration . . . . . . 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. . . . . . . . . . . . . . . . . . . . 12
4.8. Latency. . . . . . . . . . . . . . . . . . . . . . . . . .12
5. Traffic Pattern . . . . . . . . . . . . . . . . . . . . . . . .13
6. Security Considerations . . . . . . . . . . . . . . . . . . . .13
7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . .13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . .14
9. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . .14
10. References. . . . . . . . . . . . . . . . . . . . . . . . . . 14
10.1 Normative References. . . . . . . . . . . . . . . . . . . 14
10.2 Informative References. . . . . . . . . . . . . . . . . . 14
Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . . . . . 14
Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . . . 15
Dohler, et al. Expires Sept 6, 2008 [Page 3]
Internet-Draft draft-dohler-roll-urban-routing-reqs-01 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 to a wider infrastructure (e.g. Internet),
2) data sink (e.g. data collection & processing from sensors), and
3) data source (e.g. instructions towards actuators).
There can be several access points connected to the same U-LLN; however,
the number of access points is well below the amount of sensing nodes.
The access points are mainly static, i.e. fixed to a random or pre-
planned location, but can be nomadic, i.e. in form of a walking
supervisor. Access points may but generally do not suffer from any form
of (long-term) resource constraint, except that they need to be small
and sufficiently cheap.
Repeaters generally act as relays with the aim to close coverage and
routing gaps; examples of their use are:
1) prolong the U-LLN's lifetime,
2) balance nodes' energy depletion,
3) build advanced sensing infrastructures.
There can be several repeaters supporting the same U-LLN; however, the
number of repeaters is well below the amount of sensing nodes. The
repeaters are mainly static, i.e. fixed to a random or pre-planned
location. Repeaters may but generally do not suffer from any form of
(long-term) resource constraint, except that they need to be small and
sufficiently cheap. Repeaters differ from access points in that they
neither act as a router nor as a data sink/source. They differ from
actuator and sensing nodes in that they neither control nor sense.
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.
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 Sept 6, 2008 [Page 4]
Internet-Draft draft-dohler-roll-urban-routing-reqs-01 April 2008
Sensing nodes measure a wide gamut of physical data, including but not
limited to:
1) municipal consumption data, such as the smart-metering of gas,
water, electricity, waste, etc;
2) meteorological data, such as temperature, pressure, humidity, sun
index, strength and direction of wind, etc;
3) pollution data, such as polluting gases (SO2, NOx, CO, Ozone),
heavy metals (e.g. Mercury), pH, radioactivity, etc;
4) ambient data, such as allergic elements (pollen, dust),
electromagnetic
pollution, noise levels, etc.
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 other. The number
of sensing nodes connected to a single network is expected to be in the
order of 10^2-10^4; this is still very large and unprecedented in
current roll-outs. Deployment of nodes is likely to happen in batches,
i.e. a box of hundreds of nodes arrives and are deployed. The location
of the nodes is random within given topological constraints, e.g.
placement along a road or river. The nodes are highly resource
constrained, i.e. cheap hardware, low memory and no infinite energy
source. Different node powering mechanisms are available, such as:
1) non-rechargeable battery;
2) rechargeable battery with regular recharging (e.g. sunlight);
3) rechargeable battery with irregular recharging (e.g. opportunistic
energy scavenging);
4) capacitive/inductive energy provision (e.g. active RFID).
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 data.
Unlike traditional ad hoc networks, the information flow in U-LLNs is
highly directional. There are three main flows to be distinguished:
1) sensed information from the sensing nodes towards one or a subset of
the access point(s);
2) query requests from the access point(s) towards the sensing nodes;
3) control information from the access point(s) towards the actuators.
Dohler, et al. Expires Sept 6, 2008 [Page 5]
Internet-Draft draft-dohler-roll-urban-routing-reqs-01 April 2008
Some of the flows may need the reverse route for delivering
acknowledgements. Finally, in the future, some direct information flows
between field devices without access points may also occur.
Sensed data is likely to be highly correlated in space, time and
observed events; an example of the latter is when temperature and
humidity increase as the day commences. Data may be sensed and delivered
at different rates with both rates being typically fairly low, i.e. in
the range of hours, days, etc. Data may be delivered regularly according
to a schedule or a regular query; it may also be delivered irregularly
after an externally triggered query; it may also be triggered after a
sudden network-internal event or alert. The network hence needs to be
able to adjust to the varying activity duty cycles, as well as to period
and aperiodic traffic. Also, sensed data ought to be secured and
locatable.
Finally, the outdoors deployment of U-LLNs has also 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
reliability of the U-LLN.
Section 3 describes a few typical use cases for urban LLN applications
exemplifying deployment problems and related routing issues.
Section 4 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-roll-routing-reqs].
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.
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
Dohler, et al. Expires Sept 6, 2008 [Page 6]
Internet-Draft draft-dohler-roll-urban-routing-reqs-01 April 2008
Schedule: An agreed execution, wake-up, transmission, reception, etc.,
time-table between two or more field devices.
Timeslot: A fixed time interval that may be used for the transmission
or reception 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 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.
3.1. Deployment of nodes
Contrary to other LLN applications, deployment of nodes is likely to
happen in batches out of a box. Typically, hundreds of nodes are being
shipped by the manufacturer with pre-programmed functionalities which
are then rolled-out by a service provider or subcontracted entities.
Prior or after roll-out, the network needs to be ramped-up. This
initialization phase may include, among others, allocation of addresses,
(possibly hierarchical) roles in the network, synchronization,
determination of schedules, etc.
If initialization is performed prior to roll-out, all nodes are likely
to be in each others 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 on resolving MAC
conflicts, any proposed U-LLN routing protocol needs to cater for such a
case. For instance, 0-configuration and network address allocation needs
to be properly supported, etc.
If initialization is performed after roll-out, 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 to support the autonomous
organization and configuration of the network at lowest possible energy
cost [Lu2007], where autonomy is understood to be the ability of the
network to operate without external impact. The result of such
organization ought to be that each node or sets of nodes are uniquely
addressable so as to facilitate the set up of schedules, etc.
Dohler, et al. Expires Sept 6, 2008 [Page 7]
Internet-Draft draft-dohler-roll-urban-routing-reqs-01 April 2008
The U-LLN routing protocol(s) 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 of nodes
After the initialization phase and possibly some operational time, new
nodes may be injected into the network as well as existing nodes removed
from the network. The former might be because a removed node is replaced
or denser readings/actuations are needed or routing protocols report
connectivity problems. The latter might be because a node's battery is
depleted, the node is removed for maintenance, the node is stolen or
accidentally destroyed, etc. Differentiation should be made between node
disappearance, where the node disappears without prior notification, and
user or node-initiated disassociation ("phased-out"), where the node has
enough time to inform the network about its removal.
The protocol(s) hence ought to support the pinpointing of problematic
routing areas as well as an organization of the network which
facilitates reconfiguration in the 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. Furthermore, to inform the access
point(s) of the node's arrival and association with the network as well
as freshly associated nodes about packet forwarding schedules, roles,
etc, appropriate (link state) updating mechanisms ought to be supported.
3.3. Regular measurement reporting
The majority of sensing nodes will be configured to report their
readings on a regular basis. The frequency of data sensing and reporting
may be different but is generally expected to be fairly low, i.e. in the
range of once per hour, per day, etc. The ratio between data sensing and
reporting frequencies will determine the memory and data aggregation
capabilities of the nodes. Latency of an end-to-end delivery and
acknowledgements of a successful data delivery are not 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 cluster of sensors
within a day. In this case, a query can be launched to check upon the
state and availability of a sensing node or sensing cluster.
The protocol(s) hence ought to support a large number of highly
directional unicast flows from the sensing nodes or sensing clusters
towards the access point or highly directed multicast or anycast flows
from the nodes towards multiple access points.
Dohler, et al. Expires Sept 6, 2008 [Page 8]
Internet-Draft draft-dohler-roll-urban-routing-reqs-01 April 2008
Route computation and selection may depend on the transmitted
information, the frequency of reporting, the amount of energy remaining
in the nodes, the recharging pattern of energy-scavenged nodes, etc. For
instance, temperature readings could be reported every hour via one set
of battery-powered nodes, whereas air quality indicators are reported
only during daytime via nodes powered by solar energy. More generally,
entire routing areas may be avoided at e.g. night but heavily used
during the day when nodes are scavenging from sunlight.
3.4. Queried measurement reporting
Occasionally, network external data queries can be launched by 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 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 query was launched. Round-trip times,
i.e. from the launch of a query from an access point towards the
delivery of the 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 order of seconds or minute. To facilitate the query process, U-LLN
network devices should support unicast and multicast routing
capabilities.
The same approach is also applicable for schedule update, provisioning
of patches and upgrades, etc. In this case, however, the provision of
acknowledgements and the support of broadcast (in addition to unicast
and multicast) are 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 a pre-programmed or prior diffused threshold. Note that
on approaching the alert threshold level, nodes may wish to change their
sensing and reporting cycles. An alarm is likely being registered by a
plurality of sensing nodes where the delivery of a single alert message
with its location of origin suffices in most cases. One example of alert
reporting is if the level of toxic gases rises above a threshold,
thereupon the sensing nodes in the vicinity of this event report the
danger. Another example of alert reporting is when a glass container -
equipped with a sensor measuring its level of occupancy - reports that
the container is full and hence needs to be emptied.
Dohler, et al. Expires Sept 6, 2008 [Page 9]
Internet-Draft draft-dohler-roll-urban-routing-reqs-01 April 2008
Routes clearly need to be unicast (towards one access point) or
multicast (towards multiple access points). Delays and latencies are
important; however, again, deliveries within seconds should suffice in
most of the cases.
4. Requirements of urban LLN applications
Urban low power and lossy network applications have a number of specific
requirements related to the set of operating conditions, as exemplified
in the previous section.
4.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. 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 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 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. Support of autonomous and alien configuration
With the large number of nodes, manually configuring and troubleshooting
each node is not possible. 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 Sept 6, 2008 [Page 10]
Internet-Draft draft-dohler-roll-urban-routing-reqs-01 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 addressing.
The protocol(s) SHOULD also support the formation and identification of
groups of field devices in the network.
4.4. Support of highly directed information flows
The reporting of the data readings by a large amount of spatially
dispersed nodes towards a few access points 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. Support of heterogeneous field devices
The sheer amount of different field devices will unlikely be provided by
a single manufacturer. A heterogeneous roll-out with nodes using
different physical and medium access control layers is hence likely.
To mandate fully interoperable implementations, the routing protocol(s)
proposed in U-LLN MUST support different devices and underlying
technologies without compromising the operability and energy efficiency
of the network.
4.6. Support of multicast and implementation of groupcast
Some urban sensing systems require low-level addressing of a group of
nodes in the same subnet without any prior creation of multicast groups,
simply carrying a list of recipients in the subnet [draft-brandt-roll-
home-routing-reqs-01].
To this end, the routing protocol(s) MUST support multicast, where the
routing protocol(s) MUST provide the ability to forward a packet towards
a single field device (unicast) or a set of devices explicitly
belonging to the same group/cast (multicast). Routing protocols
activated in urban sensor networks must be able to support unicast
Dohler, et al. Expires Sept 6, 2008 [Page 11]
Internet-Draft draft-dohler-roll-urban-routing-reqs-01 April 2008
(traffic is sent to a single field device) and multicast (traffic is
sent to a set of devices that belong to the same group/cast) forwarding
schemes. Routing protocols activated in urban sensor networks SHOULD
accommodate "groupcast" forwarding schemes, where traffic is sent to a
set of devices that implicitly belong to the same group/cast.
The support of unicast, groupcast and multicast 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).
4.7. Network dynamicity
Although mobility is assumed to be low in urban LLNs, network dynamicity
due to node association, disassociation and disappearance 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 entire network
to 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 inverse
of the smallest reporting cycle.
4.8. Latency
With the exception of alert reporting solutions and to a certain extent
queried reporting, U-LLN are delay tolerant as long as the information
arrives within a fraction of the inverse of the respective reporting
cycle, e.g. a few seconds if reporting is done every 4 hours.
To this end, the routing protocol(s) SHOULD support minimum latency for
alert reporting and time-critical data queries. For regular data
reporting, it SHOULD support latencies not exceeding a fraction of the
inverse of the respective reporting cycle. Due to the different latency
requirements, the routing protocol(s) SHOULD support the ability of
dealing with different latency requirements. The routing protocol(s)
SHOULD also support the ability to route according to different metrics
(one of which could e.g. be latency).
Dohler, et al. Expires Sept 6, 2008 [Page 12]
Internet-Draft draft-dohler-roll-urban-routing-reqs-01 April 2008
5. Traffic Pattern
tbd
6. Security Considerations
As every network, U-LLNs are exposed to security threats which, if
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 the serious constraints in node battery power,
thereby preventing previously known security approaches to be deployed.
Above mentioned issues require special attention during the design
process, so as to facilitate a commercially attractive deployment.
A secure communication in a wireless network encompasses three main
elements, i.e. confidentiality (encryption of data), integrity
(correctness of data), and authentication (legitimacy of data). Since
the majority of measured data in U-LLNs is publicly available, the main
emphasis is on integrity and authenticity of data reports.
Authentication can e.g. be violated if external sources insert incorrect
data packets; integrity can e.g. be violated if nodes start to break
down and hence commence measuring and relaying data incorrectly.
Nonetheless, some sensor readings as well as the actuator control
signals need to be confidential.
Further example security issues which may arise are the abnormal
behavior of nodes which exhibit an egoistic conduct, such as not obeying
network rules, or forwarding no or false packets. Other important issues
may arise in the context of Denial of Service (DoS) attacks, malicious
address space allocations, advertisement of variable addresses, a wrong
neighborhood, external attacks aimed at injecting dummy traffic to drain
the network power, etc.
The 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. Open Issues
Other items to be addressed in further revisions of this document
include:
* node mobility; and
* traffic patterns.
Dohler, et al. Expires Sept 6, 2008 [Page 13]
Internet-Draft draft-dohler-roll-urban-routing-reqs-01 April 2008
8. IANA Considerations
This document includes no request to IANA.
9. Acknowledgements
The in-depth feedback of JP Vasseur, Cisco, and Jonathan Hui, Arch Rock,
is greatly appreciated.
10. References
10.1 Normative References
[RFC2119]
S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels",
BCP 14, RFC 2119, March 1997.
10.2 Informative References
[I-D.culler-roll-routing-reqs]
J.P. Vasseur and D. Culler, "Routing Requirements for Low-Power Wireless
Networks", draft-culler-roll-routing-reqs-00 (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 for 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 and Lossy Networks," draft-brandt-roll-home-routing-reqs-01 (work
in progress), July 2007.
Authors' Addresses
Mischa Dohler
CTTC
Parc Mediterrani de la Tecnologia, Av. Canal Olimpic S/N
08860 Castelldefels, Barcelona
Spain
Email: mischa.dohler@cttc.es
Dohler, et al. Expires Sept 6, 2008 [Page 14]
Internet-Draft draft-dohler-roll-urban-routing-reqs-01 April 2008
Thomas Watteyne
France Telecom R&D
28 Chemin du Vieux Chene
38243 Meylan Cedex
France
Email: thomas.watteyne@orange-ftgroup.com
Christian Jacquenet
France Telecom R&D
4 rue du Clos Courtel BP 91226
35512 Cesson Sevigne
France
Email: christian.jacquenet@orange-ftgroup.com
Giyyarpuram Madhusudan
France Telecom R&D
28 Chemin du Vieux Chene
38243 Meylan Cedex
France
Email: giyyarpuram.madhusudan@orange-ftgroup.com
Gabriel Chegaray
France Telecom R&D
28 Chemin du Vieux Chene
38243 Meylan Cedex
France
Email: gabriel.chegaray@orange-ftgroup.com
Dominique Barthel
France Telecom R&D
28 Chemin du Vieux Chene
38243 Meylan Cedex
France
Email: Dominique.Barthel@orange-ftgroup.com
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
Dohler, et al. Expires Sept 6, 2008 [Page 15]
Internet-Draft draft-dohler-roll-urban-routing-reqs-01 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 Sept 6, 2008 [Page 16]
| PAFTECH AB 2003-2026 | 2026-04-23 03:49:51 |