One document matched: draft-thubert-roll-fundamentals-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2460 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2460.xml">
<!ENTITY RFC2740 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2740.xml">
<!ENTITY RFC3626 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3626.xml">
<!ENTITY RFC3561 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3561.xml">
<!ENTITY RFC3775 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3775.xml">
<!ENTITY RFC3963 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3963.xml">
<!ENTITY RFC3971 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3971.xml">
<!ENTITY RFC4728 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4728.xml">
<!ENTITY RFC4861 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4861.xml">
<!ENTITY RFC4944 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4944.xml">
<!ENTITY I-D.ietf-roll-terminology SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-roll-terminology.xml">
<!ENTITY I-D.ietf-manet-dymo SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-manet-dymo.xml">
<!ENTITY I-D.perkins-manet-aodvqos SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.perkins-manet-aodvqos.xml">
<!ENTITY I-D.ietf-roll-indus-routing-reqs SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-roll-indus-routing-reqs.xml">
<!ENTITY I-D.ietf-roll-home-routing-reqs SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-roll-home-routing-reqs.xml">
<!ENTITY I-D.ietf-roll-urban-routing-reqs SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-roll-urban-routing-reqs.xml">
<!ENTITY I-D.ietf-roll-building-routing-reqs SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-roll-building-routing-reqs.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="3"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" ipr="trust200811" docName="draft-thubert-roll-fundamentals-01">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<front>
<title>LLN Routing Fundamentals</title>
<author initials="P" surname="Thubert" fullname="Pascal Thubert">
<organization abbrev="Cisco">
Cisco Systems
</organization>
<address>
<postal>
<street>Village d'Entreprises Green Side</street>
<street>400, Avenue de Roumanille</street>
<street>Batiment T3</street>
<city>Biot - Sophia Antipolis</city>
<code>06410</code>
<country>FRANCE</country>
</postal>
<phone>+33 4 97 23 26 34</phone>
<email>pthubert@cisco.com</email>
</address>
</author>
<author initials="T" surname="Watteyne" fullname="Thomas Watteyne">
<organization>
UC Berkeley
</organization>
<address>
<postal>
<street>497 Cory Hall #1774</street>
<street>Berkeley Sensor & Actuator Center</street>
<city>Berkeley, California</city>
<code>94720-1774</code>
<country>USA</country>
</postal>
<phone>+1 (510) 333-4437</phone>
<email>watteyne@eecs.berkeley.edu</email>
</address>
</author>
<author initials="Z" surname="Shelby" fullname="Zach Shelby">
<organization>
Sensinode
</organization>
<address>
<postal>
<street>Kidekuja 2</street>
<city>Vuokatti</city>
<code>88600</code>
<country>FINLAND</country>
</postal>
<phone>+358407796297</phone>
<email>zach@sensinode.com</email>
</address>
</author>
<author initials="D" surname="Barthel" fullname="Dominique Barthel">
<organization>
Orange Labs
</organization>
<address>
<postal>
<street>28 chemin du Vieux Chene, BP98</street>
<street>BP98</street>
<city>Meylan</city>
<code>38243</code>
<country>FRANCE</country>
</postal>
<phone>+33476764522</phone>
<email>dominique.barthel@orange-ftgroup.com</email>
</address>
</author>
<date year="2009"/>
<area>Routing</area>
<workgroup>ROLL Working Group</workgroup>
<abstract>
<t>
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.
</t>
</abstract>
</front>
<middle>
<!-- ################################################################## -->
<section anchor='intro' title="Introduction">
<t>
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.
</t>
<t>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:
<list style="symbols">
<t><xref target="I-D.ietf-roll-urban-routing-reqs">Urban WSNs Routing Requirements in Low Power and Lossy Networks</xref></t>
<t><xref target="I-D.ietf-roll-building-routing-reqs">Building Automation Routing Requirements in Low Power and Lossy Networks</xref></t>
<t><xref target="I-D.ietf-roll-home-routing-reqs">Home Automation Routing Requirements in Low Power and Lossy Networks</xref></t>
<t><xref target="I-D.ietf-roll-indus-routing-reqs">Industrial Routing Requirements in Low Power and Lossy Networks</xref></t>
</list>
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.
</t>
<t>
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.
</t>
<t>
In terms of routing, the basic fundamental methods include uni/anycast routing up the graph and unicast routing down the tree (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.
</t>
<t>
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.
</t>
<t>
This document is organized as follows:
<list style="hanging">
<t>Section 1.1 defines the terminology used in this document.</t>
<t>Section 2 concentrates on the basic tree discovery and maintenance mechanism.</t>
<t>Section 3 introduces the basic distance-vector route dissemination mechanism.</t>
<t>Section 4 describes the upstream and downstream forwarding rules.</t>
<t>Section 5 describes multicast support.</t>
<t>Section 6 describes advanced mechanisms which can be built upon these fundamentals.</t>
</list>
</t>
<section anchor='intro_terminology' title="Terminology">
<t>The terminology used in this document is consistent with and incorporates that described in <xref target="I-D.ietf-roll-terminology"/>. This terminology is extended in this document as follows:
<list style="hanging">
<t hangText="to Attach:">the action of establishing a child-to-parent relationship in Tree Discovery.</t>
<t hangText="Tree Depth:">the maximum number of edges that need to be traversed from any tree node to the root.</t>
<t hangText="Discovery:">a mechanism by which a logical representation of the network is built.</t>
<t hangText="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.</t>
<t hangText="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.</t>
<t hangText="Uniform Path Metric:">A scalar measure for the quality of the bi-directional path between the LLN Router and the root.</t>
<t hangText="Route Dissemination:">the action of establishing state within the network so that routers know how to forward packets related to some source-destination pairs.</t>
<t hangText="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.</t>
<t hangText="Default Router:">the router to turn to when a node has no information on where to forward a packet.</t>
</list>
</t>
</section>
<section anchor='needs' title="Needs">
<t>
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:
<list style="symbols">
<t>Support for operation in both full IPv6 <xref target="RFC2460"/> and minimal 6LoWPAN <xref target="RFC4944"/> networks.</t>
<t>Optimized for traffic directed between nodes and LBRs.</t>
<t>The discovery of multiple disjoint routing paths to increase reliability.</t>
<t>Support for multiple LBRs out of the LLN.</t>
<t>Minimal network state needed by routers, with a hard bound better than O(D), D being the number of destinations.</t>
<t>Support for complex unicast, anycast and multicast flows.</t>
<t>Localized response upon link failures without requiring global updates.</t>
<t>Minimal control overhead scaling within O(log(L)) of the data rate.</t>
<t>Support for link and node costs along routes.</t>
</list>
</t>
</section>
</section>
<!-- ################################################################## -->
<section anchor='disco' title="Tree Discovery">
<t>
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.
</t>
<t>
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.
</t>
<t> 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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
This section describes
<list style='numbers'>
<t>a minimum extension to IPv6 Neighbor
Discovery Router Advertisements in order to ensure that LLN
Routers organize in a tree structure, and</t>
<t>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.</t>
</list>
</t>
<t>
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 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.
</t>
<t>
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.
</t>
<section anchor='disco_overview' title="Overview">
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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:
<list style="numbers">
<t>
The root of a tree exposes the tree in the Router
Advertisement (RA) Tree Information Option (TIO) and LLN Routers
propagate the TIO down.
</t>
<t>
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.
</t>
<t>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 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.
</t>
<t>
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.
</t>
<t>
A router sending an RA without TIO is considered a Grounded Default Router at depth 0.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
</list>
</t>
</section>
<section anchor='disco_treeinfo' title="Discovery Information">
<t>
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.
<list style="hanging">
<t hangText="TIO Base option"></t>
<t>
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.
<list style="hanging">
<t hangText="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.</t>
<t hangText="Grounded (G):">The Grounded (G) flag is set when the tree is
attached to a fixed network infrastructure (such as the Internet).</t>
<t hangText="Sequence Number:">An integer that is
incremented by the root for each TIO sent on a link. It is propagated unchanged down the tree.</t>
<t hangText="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.</t>
<t hangText="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.</t>
<t hangText=" Uniform Path Metric:">A scalar measure for the quality of the bi-directional path between the LLN Router and the root.</t>
</list>
</t>
<t>
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.
</t>
<t>
In addition to the minimum set of information required, a
number of options can are used, e.g. for bandwidth,
stability, preference etc.
</t>
</list>
</t>
</section>
<section anchor='disco_stability' title="Stability">
<t>
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.
</t>
<t>
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.
</t>
</section>
</section>
<!-- ################################################################## -->
<section anchor='dissemination' title="Route Dissemination">
<section anchor='dissemination_overview' title="Overview">
<t>
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.
</t>
<t>
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).
</t>
<t>
LLN Tree Discovery does not only provide loop avoidance for the Route 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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
</section>
<section anchor='dissemination_ninooption' title="Disseminated Information">
<t>
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).
</t>
<t>
In order to track the freshness of an advertisement, the
RIO includes a sequence counter that is incremented each time the
advertisement is reissued.
</t>
<t>
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.
</t>
<t>
Route Dissemination may advertise positive (prefix is present) or negative (removed) RIOs.
</t>
<t>
The RIO base option carries sequenced route information for unicast and multicast;
it contains:
<list style="hanging">
<t hangText="Resource type:">Prefix, host, or multicast group</t>
<t hangText="Prefix Length:">Number of valid leading bits in the IPv6 Prefix.</t>
<t hangText="RIO Lifetime:"> The length of time in seconds (relative
to the time the packet is sent) that the prefix is valid for route
determination. </t>
<t hangText="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.</t>
<t hangText="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.
</t>
<t hangText="Prefix:">Variable-length field containing a prefix, an IPv6 address or a multicast
group id.</t>
</list>
</t>
</section>
<section anchor='dissemination_ROLLrouteroperation' title="LLN Router Operation">
<t>
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 <xref target="adv_igps"/> for more discussion on integration with other routing
protocols.
</t>
<t>
As a result:
</t>
<t>
<list style="symbols">
<t>
LLN Tree Discovery establishes a tree using extended Neighbor
Discovery RS/RA flows.
</t>
<t>
A routing algorithm exploits the tree to optimally move upstream traffic
out of the LLN (default route).
</t>
<t>
Route Dissemination extends Neighbor Discovery in order
to quickly establish hop-by-hop routes down the tree.
</t>
<t>
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.
</t>
</list>
</t>
<t>
Route Dissemination maintains abstract lists of known information. An entry
contains the following abstract information:
<list style="symbols">
<t>A reference to the adjacency that was created for that prefix.</t>
<t>The IPv6 address of the advertising Neighbor.</t>
<t>The logical equivalent of the full Route Dissemination information.</t>
<t>A 'reported' Boolean to keep track whether this prefix was already reported to the parent's parent.</t>
<t>A counter of retries to count how many TIOs were sent to the neighbor without reachability confirmation for the prefix.</t>
</list>
</t>
<t>
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.
</t>
<t>
The Connected list corresponds to the resources owned by the LLN Router.
</t>
<t>
As long as a router keeps receiving timely RIOs for a given information, its entry is listed in the Reachable list.
</t>
<t>
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.
</t>
<t>
<list style="hanging">
<t hangText="RIO Processing"></t>
<t>
When ND sends an NA to the parent, Route Dissemination extends the message with RIO options for:
<list style="symbols">
<t>All entries that are not deleted.</t>
<t>All entries in the removed list, using a no-RIO.</t>
<t>All entries in the advertised list that are 'not reported yet'. The entries are then set to 'reported'.</t>
</list>
</t>
<t>
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:
<list style="symbols">
<t>
If a preferred route to that source from another protocol already
exists, the RIO is ignored.
</t>
<t>
If a new route can be created, a new entry is allocated to
track it, as CONFIRMED, but not reported.
</t>
<t>
If a Route Dissemination route existed already via the same Neighbor, it is
CONFIRMED.
</t>
<t>
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.
</t>
</list>
</t>
<t hangText="Unicast Route Dissemination messages from child to parent"></t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
</list>
</t>
</section>
</section>
<!-- ################################################################## -->
<section anchor='forwarding' title="Forwarding">
<t>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.</t>
<t>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.</t>
<section anchor='forwarding_in' title="Upstream Forwarding">
<t> Forwarding in a LLN needs to account for requirements that are unusual in the IP world:
<list style="hanging">
<t hangText="perfect loop freedom is a non-goal"></t>
<t>the specification allows for the 'wheel model' where a packet circulates a bit around the destination till it finally makes it.</t>
<t hangText="transient forwarding failure are commonplace"></t>
<t> This specification introduces the capability for the layer 2 to give a packet back to layer 3 in order to try another adjacency.</t>
</list>
</t>
<t>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.
</t>
<t>
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.
</t>
<t>In more details: <list style="symbols">
<t>
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.</t>
<t>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.</t>
<t>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.</t>
<t>When the transmission fails and the packet is retried via a different neighbor, the router MUST decrease the TTL by one.</t>
</list>
</t>
<t>In order to enable these rules, a LLN router maintains a blacklist per packet being forwarded that contains:
<list style="symbols">
<t>the neighbor that forwarded the packet to self
</t>
<t>neighbors to which forwarding of this packet failed
</t>
</list>
</t>
<t>These rules are illustrated in the following figure which represents a subset of an LLN.</t>
<t>
<figure>
<artwork>
D,1,3 B,1,7
| /
| /
| /
C,2,9--- A,2,8
</artwork>
</figure>
</t>
<t>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.</t>
</section>
<section anchor='forwarding_out' title="Downstream Forwarding">
<t>
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.
</t>
<t>
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.
</t>
<t>Therefore three different downstream techniques are supported:
<list style="symbols">
<t>Hop-by-hop forwarding. When only partial route dissemination data reaches a LLN Border Router, it only knows the next-hop to a given 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.</t>
<t>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.</t>
<t>Loose source routing. When the source route information is compressed because of existing state in the routers along the path.</t>
</list>
</t>
</section>
</section>
<!-- ################################################################## -->
<section anchor='multicast' title="Multicast Support">
<section anchor='multicast_overview' title="Overview">
<t>Wherever we mention <MLD>, one can read MLDv2,3 for IPv6. Doing IGMP over the LLN involves:
<list style="symbols">
<t>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.</t>
<t>transporting <MLD> in Route Dissemination and recursive coalescence of the multicast requests.</t>
</list>
</t>
</section>
<section anchor='multicast_rxflow' title="Receiver Flow">
<t>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.</t>
<t>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.</t>
<t>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.</t>
</section>
<section anchor='multicast_srcflow' title="Source flow">
<t>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.</t>
<t>If the LLN Border Router is configured to do so, it will source the packet to a real RP in the Internet.</t>
</section>
</section>
<!-- ################################################################## -->
<section anchor='adv' title="Advanced Features">
<t>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.</t>
<section anchor='adv_igps' title="Interaction with other routing protocols">
<t>
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.
</t>
<section anchor='adv_igp_dymo' title="AODV/DYMO">
<t>In the example of a closed loop between a sensor and a switch, a constrained
optimized route must be installed between the 2 devices.
</t>
<t>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.
</t>
<t>A reactive MANET protocol such as <xref target="RFC3561"> AODV </xref>, <xref target="RFC4728"> DSR </xref> or
<xref target="I-D.ietf-manet-dymo"> DYMO </xref> can be deployed to enable
such routing, though the QoS-constrained approach for AODV is stalled as a draft
(<xref target="I-D.perkins-manet-aodvqos"/>).
</t>
</section>
<section anchor='adv_igp_olsr' title="OSPF/OLSR">
<t>
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 <xref target="RFC4861">IPv6 Neighbor Discovery</xref>.
</t>
<t>
In a generalized case with routing and multiple subnets, a traditional IGP such as <xref target="RFC2740"> OSPF </xref> or a
MANET protocol such as <xref target="RFC3626"> OLSR </xref> 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.
</t>
<t>
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.
</t>
<t> 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.
</t>
<t>Beltline routes should be used with caution in order to maintain stability and optimize the resulting routes:
<list style="symbols">
<t>beltline routes should only be used when a certain topological stability was asserted
</t>
<t>using beltline routes discourages the reorganization of the tree, mostly when that causes a router to change its depth
</t>
<t>a divide and conquer approach to limit the size of a beltline enables to manage the cost of the control plane
</t>
<t>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.
</t>
</list>
</t>
</section>
<section anchor='adv_igp_mip6' title="MIP6/NEMO">
<t>
<xref target="RFC3775"> MIP6 </xref> and <xref target="RFC3963"> NEMO </xref> 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 <xref target="adv_aggregation"/>) 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.
</t>
</section>
</section>
<section anchor='adv_opt' title="Route Optimization">
<t>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:
</t>
<section anchor='adv_opt_node' title="Node-to-node routing">
<t>
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 <xref target="adv_igp_dymo"/>.</t>
</section>
<section anchor='adv_opt_offline' title="Offline Path Computation">
<t>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.</t>
<t>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.</t>
<t>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 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.
</t>
</section>
<section anchor='adv_opt_graphforwarding' title="Graph forwarding">
<t>
Distance Vector and Link State routing protocols are traditionally designed in terms of:
</t>
<t>
<figure>
<artwork>
Links -> Metrics -> Routes -> network runtime
</artwork>
</figure>
</t>
<t>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.</t>
<t>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.</t>
<t>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:</t>
<t>
<figure>
<artwork>
Links -> Metrics -> Routes -> network runtime
^ |
|__________________________________|
</artwork>
</figure>
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
The topological metrics are used by the LLN routing protocol
to initially build the tree as described in this specification.
The 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.
</t>
<t>
To get there, the control plane operates in 2 phases, in a lollipop fashion:
</t>
<t>
<figure>
<artwork>
Links->Metrics->Routes->netw. runtime->runtime metrics->forwarding
^ |
|________________________________|
<--------------------------> <----------------------------------->
ROLL routing protocol ROLL forwarding protocol
</artwork>
</figure>
</t>
<t>
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.
</t>
</section>
</section>
<section anchor='density' title="Density">
<t>
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.
</t>
<t>
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.
</t>
</section>
<section anchor='adv_digraph' title="Digraph Dissemination">
<t>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.</t>
</section>
<section anchor='adv_multiple' title="Multiple LBRs and Trees">
<t>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:
<list style="symbols">
<t>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.</t>
<t>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.</t>
<t>A hybrid case can exist in which some LBRs share the same TreeID while others have their dedicated Tree ID.</t>
</list>
</t>
<t>
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.
</t>
</section>
<section anchor='adv_aggregation' title="Aggregation for Route Dissemination">
<t>
<list style="hanging">
<t hangText="Aggregation of prefixes on a same router"></t>
<t>
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.
</t>
<t hangText="Aggregation of prefixes by a parent acting as ROLL Home"></t>
<t>
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.
</t>
<t>
But other cases might occur for which additional support is required:
<list style="numbers">
<t>the aggregator is attached within the subtree of one of its platoon members.</t>
<t>a platoon member is somewhere else within the TD tree.</t>
<t>a platoon member is somewhere else in the Internet.</t>
</list>
</t>
<t>
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.
</t>
</list>
</t>
</section>
<section anchor='adv_advancedfwd' title="Advanced Forwarding">
<t>
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.
</t>
</section>
</section>
<!-- ################################################################## -->
<section anchor='security' title="Security Considerations">
<t>
As this draft suggests the use of new options carried in ICMP ND messages;
the same security considerations as in <xref target="RFC4861"/> apply, in particular with regards to the use of Secure ND <xref target="RFC3971"/> to protect against address theft.
Additionally link-layer security should be applied in the
case of 6LoWPAN where SeND is not typically possible.
</t>
</section>
<!-- ################################################################## -->
<section anchor='iana' title="IANA Considerations">
<t>
This draft would require two new ICMP options for use with ND: the
Tree Information Option (TIO) and the Route Information Option (RIO).
</t>
</section>
<!-- ################################################################## -->
<section anchor='acknowledgments' title="Acknowledgments">
<t>
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.
</t>
</section>
</middle>
<back>
<references title='Normative References'>
&RFC2460;
&RFC4944;
</references>
<references title='Informative References'>
&I-D.ietf-roll-indus-routing-reqs;
&I-D.ietf-roll-home-routing-reqs;
&I-D.ietf-roll-urban-routing-reqs;
&I-D.ietf-roll-building-routing-reqs;
&RFC2740;
&RFC3561;
&RFC3626;
&RFC3775;
&RFC3963;
&RFC3971;
&RFC4728;
&RFC4861;
&I-D.ietf-roll-terminology;
&I-D.ietf-manet-dymo;
&I-D.perkins-manet-aodvqos;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 03:24:16 |