ROLL Working Group P. Thubert
Internet-Draft Cisco
Intended status: Standards Track T. Watteyne
Expires: October 11, 2009 UC Berkeley
Z. Shelby
Sensinode
D. Barthel
Orange Labs
April 9, 2009
LLN Routing Fundamentals
draft-thubert-roll-fundamentals-01
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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 October 11, 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Thubert, et al. Expires October 11, 2009 [Page 1]
Internet-Draft LLN Routing Fundamentals April 2009
Abstract
This document describes a basic set of fundamental mechanisms for
routing on a Low-power and Lossy Network (LLN). It does not intend
to specify a full-blown protocol. It is rather offered as a basis to
support the discussion while designing the ROLL protocol.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. Needs . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2. Tree Discovery . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2. Discovery Information . . . . . . . . . . . . . . . . . . 10
2.3. Stability . . . . . . . . . . . . . . . . . . . . . . . . 11
3. Route Dissemination . . . . . . . . . . . . . . . . . . . . . 11
3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2. Disseminated Information . . . . . . . . . . . . . . . . . 12
3.3. LLN Router Operation . . . . . . . . . . . . . . . . . . . 13
4. Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.1. Upstream Forwarding . . . . . . . . . . . . . . . . . . . 15
4.2. Downstream Forwarding . . . . . . . . . . . . . . . . . . 17
5. Multicast Support . . . . . . . . . . . . . . . . . . . . . . 18
5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.2. Receiver Flow . . . . . . . . . . . . . . . . . . . . . . 18
5.3. Source flow . . . . . . . . . . . . . . . . . . . . . . . 19
6. Advanced Features . . . . . . . . . . . . . . . . . . . . . . 19
6.1. Interaction with other routing protocols . . . . . . . . . 19
6.1.1. AODV/DYMO . . . . . . . . . . . . . . . . . . . . . . 19
6.1.2. OSPF/OLSR . . . . . . . . . . . . . . . . . . . . . . 20
6.1.3. MIP6/NEMO . . . . . . . . . . . . . . . . . . . . . . 21
6.2. Route Optimization . . . . . . . . . . . . . . . . . . . . 21
6.2.1. Node-to-node routing . . . . . . . . . . . . . . . . . 21
6.2.2. Offline Path Computation . . . . . . . . . . . . . . . 21
6.2.3. Graph forwarding . . . . . . . . . . . . . . . . . . . 22
6.3. Density . . . . . . . . . . . . . . . . . . . . . . . . . 23
6.4. Digraph Dissemination . . . . . . . . . . . . . . . . . . 24
6.5. Multiple LBRs and Trees . . . . . . . . . . . . . . . . . 24
6.6. Aggregation for Route Dissemination . . . . . . . . . . . 24
6.7. Advanced Forwarding . . . . . . . . . . . . . . . . . . . 25
7. Security Considerations . . . . . . . . . . . . . . . . . . . 25
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
10.1. Normative References . . . . . . . . . . . . . . . . . . . 26
10.2. Informative References . . . . . . . . . . . . . . . . . . 26
Thubert, et al. Expires October 11, 2009 [Page 2]
Internet-Draft LLN Routing Fundamentals April 2009
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28
Thubert, et al. Expires October 11, 2009 [Page 3]
Internet-Draft LLN Routing Fundamentals April 2009
1. Introduction
This document describes a basic set of fundamental mechanisms for
routing on a Low-power and Lossy Network (LLN) appropriate for
scenarios identified by the ROLL working group. It does not intend
to specify a full-blown protocol. It is rather offered as a basis to
support the discussion while designing the ROLL protocol. The
fundamental mechanisms proposed stem from our analysis that current
academic, industrial and IETF protocols suitable to ROLL scenarios
are reduceable to those basic mechanisms.
Those mechanisms provide a core set of functionality that can be
complemented by specific extensions to implement the needs expressed
in the ROLL routing requirement drafts:
o Urban WSNs Routing Requirements in Low Power and Lossy Networks
[I-D.ietf-roll-urban-routing-reqs]
o Building Automation Routing Requirements in Low Power and Lossy
Networks [I-D.ietf-roll-building-routing-reqs]
o Home Automation Routing Requirements in Low Power and Lossy
Networks [I-D.ietf-roll-home-routing-reqs]
o Industrial Routing Requirements in Low Power and Lossy Networks
[I-D.ietf-roll-indus-routing-reqs]
The constraints expressed in the routing requirement documents (such
as on node memory and communication cost) narrow the choice of
fundamental mechanisms down to very simple ones.
Due to the highly directed flows in LLNs, a tree structure comes
naturally to mind as a bare minimum. In a slightly more elaborate
mechanism, we propose that each router memorizes a few best neighbor
routers (not only among its parents up the tree, but also among its
siblings), to choose from (using some routing metric) when routing
towards LLN Border Routers (LBR). However, to reduce complexity, we
propose that only the best parent be advertised up the structure
towards the LBRs, giving each of them a simple tree representation to
be used for routing downstream traffic or for making other global
decisions. Since links and nodes are expected to come and go over
time, mechanisms for tree reorganization are described. However, on
a shorter time scale, transient link failures are bound to happen.
In such a case, we recommend that the link-layer passes packets back
to the network layer for re-routing along alternate paths.
In terms of routing, the basic fundamental methods include uni/
anycast routing up the graph and unicast routing down the tree
Thubert, et al. Expires October 11, 2009 [Page 4]
Internet-Draft LLN Routing Fundamentals April 2009
(either hop-by-hop or source-based). The best neighbor selection
mechanism is left to the protocol design phase. We even suggest that
it be left as a plug-in for future evolution. However, a set of
basic tree discovery and forwarding rules, described here, prevents
loops from forming, in most cases, whatever the routing algorithm
eventually implemented.
More advanced mechanisms which can be built upon the fundamental
mechanisms are also described. They include route optimizations,
dissemination of a digraph, dissemination and maintenance of multiple
overlapping trees, prefix aggregation and advanced forwarding rules.
This document is organized as follows:
Section 1.1 defines the terminology used in this document.
Section 2 concentrates on the basic tree discovery and maintenance
mechanism.
Section 3 introduces the basic distance-vector route dissemination
mechanism.
Section 4 describes the upstream and downstream forwarding rules.
Section 5 describes multicast support.
Section 6 describes advanced mechanisms which can be built upon
these fundamentals.
1.1. Terminology
The terminology used in this document is consistent with and
incorporates that described in [I-D.ietf-roll-terminology]. This
terminology is extended in this document as follows:
to Attach: the action of establishing a child-to-parent relationship
in Tree Discovery.
Tree Depth: the maximum number of edges that need to be traversed
from any tree node to the root.
Discovery: a mechanism by which a logical representation of the
network is built.
Floating, Grounded: a tree is said to be Grounded if it is connected
to a high-capacity backbone or backhaul link to a network such as
the Internet. By contrast, a tree is said to be Floating if it is
not Grounded.
Thubert, et al. Expires October 11, 2009 [Page 5]
Internet-Draft LLN Routing Fundamentals April 2009
Graph: a set of vertices and edges to represent a network of nodes
and links. A Directed Acyclic Graph (DAG) is a graph with
directional edges where no loop is formed.
Uniform Path Metric: A scalar measure for the quality of the bi-
directional path between the LLN Router and the root.
Route Dissemination: the action of establishing state within the
network so that routers know how to forward packets related to
some source-destination pairs.
Router: a network node that is capable of forwarding packets on
behalf of other nodes. In ROLL routing requirement documents, it
appears that most nodes are expected to be routers.
Default Router: the router to turn to when a node has no information
on where to forward a packet.
1.2. Needs
The ROLL working group has identified typical scenarios and their
related requirements for LLN routing. The main requirements on any
fundamental mechanisms used for achieving the ROLL protocol can be
summarized as follows:
o Support for operation in both full IPv6 [RFC2460] and minimal
6LoWPAN [RFC4944] networks.
o Optimized for traffic directed between nodes and LBRs.
o The discovery of multiple disjoint routing paths to increase
reliability.
o Support for multiple LBRs out of the LLN.
o Minimal network state needed by routers, with a hard bound better
than O(D), D being the number of destinations.
o Support for complex unicast, anycast and multicast flows.
o Localized response upon link failures without requiring global
updates.
o Minimal control overhead scaling within O(log(L)) of the data
rate.
o Support for link and node costs along routes.
Thubert, et al. Expires October 11, 2009 [Page 6]
Internet-Draft LLN Routing Fundamentals April 2009
2. Tree Discovery
A tree is the simplest and most basic acyclic graph structure. Even
if it is not sufficient to ensure by itself the multipath forwarding
proposed below, a tree provides the ideal structure for best path
routing between source and sink in a convergecast.
In many occasions, LLNs do not have a clear and stable physical
structure and it becomes necessary to overlay a logical
representation to define links and enable IPv6 operations. LLN Tree
Discovery is the component of the LLN fundamentals that builds and
maintains logical tree structures over the LLN.
The nodes in an LLN discovery tree are Routers; the root is an
arbitrary elected Router if the tree is Floating; it is a LLN Border
Router (LBR) if the tree is Grounded, that is the root is connected
to the infrastructure via a backhaul link or a federating backbone.
A federating backbone such as an extended LoWPAN backbone is the
virtual root of the federated tree. In that case, the LBRs are
attached at a depth of one and are in charge of performing the root
operations on behalf of that virtual root.
A tree is identified by a Tree ID which can take the form of an IPv6
address: in the case of a LoWPAN configuration with a federating
backbone, the LoWPAN prefix is used as the Tree ID. If there is no
backbone, the tree ID will be an address of the root or a prefix
owned by the root. A router attaching to a tree sets a route to the
treeID via its parent in the tree.
A router may attach to and may advertise more than one tree, but it
uses and advertises at most one tree as Default tree. A router sets
up its default route via its parent in its Default tree.
This section describes
1. a minimum extension to IPv6 Neighbor Discovery Router
Advertisements in order to ensure that LLN Routers organize in a
tree structure, and
2. a minimum common algorithmic part that all LLN Routers are
required to implement in order to ensure that, whatever the
individual routing decisions, routing loops between LLN Routers
are avoided and basic optimization is achieved.
LLN Discovery is based on an autonomous decision by each Router with
no global state convergence such as traditionally found in IGPs. In
order to enable backward compatibility and interoperability, LLN
Thubert, et al. Expires October 11, 2009 [Page 7]
Internet-Draft LLN Routing Fundamentals April 2009
Discovery allows Routers to make different decisions from identical
inputs, based on their own configuration and their own algorithms,
though it is highly preferable that the decision algorithm be
consistent in a given deployment to achieve the specific goals of
that deployment.
The signalling mechanism that is used to form the trees is an
extension to the ICMP Router Advertisement (RA) message, namely the
Tree Information Option (TIO). The TIO allows LLN Routers to
advertise the tree they belong to, and to select and move to the best
location within the available trees. LLN Routers propagate the TIO
in RA messages down the tree, updating some metrics such as the Tree
Depth while leaving other information such as the Tree ID unchanged.
This is compatible with RA period reduction techniques such as the
use of Trickle.
2.1. Overview
LLN Tree Discovery is a form of distance vector protocol for use in
wireless meshed networks. Tree Discovery locates the nearest exit
and forms Directed Graphs towards that exit, composed of a best path
tree and alternate forwarding options.
By introducing the concept of routing plug-ins, LLN Tree Discovery
enables LLN Routers to implement different policies for selecting
their preferred parent in the Tree. Tree Discovery does not specify
the plug-in operation, but rather specifies a set of rules to be
implemented by all plug-ins to ensure interoperability.
The Tree Depth is the underlying criterion that garantees loop-free
operations even if plug-ins implement different policies, and even if
these policies do not use Depth as a routing metric.
In order to organize and maintain a loopfree structure, the parent
selection plug-ins in the LLN Routers MUST obey the following rules
and definitions:
1. The root of a tree exposes the tree in the Router Advertisement
(RA) Tree Information Option (TIO) and LLN Routers propagate the
TIO down.
2. An LLN Border Router that is attached to a federating backbone
acts as root and advertises a depth of one. An LBR that is not
attached to a federating backbone is a root and exposes a depth
of zero.
3. An LLN Router that is not a Border Router may be the root of its
own Floating tree. Its depth is zero in that tree. An LLN
Thubert, et al. Expires October 11, 2009 [Page 8]
Internet-Draft LLN Routing Fundamentals April 2009
Router that loses its current parent and has no alternate parent
is back to that same state, but it needs to remember the Tree ID
and the sequence counter in the TIO of the lost parent for a
period of time which covers multiple TIOs.
4. An LLN Router announces its tree as Default in a TIO unless it
also announces its participation to another tree that it uses as
Default. An LBR announces its tree as Default and sets up its
default route over the backhaul or the backbone. An LLN router
that attaches to a tree that is announced as Default may select
that tree as Default in which case it will propagate the Default
information in the TIO for that tree and set up a default route
via its parent in that tree. If the route attaches to other
trees that are also announced as Default, it will reset the
Default for the corresponding TIOs.
5. A router sending an RA without TIO is considered a Grounded
Default Router at depth 0.
6. An LLN Router that is already part of a tree MAY move at any
time and with no delay in order to get closer to the root of its
current tree, i.e. in order to reduce its own tree depth. But
an LLN Router MUST NOT move down the tree that it is attached to
unless the potential parent advertises a Sequence Number that is
newer than the last Sequence Number known for that tree,
indicating that the potential parent is not within this router
subtree.
7. A LLN Router may move from its current default tree into any
different default tree at any time and whatever the depth it
reaches in the new tree but, before it can do so, it may have to
wait for a Tree Hop Timer to elapse. If the router was root of
its own floating tree, it may join its previous tree (identified
by the last parent Tree ID) only if the sequence number in the
TIO was incrememented since the LLN Router left that tree,
indicating that the candidate parent was not attached behind
this LLN Router and kept getting subsequent TIOs from the same
tree. The LLN Router will join that other tree if it is
preferable for reasons of connectivity, configured preference,
available medium time, size, security, bandwidth, tree depth, or
whatever metrics the LLN Router cares to use.
8. If an LLN Router has selected a new parent router but has not
moved yet (because it is waiting for Tree Hop Timer to elapse),
it is said to be unstable and refrains from sending Router
Advertisement - Tree Information Options.
Thubert, et al. Expires October 11, 2009 [Page 9]
Internet-Draft LLN Routing Fundamentals April 2009
9. When a LLN Router joins a tree, moves within its own tree or
receives a modified TIO from its current parent router, it sends
out an unsolicited Router Advertisement message with TIO that
propagates the new tree information.
10. This allows the new higher parts of the tree to be updated
first, eventually dragging their sub-tree with them, and
allowing stepped sub-tree reconfigurations, limiting relative
movements.
2.2. Discovery Information
The Tree Information Option carries a number of metrics and other
information that allows an LLN Router to discover a tree and select
its parent while avoiding loop generation.
TIO Base option
The Tree Information Option is a container option, which might
contain a number of suboptions. The base option regroups the
minimum information set that is mandatory to operate the LLN
Discovery Algorithm.
Default (D): The Default (D) flag is set when the tree is used to
set up the default route. A router that participates to
multiple trees (including self-rooted) announces at most one
tree as Default.
Grounded (G): The Grounded (G) flag is set when the tree is
attached to a fixed network infrastructure (such as the
Internet).
Sequence Number: An integer that is incremented by the root for
each TIO sent on a link. It is propagated unchanged down the
tree.
Tree Depth: If the root is attached to a federating backbone, its
Tree Depth is 1, otherwise it is 0. The Tree Depth of an LLN
Router is the depth of its parent as received in a TIO,
incremented by at least one. All the nodes in the tree
advertise their Tree Depth in the Tree Information Options that
they append to the RA messages as part of the propagation
process.
Tree ID: An IPv6 address which uniquely identifies a tree. This
value is set by the root to one of its ULA or global addresses
or prefixes.
Thubert, et al. Expires October 11, 2009 [Page 10]
Internet-Draft LLN Routing Fundamentals April 2009
Uniform Path Metric: A scalar measure for the quality of the bi-
directional path between the LLN Router and the root.
The following values MUST not change during the propagation of the
TIO down the tree: G, Sequence Number, Tree Delay and Tree ID.
The Default flag MAY only be reset. All other fields are updated
at each hop of the propagation.
In addition to the minimum set of information required, a number
of options can are used, e.g. for bandwidth, stability, preference
etc.
2.3. Stability
An LLN Router is instable when it is prepared to move shortly to
another parent Router. This happens typically when the LLN Router
has selected a more preferred candidate parent Router and has to wait
for the Tree Hop Timer to elapse before roaming. Instability may
also occur when the current parent Router is lost and the next best
one is still held up. Instability is resolved when the Tree Hop
Timer of all the parent Router(s) causing instability elapse.
Instability is transient (on the order of Tree Hop Timers). When an
LLN Router is unstable, it MUST NOT send RAs with TIO. This reduces
the likelyhood of loops when LLN Router A wishes to attach to LLN
Router B and LLN Router B wishes to attach to LLN Router A. Unless
RAs crisscross, a LLN Router only receives TIO from stable parent
Routers, which do not plan to attach to it, so it can safely attach
to one of them.
3. Route Dissemination
3.1. Overview
Route Dissemination is the second component of the LLN fundamental
mechanisms. As explained previously, the first component, LLN Tree
Discovery, establishes a logical tree structure over the LLN and sets
up default routes towards the root of its Default Tree. To establish
the routing states towards the nodes in the LLN and enable complete
reachability along the tree, it suffices for Route Dissemination to
advertise up the tree the host ID, prefix and multicast routes.
As a result, the Default Router for an LLN Router is its parent up in
the Default tree (upstream); and the more specific routes are always
oriented down the tree (downstream).
LLN Tree Discovery does not only provide loop avoidance for the Route
Thubert, et al. Expires October 11, 2009 [Page 11]
Internet-Draft LLN Routing Fundamentals April 2009
Dissemination protocol; LLN Tree Discovery also triggers Route
Dissemination each time a topological change occurs. The loopfree
structure must be restored before Route Dissemination can operate
again and repaint the tree with prefixes, addresses and group
membership.
Each logical tree that LLN Tree Discovery forms is considered a
separate routing topology. If an LLN Router belongs to multiple of
such topologies, then it is expected that both the Route
Dissemination signaling and the data packets are flagged to follow
the topology for which the packet was introduced in the network.
The ROLL Route Dissemination protocol defines a new information
vector called the Route Information Option (RIO) to disseminate
atomic routing information towards the root of the tree.
A parent maintains a state for each information it learns from Route
Dissemination. Advertisements are sequenced and the last sequence
number is kept. An out-of-sequence RIO must be disregarded. If the
RIO information appears valid, it is forwarded to the parent's parent
in the next burst, carried by a RIO, together with the parent's own
information.
3.2. Disseminated Information
Route Dissemination extends RFC4861 and RFC4191 to allow a node to
include a new Route Information Option in ND messages such as
Neighbor Advertisements (NAs).
In order to track the freshness of an advertisement, the RIO includes
a sequence counter that is incremented each time the advertisement is
reissued.
An NA is also sent to the new parent once it has been selected after
a movement, or when the list of advertised information has changed.
Route Dissemination may advertise positive (prefix is present) or
negative (removed) RIOs.
The RIO base option carries sequenced route information for unicast
and multicast; it contains:
Resource type: Prefix, host, or multicast group
Prefix Length: Number of valid leading bits in the IPv6 Prefix.
Thubert, et al. Expires October 11, 2009 [Page 12]
Internet-Draft LLN Routing Fundamentals April 2009
RIO Lifetime: The length of time in seconds (relative to the time
the packet is sent) that the prefix is valid for route
determination.
RIO Depth: Set to 0 by the router that owns the resource and issues
the RIO. Incremented by all routers that propagate the RIO
towards the root.
RIO Sequence: Incremented by the router that owns the resource for
each new RIO for that prefix. Left unchanged by all routers that
propagate the RIO.
Prefix: Variable-length field containing a prefix, an IPv6 address
or a multicast group id.
3.3. LLN Router Operation
Route Dissemination information can be redistributed in another
routing protocol, e.g. MANET or IGP. But the MANET or the IGP route
information SHOULD NOT be redistributed into Route Dissemination.
This creates a hierarchy of routing protocols where Route
Dissemination routes stand somewhere between connected and IGP
routes. See Section Section 6.1 for more discussion on integration
with other routing protocols.
As a result:
o LLN Tree Discovery establishes a tree using extended Neighbor
Discovery RS/RA flows.
o A routing algorithm exploits the tree to optimally move upstream
traffic out of the LLN (default route).
o Route Dissemination extends Neighbor Discovery in order to quickly
establish hop-by-hop routes down the tree.
o Source Routing can be used to provide additional routes towards
nodes in the LLN. When and where there exists hop-by-hop state in
routers, the source routing information can be made sparse.
Route Dissemination maintains abstract lists of known information.
An entry contains the following abstract information:
o A reference to the adjacency that was created for that prefix.
o The IPv6 address of the advertising Neighbor.
Thubert, et al. Expires October 11, 2009 [Page 13]
Internet-Draft LLN Routing Fundamentals April 2009
o The logical equivalent of the full Route Dissemination
information.
o A 'reported' Boolean to keep track whether this prefix was already
reported to the parent's parent.
o A counter of retries to count how many TIOs were sent to the
neighbor without reachability confirmation for the prefix.
Route Dissemination stores the entries in either one of 3 abstract
lists; the Connected, the Reachable and the Unreachable lists. In
practice all are part of a route table.
The Connected list corresponds to the resources owned by the LLN
Router.
As long as a router keeps receiving timely RIOs for a given
information, its entry is listed in the Reachable list.
Once scheduled to be destroyed, an entry is moved to the Unreachable
list if the router has a parent to which it sends RIOs, otherwise the
entry is cleaned up right away. The entry is removed from the
Unreachable list when the parent changes or after a no-RIO has been
sent to the parent indicating the loss of the prefix.
RIO Processing
When ND sends an NA to the parent, Route Dissemination extends the
message with RIO options for:
* All entries that are not deleted.
* All entries in the removed list, using a no-RIO.
* All entries in the advertised list that are 'not reported yet'.
The entries are then set to 'reported'.
If an information is advertised as a no-RIO, the associated route
is removed, and the entry is transferred to the removed list.
Otherwise, the proper routing table is looked up:
* If a preferred route to that source from another protocol
already exists, the RIO is ignored.
* If a new route can be created, a new entry is allocated to
track it, as CONFIRMED, but not reported.
Thubert, et al. Expires October 11, 2009 [Page 14]
Internet-Draft LLN Routing Fundamentals April 2009
* If a Route Dissemination route existed already via the same
Neighbor, it is CONFIRMED.
* If an older unicast route existed via a different Neighbor,
this is equivalent to a no-RIO for the previous entry followed
by a new RIO for the new entry. So the old entry is scheduled
to be destroyed, whereas the new one is installed.
Unicast Route Dissemination messages from child to parent
When sending Route Dissemination to its parent, a router includes
the RIOs about not already reported entries in the Reachable and
Connected lists, as well as no-RIOs for all the entries in the
Unreachable list.
The TIO from the root is used to synchronize the whole tree. Its
period is expected to range from 500ms to hours, depending on the
stability of the configuration and the bandwidth available.
The design choice behind this is NOT TO synchronize the parent and
children databases, but instead to update them regularly to cover
from the loss of packets. The rationale for that choice is
network dynamicity. If the topology can be expected to change
frequently, synchronization might be an excessive goal in terms of
exchanges and protocol complexity. This results in a simple
protocol with no real peering.
4. Forwarding
The fundamental mechanisms described in this draft build a DAG to
enable communication from the LLN Router nodes to the LLN Border
Routers (upstream); a second mechanism informs LLN Routers about
their children in the tree, hence enabling LLN Boarder Router to LLN
Router communication (downstream) and node-to-node routing along the
tree. While the previous sections focus on how routing information
is disseminated throughout the LLN and used for routing, this section
focuses on the forwarding policies used by LLN Routers.
Reliability is increased by allowing a node to try several potential
next-hop nodes in upstream traffic; downstream traffic is sent along
the tree formed by route dissemination.
4.1. Upstream Forwarding
Forwarding in a LLN needs to account for requirements that are
unusual in the IP world:
Thubert, et al. Expires October 11, 2009 [Page 15]
Internet-Draft LLN Routing Fundamentals April 2009
perfect loop freedom is a non-goal
the specification allows for the 'wheel model' where a packet
circulates a bit around the destination till it finally makes it.
transient forwarding failure are commonplace
This specification introduces the capability for the layer 2 to
give a packet back to layer 3 in order to try another adjacency.
Using the LLN Tree Discovery procedure, LLN Routers expose their path
metrics using the Uniform Path Metric field in the TIO. Neighbor LLN
Routers with a lesser depth in the tree then self are forwarding
parents. Neighbor LLN Routers with a same depth in the tree are
siblings. Forwarding via parents ensures a loop free operation
whereas forwarding via siblings may not be loopfree unless additional
measures are taken.
The approach taken in this specification is to favor forwarding via
parents but still enable forwarding via siblings as a backup option.
Preferring the parents enables a forwarding gradient towards the LBR
that limits the chances of multiple consecutive hops over siblings.
This specification also prevents from returning a packet back to the
neighbor that just passed it. This simple rule coupled with the
forwarding gradient protect against loops for a vast majority of
cases, and the specification relies on a appropriate setting of the
TTL in a given deployment to protect against meltdowns.
In more details:
o A LLN router MUST send upstream data to its forwarding parent with
smallest metric. Note that, depending on the way the routing
protocol determines this metric, and the dynamics of the tree, the
best forwarding parent at a given point of time is not necessarily
the parent with the smallest depth or the parent in the logical
tree defined by the Tree Discovery procedure.
o If the transmission of an upstream packet to that preferred parent
fails (due to a node or link failure, or mobility), the LLN router
MAY attempt to forward the packet again via other parents, as
ordered by best metric.
o If the transmission to both primary and secondary forwarding
parents fails, the LLN Router MAY forward the packet via siblings,
as ordered by best metric.
o When the transmission fails and the packet is retried via a
different neighbor, the router MUST decrease the TTL by one.
Thubert, et al. Expires October 11, 2009 [Page 16]
Internet-Draft LLN Routing Fundamentals April 2009
In order to enable these rules, a LLN router maintains a blacklist
per packet being forwarded that contains:
o the neighbor that forwarded the packet to self
o neighbors to which forwarding of this packet failed
These rules are illustrated in the following figure which represents
a subset of an LLN.
D,1,3 B,1,7
| /
| /
| /
C,2,9--- A,2,8
An LLN Router is identified by <Id,Depth,Metric>. LLN Router A has
three neighbors B,C,D. D is A's primary forwarding parent as it is
the neighbor with the smallest Metric amoung neighbors with smaller
depth. If transmission to D fails, A sends the packet to B, which is
of smaller depth. If transmission to B fails, A transmits to C.
Because C is at the same depth as A, a blacklisting policy is used to
avoid that C retransmits to A.
4.2. Downstream Forwarding
Downstream routing using LLN fundamental mechanisms can occur using
either hop-by-hop state, source routing or a combination thereof
(loose source route). By default, the LLN Route Dissemination
mechanism builds up hop-by-hop distance-vector routing information in
each of the routers along the tree up to the root for each address,
prefix or group ID.
Source routing can optionally be supported by either requesting a
route record header from a node, or by having nodes send periodic
route record headers up to the root. If a Route Dissemination route
exists to the first entry in the Record Route header via the source
of the packet, then the router can override the source of the packet
with its address without adding the original source to the Record
Route. At that point, the routing header operation becomes loose, in
other words an hybrid between transparent hop-by-hop (stateful) and
source routing.
Therefore three different downstream techniques are supported:
o Hop-by-hop forwarding. When only partial route dissemination data
reaches a LLN Border Router, it only knows the next-hop to a given
Thubert, et al. Expires October 11, 2009 [Page 17]
Internet-Draft LLN Routing Fundamentals April 2009
LLN Router in the network. In this case, each LLN Router relaying
downstream data will select the next-hop according to the
information it receives during route dissemination.
o Full source routing. When all the route dissemination data
reaches a LLN Border Router, it one can choose to specify the full
list of LLN Routers to be traversed in each downstream data
packet.
o Loose source routing. When the source route information is
compressed because of existing state in the routers along the
path.
5. Multicast Support
5.1. Overview
Wherever we mention <MLD>, one can read MLDv2,3 for IPv6. Doing IGMP
over the LLN involves:
o LLN Border Router acting as a local Rendez-vous Point (RP) for the
LLN and as source towards the Internet for all multicast flows
started in the LLN.
o transporting <MLD> in Route Dissemination and recursive
coalescence of the multicast requests.
5.2. Receiver Flow
The LBR is considered as a Rendezvous Point (RP) for all multicast
flows issued from inside the LLN. Multicast packets are passed up
the tree to the LBR.
Nodes talk <MLD> to their parent router. The parent router forward
the registration and inject their own as a special type of RIO for
multicast groups, towards the LBR. The LBR MAY participate to
multicast in the infrastructure it is connected to and forward all
the packets coming from the LLN.
Between the parent router and the LBR, <MLD> requests are transported
in the RIO; each hop aggregates the requests in a fashion that is
similar to proxy IGMP, but this happens recursively between child
node to parent router up to the LBR. On the way, multicast routing
states are installed in each router from the receiver to the root,
enabling multicast routing down the LLN tree.
Thubert, et al. Expires October 11, 2009 [Page 18]
Internet-Draft LLN Routing Fundamentals April 2009
5.3. Source flow
As a Node, the source is unaware of the ROLL protocol, and it uses
standard protocols with the router (say in IPv6: Neighbor Discovery,
<MLD> etc...). So when it has a multicast packet to send, the source
just forwards it to its default router, which is the expected
standard behavior. Routers on the way recursively forward to their
parent. At each hop, if a multicast route indicates that a listener
is reachable via another child (different from that through which the
packet was received) then the packet is duplicated and forwarded to
that child down the tree.
If the LLN Border Router is configured to do so, it will source the
packet to a real RP in the Internet.
6. Advanced Features
The fundamental mechanisms described in this document are sufficient
to allow for upstream and downstream communication inside the LLN.
They form a common basis upon which future LLN routing protocols can
be designed. This section indicates some possible advanced features
which can be integrated to increase efficiency for a particular usage
scenarios.
6.1. Interaction with other routing protocols
While network design and specific use cases are out of scope for this
document, it must be noted that the LLN fundamental mechanisms
described herein might be used in conjunction with other routing
protocols in order to fulfill the requirements of a particular
deployment. Here follows a non exhaustive series of examples
illustrating such interactions.
6.1.1. AODV/DYMO
In the example of a closed loop between a sensor and a switch, a
constrained optimized route must be installed between the 2 devices.
Defining such a specific route is costly and should be performed on-
demand when the bulk of the traffic is buffered data from source to
sink.
A reactive MANET protocol such as AODV [RFC3561], DSR [RFC4728] or
DYMO [I-D.ietf-manet-dymo] can be deployed to enable such routing,
though the QoS-constrained approach for AODV is stalled as a draft
([I-D.perkins-manet-aodvqos]).
Thubert, et al. Expires October 11, 2009 [Page 19]
Internet-Draft LLN Routing Fundamentals April 2009
6.1.2. OSPF/OLSR
A federating backbone is the virtual root of a collection of trees
that forms a single routing topology. If that topology shares a same
prefix, a sensor device can move freely within the topology without
renumbering. The 6LoWPAN backbone link is an example of such a
federating backbone and in that case, the protocol that enables any
to any reachability is simply IPv6 Neighbor Discovery [RFC4861].
In a generalized case with routing and multiple subnets, a
traditional IGP such as OSPF [RFC2740] or a MANET protocol such as
OLSR [RFC3626] can be deployed within the federating backbone between
the LBR to advertise the routes learnt from the LLN fundamentals
dissemination protocol through the redistribution of route
information.
In turn, the routed federating backbone is just the instantiation at
Depth 0 of the more general concept of beltlines. A beltline is a
set of routers of a same depth in a same tree that form a subarea
where an IGP is run and route information from the LLN Route
Dissemination protocol is redistributed. This creates routes around
the root and reduces the load that routing along the tree imposes on
the lower depth of the tree.
Note that in turn, beltline routes ARE NOT redistributed into LLN
Route Dissemination information. As a result, the beltlines routes
are orthogonal to the route dissemination routes, and they should
never collide, which optimizes the value of the control plane of the
combination.
Beltline routes should be used with caution in order to maintain
stability and optimize the resulting routes:
o beltline routes should only be used when a certain topological
stability was asserted
o using beltline routes discourages the reorganization of the tree,
mostly when that causes a router to change its depth
o a divide and conquer approach to limit the size of a beltline
enables to manage the cost of the control plane
o a beltline of depth 2 or more should be an arc as opposed to full
circle.In the example of a closed loop between a sensor and a
switch, a constrained optimized route must be installed between
the 2 devices.
Thubert, et al. Expires October 11, 2009 [Page 20]
Internet-Draft LLN Routing Fundamentals April 2009
6.1.3. MIP6/NEMO
MIP6 [RFC3775] and NEMO [RFC3963] enable a subtree to move away from
the tree and maintain reachability as if the nodes in the subtree
were still located in their topologically correct position. This can
be useful when a RIO aggregation is performed (see Section 6.6) to
enable reachability of a stray device. MIP6 be also be useful to
enable a mobile display device such as a PDA to keep accessing a
sensor network remotely without injecting the sensor network prefix
into the infrastructure for security reasons.
6.2. Route Optimization
Whereas upstream and downstream communication is made possible by the
fundamental mechanisms described in this document, applications may
require more require traffic engineering, which may include:
6.2.1. Node-to-node routing
Node-to-node routing is ensured along the tree by the Route
Dissemination protocol, and the packets flow via the first common
parent. This can be optimized if the LLN Border Router has a clear
view of the topology (see 'Offline Path Computation' section). In
this case, the LLN Border Router can indicate the direct path between
both LLN Routers, calculated offline, to the source, the destination,
or both. This technique induces a trade-off between multi-hop route
efficiency and signaling overhead to setup this direct node-to-node
path for instance as suggested in Section 6.1.1.
6.2.2. Offline Path Computation
Whereas nodes might not have the capacity to store and manage enough
information to perform constrained routing, it is possible for nodes
to report their neighborhood information to the LLN Border routers.
LLN Border routers can then share their partial topology databases
and get a full picture of the network.
From there, it is possible to get LLN Border routers to compute
shorter or constrained paths and either distribute them (e.g. LDP)
or pass the source route information to the end nodes.
An OSPF example of that goes like this. Nodes run HELLO or similar,
and send their LSA in unicast to their LLN Border routers. The LLN
Border routers act as proxy for the nodes and share those LSAs with
other LLN Border routers over the backbone. At some point they
converge and an LLN Border router will run SPF on behalf of all its
registered nodes, one at a time. The SPF computation should end at a
certain distance from the node for which it makes more sense to go
Thubert, et al. Expires October 11, 2009 [Page 21]
Internet-Draft LLN Routing Fundamentals April 2009
through the backbone anyway. Then the LLN Border router sends the
set of routes to the node as an new topology that can be used in a
MTR fashion.
6.2.3. Graph forwarding
Distance Vector and Link State routing protocols are traditionally
designed in terms of:
Links -> Metrics -> Routes -> network runtime
Unless traffic engineering kicks in, either the routes are
established over the shortest path and the alternate links are wasted
or the traffic is load balanced in a fashion that represents the
ratio of costs as opposed to the ratio of capacity of the paths.
Also, the runtime of the network is opaque to the forwarding plane,
so the only way to guarantee some end-to-end bandwidth for a class of
traffic is to blindly reserve it, leading to even more waste of
bandwidth when the reservation is not fully utilized.
In order to optimize the network utilization, it would be beneficial
to detect the saturation of the shortest path and load balance the
extra traffic over alternate routes. In the case of ROLL, it is also
critical to be able to make a reroute decision on a per packet basis
when hop by hop retries are exhausted. Arpanet introduced a feedback
loop into the routing protocol by making the metrics dynamic:
Links -> Metrics -> Routes -> network runtime
^ |
|__________________________________|
But this approach was unsuccessful, causing instabilities and
disrupting the network. With dynamic metrics, the duration of the
convergence time - or frozen time -,increases with the number of
links and the frequency of the metric updates. During that time, the
response of the network is undefined and temporary loops occur.
An approach to solve this problem is having 2 independent sets of
metrics: on the one hand, the topological metrics that are rather
static and mostly administratively set; and on the other hand, the
volatile metrics that are based on dynamic measurements of the
network characteristics.
The topological metrics are used by the LLN routing protocol to
initially build the tree as described in this specification. The
Thubert, et al. Expires October 11, 2009 [Page 22]
Internet-Draft LLN Routing Fundamentals April 2009
volatile metrics are then used by a forwarding protocol to balance
the traffic for that destination over the upstream links, thus
modifying the way the graph is being used in runtime, without
changing its structure.
To get there, the control plane operates in 2 phases, in a lollipop
fashion:
Links->Metrics->Routes->netw. runtime->runtime metrics->forwarding
^ |
|________________________________|
<--------------------------> <----------------------------------->
ROLL routing protocol ROLL forwarding protocol
The LLN fundamentals proposal builds shortest path trees to the exits
but adds the capability to forward over another branch if sending a
packet to a parent fails, either via any alternate parent or a
sibbling. So the paths that we really want to monitor are along the
tree itself and one hop away from the tree. To get there, the root
emits a beacon that is multicasted down the tree and heard one hop
away. That beacon gathers the metrics that will be used for
alternate parents and sibblings selection and nodes keep track of the
beacon they hear for all the parents and sibblings they want to
track. From the beacon, they can infer the quality of the path
through all the alternates and compare them.
6.3. Density
In a dense environment, it is useless that all routers that can
provide backhauling service actually do so; in practice, limiting the
number of routers that accept attached nodes saves memory in the
attached nodes and reduces the cost of signalling. Also, limiting
the number of forwarding LLN Routers in the tree improves the
multicast operations.
Algorithms such a Trickle could be used by a LLN Router to decide to
stop providing its access services for attached nodes if there are a
number of neighboring routers that provide similar services. The
simplest abstraction of such similarity is that a multiple routers
advertising a same depth, though such a simple similarity does not
address the specifics of a router selection in the plugins. In a
more general fashion, a LLN Router can associate the concept of
similarity with the characteristics of its own parent router
selection plug in.
Thubert, et al. Expires October 11, 2009 [Page 23]
Internet-Draft LLN Routing Fundamentals April 2009
6.4. Digraph Dissemination
The fundamental techniques described in this draft overlay a tree for
source/sink traffic over the physical topology. This tree could be
converted into a (bi)graph with additional overhead. A LLN Router
would therefore send route dissemination data to both its primary and
secondary forwarding parents, hence informing an LLN Border Router of
disjoint paths. This makes sense in applications where the gains in
increase downstream reliability outweigh the additional signaling
overhead.
6.5. Multiple LBRs and Trees
The LLN Tree Discovery technique propagates increasing depths and
metrics throughout the network; upstream messages travel on a
decreasing metric path back to the LLN Border Router. When the LLN
features multiple LBRs, the following options appear:
o If the different LBRs share the same TreeID, an LLN Router
implicitly sends its upstream data to the LBR which is closest in
terms of aggregated metric. This should be used whenever LBRs
play the same role.
o Different LBRs may choose to use different TreeIDs. In this case,
a LLN Router is part of multiple trees, one for eachTreeID. When
sending an upstream message, a LLN Router chooses on which TreeID
it wishes to send, i.e. to which LBR.
o A hybrid case can exist in which some LBRs share the same TreeID
while others have their dedicated Tree ID.
An alternative when having multiple LBRs is to construct multiple
trees (e.g. one for each LBR) and choose a default tree for
forwarding data. Using an alternate tree is possible only when
labeling the data packet accordingly; an unlabeled packet is
forwarded on the default tree.
6.6. Aggregation for Route Dissemination
Aggregation of prefixes on a same router
When deploying a router with multiple interfaces, it makes sense
to assign an aggregation prefix (shorter than /64) to the router
and partition it as /64 prefixes over the router interfaces. A
router that owns a contiguous set of prefixes should only report
the aggregation of these prefixes through Route Dissemination.
Thubert, et al. Expires October 11, 2009 [Page 24]
Internet-Draft LLN Routing Fundamentals April 2009
Aggregation of prefixes by a parent acting as ROLL Home
There are also a number of cases where a ROLL aggregation is
shared within a platoon of LLN Routers. In that case, it is still
possible to use aggregation techniques with Route Dissemination
and improve its scalability. In that case, the parent is
configured as the Route Dissemination aggregator for the group
prefix. At run time, it absorbs the individual RIO information it
receives from the platoon members down its subtree and only
reports the aggregation up the TD tree. This works fine when the
whole platoon is attached within the parent's subtree.
But other cases might occur for which additional support is
required:
1. the aggregator is attached within the subtree of one of its
platoon members.
2. a platoon member is somewhere else within the TD tree.
3. a platoon member is somewhere else in the Internet.
In all those cases, a node situated above the aggregator in the TD
tree but not above the platoon member will see the advertisements
for the aggregation owned by the aggregator but not that of the
individual platoon member prefix. So it will route all the
packets for the platoon member towards the aggregator, but the
aggregator will have no route to the platoon and will fail to
forward.
6.7. Advanced Forwarding
A blacklisting policy can be used to avoid routing loops when an
upstream data packet is sent between neighbor LLN Routers of the same
depth. Alternatively, more general techniques can be used to avoid
loops. One is to record the sequence of already traversed nodes in
the data packet as it travels along a multi-hop path. When receiving
a packet, a LLN Router may know whether it has already relayed that
packet; if yes, it can know from which neighbors it had received it
and to which it had sent. A distributed version of depth first
search can then be used to avoid routing loops. This extension
enables upstream packets to be sent to neighbors with a larger depth.
7. Security Considerations
As this draft suggests the use of new options carried in ICMP ND
messages; the same security considerations as in [RFC4861] apply, in
Thubert, et al. Expires October 11, 2009 [Page 25]
Internet-Draft LLN Routing Fundamentals April 2009
particular with regards to the use of Secure ND [RFC3971] to protect
against address theft. Additionally link-layer security should be
applied in the case of 6LoWPAN where SeND is not typically possible.
8. IANA Considerations
This draft would require two new ICMP options for use with ND: the
Tree Information Option (TIO) and the Route Information Option (RIO).
9. Acknowledgments
The authors would like to thank Richard Kelsey, Robert Assimiti, Kris
Pister, Mischa Dohler, Julien Abeille, Ryuji Wakikawa, Teco Boot,
Patrick Wetterwald, Bryan Mclaughlin and Carlos J. Bernardos for
useful design considerations and reviews.
10. References
10.1. Normative References
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4
Networks", RFC 4944, September 2007.
10.2. Informative References
[I-D.ietf-manet-dymo]
Chakeres, I. and C. Perkins, "Dynamic MANET On-demand
(DYMO) Routing", draft-ietf-manet-dymo-17 (work in
progress), March 2009.
[I-D.ietf-roll-building-routing-reqs]
Martocci, J., Riou, N., Mil, P., and W. Vermeylen,
"Building Automation Routing Requirements in Low Power and
Lossy Networks", draft-ietf-roll-building-routing-reqs-05
(work in progress), February 2009.
[I-D.ietf-roll-home-routing-reqs]
Porcu, G., "Home Automation Routing Requirements in Low
Power and Lossy Networks",
draft-ietf-roll-home-routing-reqs-06 (work in progress),
November 2008.
Thubert, et al. Expires October 11, 2009 [Page 26]
Internet-Draft LLN Routing Fundamentals April 2009
[I-D.ietf-roll-indus-routing-reqs]
Networks, D., Thubert, P., Dwars, S., and T. Phinney,
"Industrial Routing Requirements in Low Power and Lossy
Networks", draft-ietf-roll-indus-routing-reqs-04 (work in
progress), January 2009.
[I-D.ietf-roll-terminology]
Vasseur, J., "Terminology in Low power And Lossy
Networks", draft-ietf-roll-terminology-00 (work in
progress), October 2008.
[I-D.ietf-roll-urban-routing-reqs]
Dohler, M., Watteyne, T., Winter, T., Barthel, D.,
Jacquenet, C., Madhusudan, G., and G. Chegaray, "Urban
WSNs Routing Requirements in Low Power and Lossy
Networks", draft-ietf-roll-urban-routing-reqs-05 (work in
progress), March 2009.
[I-D.perkins-manet-aodvqos]
Perkins, C. and E. Belding-Royer, "Quality of Service for
Ad hoc On-Demand Distance Vector Routing",
draft-perkins-manet-aodvqos-01 (work in progress),
November 2001.
[RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6",
RFC 2740, December 1999.
[RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On-
Demand Distance Vector (AODV) Routing", RFC 3561,
July 2003.
[RFC3626] Clausen, T. and P. Jacquet, "Optimized Link State Routing
Protocol (OLSR)", RFC 3626, October 2003.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
Thubert, "Network Mobility (NEMO) Basic Support Protocol",
RFC 3963, January 2005.
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC4728] Johnson, D., Hu, Y., and D. Maltz, "The Dynamic Source
Routing Protocol (DSR) for Mobile Ad Hoc Networks for
IPv4", RFC 4728, February 2007.
Thubert, et al. Expires October 11, 2009 [Page 27]
Internet-Draft LLN Routing Fundamentals April 2009
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
Authors' Addresses
Pascal Thubert
Cisco Systems
Village d'Entreprises Green Side
400, Avenue de Roumanille
Batiment T3
Biot - Sophia Antipolis 06410
FRANCE
Phone: +33 4 97 23 26 34
Email: pthubert@cisco.com
Thomas Watteyne
UC Berkeley
497 Cory Hall #1774
Berkeley Sensor & Actuator Center
Berkeley, California 94720-1774
USA
Phone: +1 (510) 333-4437
Email: watteyne@eecs.berkeley.edu
Zach Shelby
Sensinode
Kidekuja 2
Vuokatti 88600
FINLAND
Phone: +358407796297
Email: zach@sensinode.com
Thubert, et al. Expires October 11, 2009 [Page 28]
Internet-Draft LLN Routing Fundamentals April 2009
Dominique Barthel
Orange Labs
28 chemin du Vieux Chene, BP98
BP98
Meylan 38243
FRANCE
Phone: +33476764522
Email: dominique.barthel@orange-ftgroup.com
Thubert, et al. Expires October 11, 2009 [Page 29]