draft-ietf-roll-protocols-survey-02.txt   draft-ietf-roll-protocols-survey-03.txt 
Networking Working Group P. Levis Networking Working Group P. Levis
Internet-Draft Stanford University Internet-Draft Stanford University
Intended status: Informational A. Tavakoli Intended status: Informational A. Tavakoli
Expires: April 20, 2009 S. Dawson-Haggerty Expires: July 16, 2009 S. Dawson-Haggerty
UC Berkeley UC Berkeley
October 17, 2008 January 12, 2009
Overview of Existing Routing Protocols for Low Power and Lossy Networks Overview of Existing Routing Protocols for Low Power and Lossy Networks
draft-ietf-roll-protocols-survey-02 draft-ietf-roll-protocols-survey-03
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
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 Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 20, 2009. This Internet-Draft will expire on July 16, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
Abstract Abstract
Networks of low power wireless devices introduce novel IP routing Networks of low power wireless devices introduce novel IP routing
issues. Low-power wireless devices, such as sensors, actuators and issues. Low-power wireless devices, such as sensors, actuators and
smart objects, have difficult constraints: very limited memory, smart objects, have difficult constraints: very limited memory,
little processing power, and long sleep periods. As most of these little processing power, and long sleep periods. As most of these
devices are battery-powered, energy efficiency is critically devices are battery-powered, energy efficiency is critically
important. Wireless link qualities can vary significantly over time, important. Wireless link qualities can vary significantly over time,
requiring protocols to make agile decisions yet minimize topology requiring protocols to make agile decisions yet minimize topology
skipping to change at page 2, line 17 skipping to change at page 3, line 7
networks, or whether further work is necessary. networks, or whether further work is necessary.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Table of Contents Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Methodology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Methodology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Suitability Summary . . . . . . . . . . . . . . . . . . . . . 5 4. Suitability Summary . . . . . . . . . . . . . . . . . . . . . 7
4.1. Formal Definitions . . . . . . . . . . . . . . . . . . . . 6 4.1. Formal Definitions . . . . . . . . . . . . . . . . . . . . 8
4.2. Table Scalability . . . . . . . . . . . . . . . . . . . . 6 4.2. Table Scalability . . . . . . . . . . . . . . . . . . . . 8
4.3. Loss Response . . . . . . . . . . . . . . . . . . . . . . 7 4.3. Loss Response . . . . . . . . . . . . . . . . . . . . . . 9
4.4. Control Cost . . . . . . . . . . . . . . . . . . . . . . . 8 4.4. Control Cost . . . . . . . . . . . . . . . . . . . . . . . 9
4.5. Link and Node Cost . . . . . . . . . . . . . . . . . . . . 9 4.5. Link and Node Cost . . . . . . . . . . . . . . . . . . . . 10
5. Routing Protocol Taxonomy . . . . . . . . . . . . . . . . . . 9 5. Routing Protocol Taxonomy . . . . . . . . . . . . . . . . . . 11
6. Link State Protocols . . . . . . . . . . . . . . . . . . . . . 12 5.1. Protocols Today . . . . . . . . . . . . . . . . . . . . . 12
6.1. OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6. Link State Protocols . . . . . . . . . . . . . . . . . . . . . 13
6.2. OLSR . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.1. OSPF & IS-IS . . . . . . . . . . . . . . . . . . . . . . . 13
6.3. TBRPF . . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.2. OLSR & OLSRv2 . . . . . . . . . . . . . . . . . . . . . . 14
7. Distance Vector protocols . . . . . . . . . . . . . . . . . . 13 6.3. TBRPF . . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.1. RIP . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 7. Distance Vector protocols . . . . . . . . . . . . . . . . . . 15
7.2. Ad-hoc On Demand Vector Routing (AODV) . . . . . . . . . . 14 7.1. RIP . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.3. DYMO . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 7.2. Ad-hoc On Demand Vector Routing (AODV) . . . . . . . . . . 15
7.4. DSR . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 7.3. DYMO . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8. Neighbor Discovery . . . . . . . . . . . . . . . . . . . . . . 15 7.4. DSR . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.1. IPv6 Neighbor Discovery . . . . . . . . . . . . . . . . . 15 8. Neighbor Discovery . . . . . . . . . . . . . . . . . . . . . . 16
8.2. MANET-NHDP . . . . . . . . . . . . . . . . . . . . . . . . 15 8.1. IPv6 Neighbor Discovery . . . . . . . . . . . . . . . . . 17
9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 8.2. MANET-NHDP . . . . . . . . . . . . . . . . . . . . . . . . 17
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
12. Annex A - Routing protocol scalability analysis . . . . . . . 16 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
13. Annex B - Logarithmic scaling of control cost . . . . . . . . 19 12. Annex A - Routing protocol scalability analysis . . . . . . . 18
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 13. Annex B - Logarithmic scaling of control cost . . . . . . . . 21
14.1. Normative References . . . . . . . . . . . . . . . . . . . 20 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
14.2. Informative References . . . . . . . . . . . . . . . . . . 20 14.1. Normative References . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 14.2. Informative References . . . . . . . . . . . . . . . . . . 22
Intellectual Property and Copyright Statements . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
1. Terminology 1. Terminology
AODV: Ad-hoc On Demand Vector Routing AODV: Ad-hoc On Demand Vector Routing
DSR: Dynamic Source Routing DSR: Dynamic Source Routing
DYMO: Dynamic Mobile On-Demand DYMO: Dynamic Mobile On-Demand
IS-IS: Intermediate System to Intermediate System
OLSR: Optimized Link State Routing
OSPF: Open Shortest Path First
RIP: Routing Information Protocol
TBRPF: Topology Dissemination Based on Reverse Path Forwarding
LLN: Low power and Lossy Network LLN: Low power and Lossy Network
LSA: Link State Advertisement LSA: Link State Advertisement
LSDB: Link State Database LSDB: Link State Database
MANET: Mobile Ad-hoc Networks MANET: Mobile Ad-hoc Network
MAC: Medium Access Control MAC: Medium Access Control
MPLS: Multiprotocol Label Switching MPLS: Multiprotocol Label Switching
MPR: Multipoint Relays MPR: Multipoint Relays
MTU: Maximum Transmission Unit MTU: Maximum Transmission Unit
OLSR: Optimized Link State Routing
ROLL: Routing in Low power and Lossy Networks ROLL: Routing in Low power and Lossy Networks
TDMA: Time Division Multiple Access TDMA: Time Division Multiple Access
2. Introduction 2. Introduction
Wireless is increasingly important to computer networking. As Wireless is increasingly important to computer networking. As
Moore's Law has reduced computer prices and form factors, networking Moore's Law has reduced computer prices and form factors, networking
includes not only servers and desktops, but laptops, palmtops, and includes not only servers and desktops, but laptops, palmtops, and
cellphones. As computing device costs and sizes have shrunk, small cellphones. As computing device costs and sizes have shrunk, small
wireless sensors, actuators, and smart objects have emerged as an wireless sensors, actuators, and smart objects have emerged as an
important next step in inter-networking. The sheer number of the important next step in internetworking. The sheer number of the low-
low-power networked devices means that they cannot depend on human power networked devices means that they cannot depend on human
intervention (e.g., adjusting position) for good networking: they intervention (e.g., adjusting position) for good networking: they
must have routing protocols that enable them to self-organize into must have routing protocols that enable them to self-organize into
multihop networks. multihop networks.
Energy is a fundamental challenge in these devices. Convenience and Energy is a fundamental challenge in these devices. Convenience and
ease of use requires they be wireless and therefore battery powered. ease of use requires they be wireless and therefore battery powered.
Correspondingly, low power operation is a key concern for this class Correspondingly, low power operation is a key concern for these
of networked device. Cost points and energy limitations cause these sensors and actuators so as to allow them to function for months and
devices to have very limited resources: a few kB of RAM and a few MHz years without interruption. Cost points and energy limitations cause
of CPU is typical. As energy efficiency does not improve with these devices to have very limited resources: a few kB of RAM and a
Moore's Law, these limitations are not temporary. This trend towards few MHz of CPU is typical. As energy efficiency does not improve
smaller, lower power, and more numerous devices has led to new low- with Moore's Law, these limitations are not temporary. This trend
power wireless link layers to support them. In practice, wireless towards smaller, lower power, and more numerous devices has led to
networks observe much higher loss rates than wired ones do, and low- new low-power wireless link layers to support them.
power wireless is no exception. Furthermore, many of these networks
will include powered as well as energy constrained nodes. In practice, wireless networks observe much higher loss rates than
Nevertheless, for cost and scaling reasons, many of these powered wired ones do, and low-power wireless is no exception. Furthermore,
devices will still have limited resources. many of these networks will include powered as well as energy
constrained nodes. Nevertheless, for cost and scaling reasons, many
of these powered devices will still have limited resources.
These low power and lossy networks introduce constraints and These low power and lossy networks introduce constraints and
requirements that other networks typically do not possess requirements that other networks typically do not possess; for
instance, in addition to the constraints of limited resources and
small power sources which constrain the amount of traffic a protocol
may generate, these applications demand an embrace of heterogeneous
node capabilities, and good support for specific traffic patterns
([I-D.ietf-roll-home-routing-reqs] and ([I-D.ietf-roll-home-routing-reqs] and
[I-D.ietf-roll-indus-routing-reqs]). As they were not designed with [I-D.ietf-roll-indus-routing-reqs]).
these requirements in mind, existing protocols may or may not work
well in LLNs. The first step to reaching consensus on a routing As they were not designed with these requirements in mind, existing
protocol for LLNs is to decide which of these two is true. If an protocols may or may not work well in LLNs. The first step to
existing protocol can meet LLN requirements without any changes, then reaching consensus on a routing protocol for LLNs is to decide which
barring extenuating circumstances, it behooves us to use an existing of these two is true. If an existing protocol can meet LLN
standard. However, if no current protocol can meet LLN's requirements without any changes, then barring extenuating
requirements, then further work will be needed to define and circumstances, it behooves us to use an existing standard. However,
standardize with a protocol that can. Whether or not such a protocol if no current protocol can meet LLN's requirements, then further work
involves modifications to an existing protocol or a new protocol will be needed to define and standardize with a protocol that can.
entirely is outside the scope of this document: this document simply Whether or not such a protocol involves modifications to an existing
seeks to answer the question: do LLNs require a new protocol protocol or a new protocol entirely is outside the scope of this
specification document at all? document: this document simply seeks to answer the question: do LLNs
require a new protocol specification document at all?
3. Methodology 3. Methodology
To answer the question of LLNs require new protocol specification To answer the question of LLNs require new protocol specification
work, this document examines existing routing protocols and how well work, this document examines existing routing protocols and how well
they can be applied to low power and lossy networks. It provides a they can be applied to low power and lossy networks. It provides a
set of criteria with which to compare the costs and benefits of set of criteria with which to compare the costs and benefits of
different protocol designs and examines existing protocols in terms different protocol designs and examines existing protocols in terms
of these criteria. of these criteria.
The five criteria this document uses are derived from a set of drafts The five criteria this document uses are derived from a set of drafts
that describe the requirements of a few major LLN application that describe the requirements of a few major LLN application
scenarios. The five criteria, presented in Section 3, are neither scenarios. The five criteria, presented in Section 4, are neither
exhaustive nor complete. Instead, they are one specific subset of exhaustive nor complete. Instead, they are one specific subset of
high-level requirements shared across all of the application high-level requirements shared across all of the application
requirement drafts. Because every application requirement draft requirement drafts. Because every application requirement draft
specifies these criteria, then a protocol which does not meet one of specifies these criteria, then a protocol which does not meet one of
them cannot be used without modifications or extensions. However, them cannot be used without modifications or extensions. However,
because these criteria represent a subset of the intersection of the because these criteria represent a subset of the intersection of the
application requirements, any given application domain may impose application requirements, any given application domain may impose
additional requirements which a particular protocol may not meet. additional requirements which a particular protocol may not meet.
For this reason, these criteria are "necessary but not sufficient." For this reason, these criteria are "necessary but not sufficient."
A protocol that does not meet the criteria cannot be used as A protocol that does not meet the criteria cannot be used as
specified, but it is possible that a protocol meets the criteria yet specified, but it is possible that a protocol meets the criteria yet
is not able to meet the requirements of a particular application is not able to meet the requirements of a particular application
domain. Nevertheless, a protocol that meets all of the criteria domain. Nevertheless, a protocol that meets all of the criteria
would be very promising, and deserve a closer look and consideration would be very promising, and deserve a closer look and consideration
in light of LLN application domains. in light of LLN application domains.
This document considers "existing routing protocols" to be protocols This document considers "existing routing protocols" to be protocols
that are specified in RFCs or, in the cases of DYMO that are specified in RFCs or, in the cases of DYMO
[I-D.ietf-manet-dymo] or OLSRv2 [I-D.ietf-manet-olsrv2] , a very [I-D.ietf-manet-dymo] or OLSRv2 [I-D.ietf-manet-olsrv2] , a very
mature draft which will most likely become an RFC. This document mature draft which will most likely become an RFC. We do not
does not seek to answer the question of whether there is any protocol consider DTN bundles [RFC5050] or the DTN Licklider protocol
anywhere which could meet LLN application requirements. Rather, it [RFC5326] as suggested by the ROLL working group charter, because
seeks to answer whether protocols, as specified in current IETF they are not routing protocols.
standards documents, can meet such requirements. If an existing
protocol specification can be used unchanged, then writing additional We do not examine the Network Mobility Basic Support Protocol (NEMO
protocol specifications is unnecessary. For example, there are many RFC 3963 [RFC3963]) because it is not a routing protocol. We do not
academic papers and experimental protocol implementations available; examine hierarchical NEMO [I-D.thubert-tree-discovery] as a candidate
while one or more of these may meet LLN requirements, if they are not because it only maintains a default route and so is insufficient for
specified in an RFC then a working group will need to write a new RFC general routing. Although NEMO itself is not a suitable routing
for them to be a standard. The question this document seeks to solution to LLNs, some of its mechanisms, such as loop-free tree
answer is not whether proposed, evaluated, theoretical or formation, might be useful in an LLN routing protocol.
hypothetical protocol designs can satisfy LLN requirements: the
question is whether existing IETF standards can. This document does not seek to answer the question of whether there
is any protocol anywhere which could meet LLN application
requirements. Rather, it seeks to answer whether protocols, as
specified in current IETF standards documents, can meet such
requirements. If an existing protocol specification can be used
unchanged, then writing additional protocol specifications is
unnecessary. For example, there are many academic papers and
experimental protocol implementations available; while one or more of
these may meet LLN requirements, if they are not specified in an RFC
then a working group will need to write a new RFC for them to be a
standard. The question this document seeks to answer is not whether
proposed, evaluated, theoretical or hypothetical protocol designs can
satisfy LLN requirements: the question is whether existing IETF
standards can.
Whether a protocol meets these criteria was judged by thinking Whether a protocol meets these criteria was judged by thinking
through each specification and considering the best implementation through each specification and considering a hypothetical
possible. The judgement is based on what a specification allows, implementation which took advantage of the specification so as to
rather than any particular implementation of that specification. For perform as well as possible on the metrics. The judgement is based
example, while many DYMO implementations use hopcount as a routing on what a specification allows, rather than any particular
metric, the DYMO specification allows a hop to add more than one to implementation of that specification. For example, while many DYMO
the routing metric, so DYMO as a specification can support some links implementations use hopcount as a routing metric, the DYMO
or nodes being more costly than others. specification allows a hop to add more than one to the routing
metric, so DYMO as a specification can support some links or nodes
being more costly than others.
4. Suitability Summary 4. Suitability Summary
In this section, we present five important requirements for routing In this section, we present five important requirements for routing
in low power and lossy networks, and evaluate protocols against them. in low power and lossy networks, and evaluate protocols against them.
This evaluation attempts to take a complicated and interrelated set This evaluation attempts to take a complicated and interrelated set
of design decisions and trade-offs and condense them to a simple of design decisions and trade-offs and condense them to a simple
"pass", "fail", or "?". As with any simplification, there is a risk "pass", "fail", or "?". As with any simplification, there is a risk
of removing some necessary nuance. However, we believe that being of removing some necessary nuance. However, we believe that being
forced to take a position on whether or not these protocols are forced to take a position on whether or not these protocols are
skipping to change at page 6, line 30 skipping to change at page 8, line 11
The five criteria are "table scalability", "loss response", "control The five criteria are "table scalability", "loss response", "control
cost", "link cost", and "node cost". For each of these, the value cost", "link cost", and "node cost". For each of these, the value
"pass" indicates that a given protocol has satisfactory performance "pass" indicates that a given protocol has satisfactory performance
according to the metric. The value "fail" indicates that the according to the metric. The value "fail" indicates that the
protocol does not have acceptable performance according to the protocol does not have acceptable performance according to the
metric, and that the RFC defining the protocol does not, as written, metric, and that the RFC defining the protocol does not, as written,
contain sufficient flexibility to alter the protocol to do so. contain sufficient flexibility to alter the protocol to do so.
Finally, "?" indicates that an implementation could exhibit Finally, "?" indicates that an implementation could exhibit
satisfactory performance while following the RFC, but that the satisfactory performance while following the RFC, but that the
implementation descisions necessary to do so are not specified and implementation decisions necessary to do so are not specified and may
may require some exploration. In other words, a "fail" means a require some exploration. In other words, a "fail" means a protocol
protocol would have to be modified so it is not compliant with its would have to be modified so it is not compliant with its RFC in
RFC in order to meet the criterion, while a "?" means a protocol order to meet the criterion, while a "?" means a protocol would
would require a supplementary document further constraining and require a supplementary document further constraining and specifying
specifying how a protocol should behave. how a protocol should behave.
4.1. Formal Definitions 4.1. Formal Definitions
To provide precise definitions of these metrics, we use formal big-O To provide precise definitions of these metrics, we use formal big-O
notation, where N refers to the number of nodes in the network, D notation, where N refers to the number of nodes in the network, D
refers to the number of unique destinations, and L refers to the size refers to the number of unique destinations, and L refers to the size
of a node's local, single-hop neighborhood (the network density). We of a node's local, single-hop neighborhood (the network density). We
explain the derivation of each metric from application requirements explain the derivation of each metric from application requirements
in its corresponding section. in its corresponding section.
skipping to change at page 8, line 17 skipping to change at page 9, line 47
while responses that can rely on O(1) local broadcasts or O(D) route while responses that can rely on O(1) local broadcasts or O(D) route
updates pass. updates pass.
4.4. Control Cost 4.4. Control Cost
Battery-operated devices are a critical component of all three Battery-operated devices are a critical component of all three
application spectrums, and as such special emphasis is placed on application spectrums, and as such special emphasis is placed on
minimizing power consumption to achieve long battery lifetime, minimizing power consumption to achieve long battery lifetime,
[I-D.ietf-roll-home-routing-reqs], with multi-year deployments being [I-D.ietf-roll-home-routing-reqs], with multi-year deployments being
a common case [I-D.ietf-roll-indus-routing-reqs]. In terms of a common case [I-D.ietf-roll-indus-routing-reqs]. In terms of
routing structure, any proposed L2N routing protocol ought to support routing structure, any proposed LLN routing protocol ought to support
the autonomous organization and configuration of the network at the the autonomous organization and configuration of the network at the
lowest possible energy cost [I-D.ietf-roll-urban-routing-reqs]. lowest possible energy cost [I-D.ietf-roll-urban-routing-reqs].
All routing protocols must transmit additional data to detect All routing protocols must transmit additional data to detect
neighbors, build routes, transmit routing tables, or otherwise neighbors, build routes, transmit routing tables, or otherwise
conduct routing. As low-power wireless networks can have very low conduct routing. As low-power wireless networks can have very low
data rates, protocols which require a minimum control packet rate can data rates, protocols which require a minimum control packet rate can
have unbounded control overhead. This is particularly true for have unbounded control overhead. This is particularly true for
event-driven networks, which only report data when certain conditions event-driven networks, which only report data when certain conditions
are met. Regions of a network which never meet the condition can be are met. Regions of a network which never meet the condition can be
skipping to change at page 8, line 41 skipping to change at page 10, line 23
data rate. data rate.
Of course, protocols require the ability to send at least a very Of course, protocols require the ability to send at least a very
small amount of control traffic, in order to discover a topology. small amount of control traffic, in order to discover a topology.
But this bootstrapping discovery and maintenance traffic should be But this bootstrapping discovery and maintenance traffic should be
small: communicating once an hour is far more reasonable than small: communicating once an hour is far more reasonable than
communicating once a second. So while control traffic should be communicating once a second. So while control traffic should be
bounded by data traffic, it requires some leeway to bootstrap and bounded by data traffic, it requires some leeway to bootstrap and
maintain a long-lived yet idle network. maintain a long-lived yet idle network.
The control cost metric is a necessary but not sufficient condition
for a protocol to be a viable routing protocol for LLNs. Protocols
not meeting this bound are unacceptable for use in this environment;
however, there may be protocols which receive a "pass" for this
metric and yet are also unsuitable.
In the case of control traffic, the communication rate (sum of In the case of control traffic, the communication rate (sum of
transmissions and receptions at a node) is a better measure than the transmissions and receptions at a node) is a better measure than the
transmission rate (since energy is consumed for both transmissions transmission rate (since energy is consumed for both transmissions
and receptions). Controlling the transmission rate is insufficient, and receptions). Controlling the transmission rate is insufficient,
as it would mean that the energy cost (sum of transmission and as it would mean that the energy cost (sum of transmission and
receptions) of control traffic could grow with O(L). receptions) of control traffic could grow with O(L).
A protocol fails the control cost criterion if its per-node control A protocol fails the control cost criterion if its per-node control
traffic (transmissions plus receptions) rate is not bounded by the traffic (transmissions plus receptions) rate is not bounded by the
data rate plus a small constant. For example, a protocol using a data rate plus a small constant. For example, a protocol using a
skipping to change at page 9, line 30 skipping to change at page 11, line 18
However, in low power networks it is also desirable to account for However, in low power networks it is also desirable to account for
the cost of routing through particular routers. Applications require the cost of routing through particular routers. Applications require
node or parameter constrained routing, which takes into account node node or parameter constrained routing, which takes into account node
properties and attributes such as power, memory, and battery life properties and attributes such as power, memory, and battery life
that dictate a router's willingness or ability to route other that dictate a router's willingness or ability to route other
packets. Home routing requirements note that devices will vary in packets. Home routing requirements note that devices will vary in
their duty cycle, and that routing protocols should prefer nodes with their duty cycle, and that routing protocols should prefer nodes with
permanent power [I-D.ietf-roll-home-routing-reqs]. The urban permanent power [I-D.ietf-roll-home-routing-reqs]. The urban
requirements note that routing protocols may wish to take advantage requirements note that routing protocols may wish to take advantage
of differing data processing and managment capabilities among network of differing data processing and management capabilities among
devices [I-D.ietf-roll-urban-routing-reqs]. Finally, industrial network devices [I-D.ietf-roll-urban-routing-reqs]. Finally,
requirements cite differing lifetime requirements as an important industrial requirements cite differing lifetime requirements as an
factor to account for [I-D.ietf-roll-indus-routing-reqs]. Node cost important factor to account for [I-D.ietf-roll-indus-routing-reqs].
refers to the ability for a protocol to incorporate router properties Node cost refers to the ability for a protocol to incorporate router
into routing metrics and use node attributes for constraint-based properties into routing metrics and use node attributes for
routing. constraint-based routing.
A "pass" indicates that the protocol contains a mechanism allowing A "pass" indicates that the protocol contains a mechanism allowing
these considerations to be considered when choosing routes. these considerations to be considered when choosing routes.
5. Routing Protocol Taxonomy 5. Routing Protocol Taxonomy
Routing protocols broadly fall into two classes: link-state and Routing protocols broadly fall into two classes: link-state and
distance-vector. distance-vector.
A router running a link-state protocol first establishes adjacency A router running a link-state protocol first establishes adjacency
skipping to change at page 11, line 5 skipping to change at page 12, line 41
Because nodes often have very limited resources for storing routing Because nodes often have very limited resources for storing routing
state, protocols cannot assume that they can store complete neighbor state, protocols cannot assume that they can store complete neighbor
information. For example, a node with 4kB of RAM cannot store full information. For example, a node with 4kB of RAM cannot store full
neighbor state when it has 1000 other nodes nearby. This means that neighbor state when it has 1000 other nodes nearby. This means that
ROLL protocols must have mechanisms to decide which of many possible ROLL protocols must have mechanisms to decide which of many possible
neighbors they monitor as routable next hops. For elements such as neighbors they monitor as routable next hops. For elements such as
2-hop neighborhoods, these decisions can have a significant impact on 2-hop neighborhoods, these decisions can have a significant impact on
the topology that other nodes observe, and therefore may require the topology that other nodes observe, and therefore may require
intelligent logic to prevent effects such as network partitions. intelligent logic to prevent effects such as network partitions.
Protocols Today 5.1. Protocols Today
Wired networks draw from both approaches. OSPF or IS-IS, for Wired networks draw from both approaches. OSPF or IS-IS, for
example, are link-state protocols, while RIP is a distance-vector example, are link-state protocols, while RIP is a distance-vector
protocol. protocol.
MANETs similarly draw from both approaches. OLSR is a link-state MANETs similarly draw from both approaches. OLSR is a link-state
protocol, while AODV and DYMO are distance vector protocols. The protocol, while AODV and DYMO are distance vector protocols. The
general consensus in core networks is to use link state routing general consensus in core networks is to use link state routing
protocols as IGPs for a number of reasons: in many cases having a protocols as IGPs for a number of reasons: in many cases having a
complete network topology view is required to adequately compute the complete network topology view is required to adequately compute the
skipping to change at page 11, line 31 skipping to change at page 13, line 19
speeds (ability to find an alternate path in case of network element speeds (ability to find an alternate path in case of network element
failure), are easier to debug and troubleshoot, and introduce less failure), are easier to debug and troubleshoot, and introduce less
control packet overhead than distance vector protocols. In contrast, control packet overhead than distance vector protocols. In contrast,
distance vector protocols are simpler, require less computation, and distance vector protocols are simpler, require less computation, and
have smaller storage requirements. Most of these tradeoffs are have smaller storage requirements. Most of these tradeoffs are
similar in wireless networks, with one exception. Because wireless similar in wireless networks, with one exception. Because wireless
links can suffer from significant temporal variation, link state links can suffer from significant temporal variation, link state
protocols can have higher traffic loads as topology changes must protocols can have higher traffic loads as topology changes must
propagate globally, while in a distance vector protocol a node can propagate globally, while in a distance vector protocol a node can
make local routing decisions with no effect on the global routing make local routing decisions with no effect on the global routing
topology. One major protocol, DSR, does not easily fit into one of topology. One protocol, DSR, does not easily fit into one of these
these two classes. Although it is a distance vector protocol, DSR two classes. Although it is a distance vector protocol, DSR has
has several properties that make it differ from most other protocols several properties that make it differ from most other protocols in
in this class. We examine these differences in our discussion of this class. We examine these differences in our discussion of DSR.
DSR.
The next two sections summarize several well established routing The next two sections summarize several well established routing
protocols. This table shows, based on the criteria described above, protocols. This table shows, based on the criteria described above,
whether these protocols meet ROLL criteria. Annex A contains the whether these protocols meet ROLL criteria. Annex A contains the
reasoning behind each value in the table. reasoning behind each value in the table.
Protocol Table Loss Control Link Cost Node Cost Protocol Table Loss Control Link Cost Node Cost
OSPF fail fail fail pass fail OSPF/IS-IS fail fail fail pass fail
OLSRv2 fail fail fail pass pass OLSRv2 fail fail ? pass pass
TBRPF fail pass fail pass ? TBRPF fail pass fail pass ?
RIP pass fail pass ? fail RIP pass fail pass ? fail
AODV pass fail pass fail fail AODV pass fail pass fail fail
DYMO[-low] pass fail pass ? fail DYMO[-low] pass fail pass ? fail
DSR fail pass pass fail fail DSR fail pass pass fail fail
6. Link State Protocols 6. Link State Protocols
6.1. OSPF 6.1. OSPF & IS-IS
OSPF (specified in [RFC2328] for IPv4 and in [RFC2740] for IPv6)) is OSPF (specified in [RFC2328] for IPv4 and in [RFC2740] for IPv6)) is
a link state protocol designed for routing within an Internet a link state protocol designed for routing within an Internet
Autonomous System (AS). OSPF provides the ability to divide a Autonomous System (AS). OSPF provides the ability to divide a
network into areas, which can establish a routing hierarchy. The network into areas, which can establish a routing hierarchy. The
topology within an area is hidden from other areas and IP prefix topology within an area is hidden from other areas and IP prefix
reachability across areas (inter-area routing) is provided using reachability across areas (inter-area routing) is provided using
summary LSAs. The hierarchy implies that there is a top-level summary LSAs. The hierarchy implies that there is a top-level
routing area (the backbone area) which connects other areas. Areas routing area (the backbone area) which connects other areas. Areas
may be connected to the back-bone area through a virtual link. OSPF may be connected to the back-bone area through a virtual link. OSPF
maintains routing adjacencies by sending hello messages. OSPF maintains routing adjacencies by sending hello messages. OSPF
calculates the shortest path to a node using link metrics (that may calculates the shortest path to a node using link metrics (that may
reflect the link bandwidth, propagation delay, ...). OSPF Traffic reflect the link bandwidth, propagation delay, ...). OSPF Traffic
Engineering (OSPF-TE, [RFC3630]) extends OSPF to include information Engineering (OSPF-TE, [RFC3630]) extends OSPF to include information
on reservable, unreserved, and available bandwidth. on reservable, unreserved, and available bandwidth.
6.2. OLSR IS-IS (specified in [RFC1142]) is similar in many respects to OSPF,
but as a descendent of the OSI protocol suite differs in some places
such as the way areas are defined and used. However, routing
adjacencies are also maintained by local propagation of the LSDB, and
a shortest path computation is used over a metric space which may
measure delay, errors, or other link properties.
6.2. OLSR & OLSRv2
Optimized Link State Routing (OLSR) (see [RFC3626] and Optimized Link State Routing (OLSR) (see [RFC3626] and
[I-D.ietf-manet-olsrv2]) is a link state routing protocol for [I-D.ietf-manet-olsrv2]) is a link state routing protocol for
wireless mesh networks. OLSR nodes flood route discovery packets wireless mesh networks. OLSR nodes flood link state advertisement
throughout the entire network, such that each node has a map of the packets throughout the entire network, such that each node has a map
mesh topology. Because link variations can lead to heavy flooding of the mesh topology. Because link variations can lead to heavy
traffic when using a link state approach, OLSR establishes a topology flooding traffic when using a link state approach, OLSR establishes a
for minimizing this communication. Each node maintains a set of topology for minimizing this communication. Each node maintains a
nodes called its Multipoint Relays (MPR), which is a subset of the set of nodes called its Multipoint Relays (MPR), which is a subset of
one-hop neighbors whose connectivity covers the two-hop neighborhood. the one-hop neighbors whose connectivity covers the two-hop
Each node that is an MPR maintains a set called its MPR selectors, neighborhood. Each node that is an MPR maintains a set called its
which are nodes that have chosen it to be an MPR. MPR selectors, which are nodes that have chosen it to be an MPR.
OLSR uses these two sets to apply three optimizations. First, only OLSR uses these two sets to apply three optimizations. First, only
MPRs generate link state information. Second, nodes can use MPRs to MPRs generate link state information. Second, nodes can use MPRs to
limit the set of nodes that forward link state packets. Third, an limit the set of nodes that forward link state packets. Third, an
MPR, rather than advertise all of its links, can advertise only links MPR, rather than advertise all of its links, can advertise only links
to its MPR selectors. Together, these three optimizations can to its MPR selectors. Together, these three optimizations can
greatly reduce the control traffic in dense networks, as the number greatly reduce the control traffic in dense networks, as the number
of MPRs should not increase significantly as a network becomes of MPRs should not increase significantly as a network becomes
denser. denser.
skipping to change at page 14, line 40 skipping to change at page 16, line 24
from their route caches. These packets can flood the entire network, from their route caches. These packets can flood the entire network,
giving loss response a fail. giving loss response a fail.
7.3. DYMO 7.3. DYMO
Dynamic Mobile On-Demand routing (DYMO) ([I-D.ietf-manet-dymo]) is an Dynamic Mobile On-Demand routing (DYMO) ([I-D.ietf-manet-dymo]) is an
evolution of AODV. The basic functionality is the same, but it has evolution of AODV. The basic functionality is the same, but it has
different packet formats, handling rules, and supports path different packet formats, handling rules, and supports path
accumulation. Path accumulation allows a single DYMO route request accumulation. Path accumulation allows a single DYMO route request
to generate routes to all nodes along the route to that destination. to generate routes to all nodes along the route to that destination.
Like AODV, DYMO uses hop counts as its routing metric, but links may Like AODV, DYMO uses a distance value as its routing metric which
have a cost >= 1, allowing DYMO to represent link costs. Like AODV, must be at least the hop count, but allows DYMO to represent link
on link breaks DYMO issues a new route request message (RREQ), with a costs. Like AODV, on link breaks DYMO issues a new route request
higher sequence number so nodes do not respond from their route message (RREQ), with a higher sequence number so nodes do not respond
caches. Correspondingly, a route request can flood the entire from their route caches. Correspondingly, a route request can flood
network. the entire network.
7.4. DSR 7.4. DSR
Dynamic Source Routing ([RFC4728]) is a distance vector protocol, but Dynamic Source Routing ([RFC4728]) is a distance vector protocol, but
a DSR packet source explicitly specifies the route for each packet. a DSR packet source explicitly specifies the route for each packet.
Because the route is determined at a single place -- the source -- Because the route is determined at a single place -- the source --
DSR does not require sequence numbers or other mechanisms to prevent DSR does not require sequence numbers or other mechanisms to prevent
routing loops, as there is no problem of inconsistent routing tables. routing loops, as there is no problem of inconsistent routing tables.
Unlike AODV and DYMO, by pushing state into packet headers, DSR does Unlike AODV and DYMO, by pushing state into packet headers, DSR does
not require per-destination routing state. Instead, a node not require per-destination routing state. Instead, a node
skipping to change at page 16, line 16 skipping to change at page 17, line 47
This document presents, considers, and raises no security This document presents, considers, and raises no security
considerations. considerations.
10. IANA Considerations 10. IANA Considerations
This document includes no request to IANA. This document includes no request to IANA.
11. Acknowledgements 11. Acknowledgements
The authors would like to thank all the members of the ROLL working
group for their valuable comments, and the chairs for their helpful
guidance.
We are also indebted to the Sensor Network Architecture group at
Berkeley for contributing their helpful analysis: Prabal Dutta,
Rodrigo Fonseca, Xiaofan Jiang, Jaein Jeong, Jorge Ortiz, and Jay
Tanega.
12. Annex A - Routing protocol scalability analysis 12. Annex A - Routing protocol scalability analysis
This aim of this Annex is to provide the details for the analysis This aim of this Annex is to provide the details for the analysis
routing scalability analysis. routing scalability analysis.
"OSPF" "OSPF & IS-IS"
OSPF floods link state through a network. Each router must receive OSPF floods link state through a network. Each router must receive
this complete link set. OSPF fails the table size criterion because this complete link set. OSPF fails the table size criterion because
it requires each router to discover each link in the network, for a it requires each router to discover each link in the network, for a
total routing table size which is O(N * L). This also causes it to total routing table size which is O(N * L). This also causes it to
fail the control cost criterion, since this information must be fail the control cost criterion, since this information must be
propagated. Furthermore, changes in the link set require re-flooding propagated. Furthermore, changes in the link set require re-flooding
the network link state even if the changed links were not being used. the network link state even if the changed links were not being used.
Since link state changes in wireless networks are often uncorrelated Since link state changes in wireless networks are often uncorrelated
with data traffic and are instead caused by external (environmental) with data traffic and are instead caused by external (environmental)
skipping to change at page 16, line 44 skipping to change at page 18, line 39
links and can consider link properties (Type of Service), as the cost links and can consider link properties (Type of Service), as the cost
associated with an edge is configurable by the system administrator associated with an edge is configurable by the system administrator
[RFC2328], so receive a pass for link cost. However, there is no way [RFC2328], so receive a pass for link cost. However, there is no way
to associate metrics with routers (as costs are only applied to to associate metrics with routers (as costs are only applied to
outgoing interfaces, i.e. edges) when computing paths, and so fails outgoing interfaces, i.e. edges) when computing paths, and so fails
the node cost criteria. While [RFC3630] discusses paths that take the node cost criteria. While [RFC3630] discusses paths that take
into account node attributes, it specifically states that no known into account node attributes, it specifically states that no known
algorithm or mechanism currently exists for incoporating this into algorithm or mechanism currently exists for incoporating this into
the OSPF RFC. the OSPF RFC.
IS-IS receives the same results as OSPF, because it maintains a
consistent LSDB using similar mechanisms, and can account for link
costs but not router costs in its shortest path computation.
"OLSRv2" "OLSRv2"
OLSRv2 is a proactive link state protocol, flooding this information OLSRv2 is a proactive link state protocol, flooding link state
through a set of multipoint relays (MPRs). Routing state includes information through a set of multipoint relays (MPRs). Routing state
1-hop neighbor information for each node in the network, 1-hop and includes 1-hop neighbor information for each node in the network,
2-hop information for neighbors (for MPR selection), and a routing 1-hop and 2-hop information for neighbors (for MPR selection), and a
table (consisting of destination, and next hop), resulting in state routing table (consisting of destination, and next hop), resulting in
proportional to network size and density (O(N*L + L^2)), and failing state proportional to network size and density (O(N*L + L^2)), and
the table scalability criteria. failing the table scalability criteria. Fisheye routing does not
alter the table size.
Unacceptable control traffic overhead arises from flooding and Unacceptable control traffic overhead may arise from flooding and
maintenance. HELLO messages are periodically broadcast local beacon maintenance. HELLO messages are periodically broadcast local beacon
messages, but TC messages spread topology information throughout the messages, but TC messages spread topology information throughout the
network (using MPRs). As such, control traffic is proportional to network (using MPRs). As such, control traffic is proportional to
O(N^2). MPRs reduce this load to O(N^2 / L). As the number of MPRs O(N^2). MPRs reduce this load to O(N^2 / L). As the number of MPRs
is inversely proportional to the density of the network and L is is inversely proportional to the density of the network and L is
bounded by N, this means control traffic is at best proportional to bounded by N, this means control traffic is at best proportional to
O(N), and fails the control cost metric. O(N).
Furthermore, changes in the link set require immediately re-flooding Fisheye routing is a technique to reduce the frequency routing
the network link state even if those links were not being used by updates as the routing update propagates away from its source. This
routing, which fails the loss response metric. has the potential to reduce the control overhead to acceptable
levels, and it is possible to impliment this technique without
violating the specification because the specification does not
require that all updates be sent with the same frequency. However,
there is no specification of how this should be accomplished, or a
guarentee that implementations with different algorithms for deciding
how frequently to age and retransmit topology updates. Thus, OLSR
receives a "?" for the control traffic metric.
Furthermore, changes in the link set may require immediately re-
flooding the network link state even if those links were not being
used by routing, which fails the loss response metric.
OLSR allows for specification of link quality, and also provides a OLSR allows for specification of link quality, and also provides a
'Willingness' metric to symbolize node cost, giving it a pass for 'Willingness' metric to symbolize node cost, giving it a pass for
both those metrics. both those metrics.
"TBRPF" "TBRPF"
As a link state protocol where each node maintains a database of the As a link state protocol where each node maintains a database of the
entire network topology, TBRPF's routing table size scales with entire network topology, TBRPF's routing table size scales with
network size and density, leading to table sizes which are O(N * L) network size and density, leading to table sizes which are O(N * L)
skipping to change at page 19, line 4 skipping to change at page 21, line 14
even if the route is not currently active, leading to a fail for loss even if the route is not currently active, leading to a fail for loss
response [RFC3561]. response [RFC3561].
AODV fails the link cost metric because the only metric used is hop AODV fails the link cost metric because the only metric used is hop
count, and this is hardcoded in the route table entry, according to count, and this is hardcoded in the route table entry, according to
the RFC [RFC3561]. It fails the node cost requirement because there the RFC [RFC3561]. It fails the node cost requirement because there
is no way for a router to indicate its [lack of] willingness to route is no way for a router to indicate its [lack of] willingness to route
while still adhering to the RFC. while still adhering to the RFC.
"DYMO/DYMO-low" "DYMO/DYMO-low"
The design of DYMO shares much with AODV, with some changes to remove The design of DYMO shares much with AODV, with some changes to remove
precursor lists and compact various messages. It still passes the precursor lists and compact various messages. It still passes the
table size criteria because it only maintains routes requested by table size criteria because it only maintains routes requested by
RREQ messages, resulting in O(D) table size. Control traffic (RREQ, RREQ messages, resulting in O(D) table size. Control traffic (RREQ,
RREP, and RREQ) are still driven by data, and hence DYMO passes the RREP, and RREQ) are still driven by data, and hence DYMO passes the
control cost criterion. However, RERR messages are forwarded by any control cost criterion. However, RERR messages are forwarded by any
nodes that have a route using the link, even if inactive, leading to nodes that have a route using the link, even if inactive, leading to
a fail of the loss reponse criteria [I-D.ietf-manet-dymo]. a fail of the loss reponse criteria [I-D.ietf-manet-dymo].
While DYMO does indicate that the metric used for a link can vary DYMO indicates that the "distance" of a link can vary from 1-65535
from 1-65535, it specifically refers to this as distance, which is [I-D.ietf-manet-dymo], leading to a ? in link cost. While additional
incremented by at least one at each hop [I-D.ietf-manet-dymo], routing information can be added DYMO messages, there is no mention
leading to a ? in link cost. While additional routing information of node properties, leading to a fail in node cost.
can be added DYMO messages, there is no mention of node cost, leading
to a fail in node cost.
"DSR" "DSR"
DSR performs on-demand route discovery, and source routing of DSR performs on-demand route discovery, and source routing of
packets. It maintains a source route for all destinations, and also packets. It maintains a source route for all destinations, and also
a blacklist of all unidirectional neighbor links [RFC4728], leading a blacklist of all unidirectional neighbor links [RFC4728], leading
to a total table size of O(D + L), failing the table size criterion. to a total table size of O(D + L), failing the table size criterion.
Control traffic is completely data driven, and so DSR receives a pass Control traffic is completely data driven, and so DSR receives a pass
for this criteria. Finally, a transmission failure only prompts an for this criteria. Finally, a transmission failure only prompts an
unreachable destination to be sent to the source of the message, unreachable destination to be sent to the source of the message,
skipping to change at page 20, line 32 skipping to change at page 22, line 41
14.1. Normative References 14.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
14.2. Informative References 14.2. Informative References
[I-D.ietf-manet-dymo] [I-D.ietf-manet-dymo]
Chakeres, I. and C. Perkins, "Dynamic MANET On-demand Chakeres, I. and C. Perkins, "Dynamic MANET On-demand
(DYMO) Routing", draft-ietf-manet-dymo-14 (work in (DYMO) Routing", draft-ietf-manet-dymo-16 (work in
progress), June 2008. progress), December 2008.
[I-D.ietf-manet-nhdp] [I-D.ietf-manet-nhdp]
Clausen, T., Dearlove, C., and J. Dean, "MANET Clausen, T., Dearlove, C., and J. Dean, "MANET
Neighborhood Discovery Protocol (NHDP)", Neighborhood Discovery Protocol (NHDP)",
draft-ietf-manet-nhdp-07 (work in progress), July 2008. draft-ietf-manet-nhdp-07 (work in progress), July 2008.
[I-D.ietf-manet-olsrv2] [I-D.ietf-manet-olsrv2]
Clausen, T., Dearlove, C., and P. Jacquet, "The Optimized Clausen, T., Dearlove, C., and P. Jacquet, "The Optimized
Link State Routing Protocol version 2", Link State Routing Protocol version 2",
draft-ietf-manet-olsrv2-07 (work in progress), July 2008. draft-ietf-manet-olsrv2-07 (work in progress), July 2008.
[I-D.ietf-roll-home-routing-reqs] [I-D.ietf-roll-home-routing-reqs]
Brandt, A., Buron, J., and G. Porcu, "Home Automation Porcu, G., "Home Automation Routing Requirements in Low
Routing Requirement in Low Power and Lossy Networks", Power and Lossy Networks",
draft-ietf-roll-home-routing-reqs-03 (work in progress), draft-ietf-roll-home-routing-reqs-06 (work in progress),
September 2008. November 2008.
[I-D.ietf-roll-indus-routing-reqs] [I-D.ietf-roll-indus-routing-reqs]
Networks, D., Thubert, P., Dwars, S., and T. Phinney, Networks, D., Thubert, P., Dwars, S., and T. Phinney,
"Industrial Routing Requirements in Low Power and Lossy "Industrial Routing Requirements in Low Power and Lossy
Networks", draft-ietf-roll-indus-routing-reqs-01 (work in Networks", draft-ietf-roll-indus-routing-reqs-03 (work in
progress), July 2008. progress), December 2008.
[I-D.ietf-roll-urban-routing-reqs] [I-D.ietf-roll-urban-routing-reqs]
Dohler, M., Watteyne, T., Winter, T., Jacquenet, C., Dohler, M., Watteyne, T., Winter, T., Barthel, D.,
Madhusudan, G., Chegaray, G., and D. Barthel, "Urban WSNs Jacquenet, C., Madhusudan, G., and G. Chegaray, "Urban
Routing Requirements in Low Power and Lossy Networks", WSNs Routing Requirements in Low Power and Lossy
draft-ietf-roll-urban-routing-reqs-01 (work in progress), Networks", draft-ietf-roll-urban-routing-reqs-03 (work in
July 2008. progress), January 2009.
[I-D.thubert-tree-discovery]
Thubert, P., Bontoux, C., Montavont, N., and B. McCarthy,
"Nested Nemo Tree Discovery",
draft-thubert-tree-discovery-07 (work in progress),
August 2008.
[RFC1142] Oran, D., "OSI IS-IS Intra-domain Routing Protocol",
RFC 1142, February 1990.
[RFC2091] Meyer, G. and S. Sherry, "Triggered Extensions to RIP to [RFC2091] Meyer, G. and S. Sherry, "Triggered Extensions to RIP to
Support Demand Circuits", RFC 2091, January 1997. Support Demand Circuits", RFC 2091, January 1997.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, [RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453,
November 1998. November 1998.
[RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", [RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6",
skipping to change at page 21, line 44 skipping to change at page 24, line 13
Protocol (OLSR)", RFC 3626, October 2003. Protocol (OLSR)", RFC 3626, October 2003.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630, (TE) Extensions to OSPF Version 2", RFC 3630,
September 2003. September 2003.
[RFC3684] Ogier, R., Templin, F., and M. Lewis, "Topology [RFC3684] Ogier, R., Templin, F., and M. Lewis, "Topology
Dissemination Based on Reverse-Path Forwarding (TBRPF)", Dissemination Based on Reverse-Path Forwarding (TBRPF)",
RFC 3684, February 2004. RFC 3684, February 2004.
[RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
Thubert, "Network Mobility (NEMO) Basic Support Protocol",
RFC 3963, January 2005.
[RFC4728] Johnson, D., Hu, Y., and D. Maltz, "The Dynamic Source [RFC4728] Johnson, D., Hu, Y., and D. Maltz, "The Dynamic Source
Routing Protocol (DSR) for Mobile Ad Hoc Networks for Routing Protocol (DSR) for Mobile Ad Hoc Networks for
IPv4", RFC 4728, February 2007. IPv4", RFC 4728, February 2007.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007. September 2007.
[RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol
Specification", RFC 5050, November 2007.
[RFC5326] Ramadas, M., Burleigh, S., and S. Farrell, "Licklider
Transmission Protocol - Specification", RFC 5326,
September 2008.
Authors' Addresses Authors' Addresses
Philip Levis Philip Levis
Stanford University Stanford University
358 Gates Hall, Stanford University 358 Gates Hall, Stanford University
Stanford, CA 94305-9030 Stanford, CA 94305-9030
USA USA
Email: pal@cs.stanford.edu Email: pal@cs.stanford.edu
skipping to change at page 22, line 22 skipping to change at page 25, line 4
Email: pal@cs.stanford.edu Email: pal@cs.stanford.edu
Arsalan Tavakoli Arsalan Tavakoli
UC Berkeley UC Berkeley
Soda Hall, UC Berkeley Soda Hall, UC Berkeley
Berkeley, CA 94707 Berkeley, CA 94707
USA USA
Email: arsalan@eecs.berkeley.edu Email: arsalan@eecs.berkeley.edu
Stephen Dawson-Haggerty Stephen Dawson-Haggerty
UC Berkeley UC Berkeley
Soda Hall, UC Berkeley Soda Hall, UC Berkeley
Berkeley, CA 94707 Berkeley, CA 94707
USA USA
Email: stevedh@cs.berkeley.edu Email: stevedh@cs.berkeley.edu
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
 End of changes. 44 change blocks. 
165 lines changed or deleted 260 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/