One document matched: draft-thubert-roll-asymlink-02.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc subcompact="no"?>
<?rfc authorship="yes"?>
<?rfc tocappendix="yes"?>
<rfc category="std" docName="draft-thubert-roll-asymlink-02" ipr="trust200902">
<front>
<title abbrev="draft-thubert-roll-asymlink">RPL adaptation for asymmetrical links</title>
<author fullname="Pascal Thubert" initials="P" role="editor"
surname="Thubert">
<organization abbrev="Cisco Systems">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 497 23 26 34</phone>
<email>pthubert@cisco.com</email>
</address>
</author>
<date />
<area>Routing Area</area>
<workgroup>ROLL</workgroup>
<keyword>Draft</keyword>
<abstract>
<t>The Routing Protocol for Low Power and Lossy Networks
defines a generic Distance Vector protocol for Low Power and
Lossy Networks, many of which exhibit strongly asymmetrical
characteristics. This draft proposes an extension for that
optimizes RPL operations whereby upwards and downwards direction-optimized
RPL instances are associated.
</t>
</abstract>
<note title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119">RFC 2119</xref>.</t>
</note>
</front>
<middle>
<section title="Introduction">
<t>The IETF ROLL Working Group has defined
application-specific routing requirements for a Low Power and Lossy
Network (LLN) routing protocol, specified in
<xref target="RFC5548"></xref>,
<xref target="RFC5673"></xref>,
<xref target="RFC5826"></xref>, and
<xref target="RFC5867"></xref>,
many of which explicitly or implicitly refer to links with
asymmetrical properties.
</t>
<t>Upon those requirements, the <xref target="I-D.ietf-roll-rpl">
Routing Protocol for Low Power and Lossy Network</xref>
was designed as a platform that can be extended by further specification or
guidance, by adding new metrics, Objective Functions, or additional options.
</t>
<t>RPL forms Destination Oriented Directed Acyclic Graphs (DODAGs) within
instances of the protocol. Each instance is associated with an Objective
Function that is designed to solve the problem that is addressed by that
instance.</t>
<t>On one hand, RPL requires bi-directional links for the control, but on the
other hand, there is no requirement that the properties of a link are the same
in both directions. In fact, a perfect symmetry is rarely present in Low Power
and Lossy Networks (LLNs) such as wireless radio or power-line links.</t>
<t>Some initial implementations require that the quality of both directions of
a link is evaluated as operational at an acceptable level so that the link can
be used for control and data in both directions. This eliminates asymmetrical
links that are not operational at an acceptable level in one direction.</t>
<t>In practice, a DAG that is built to optimize upwards traffic is generally
not congruent with a DAG that is built to optimize downwards traffic. This is
why this specification is designed to enable asymmetrical routing DAGs that
are bound together to get the maximum benefits of all types of bi-directional
links.</t>
</section>
<section anchor="Terminology" title="Terminology">
<t>The terminology used in this document is consistent with and
incorporates that described in `Terminology in Low power And Lossy
Networks' <xref target="I-D.ietf-roll-terminology"></xref>
and <xref target="I-D.ietf-roll-rpl"/>.</t>
<t>The term upwards qualifies a link, a DODAG or a RPL instance that is optimal
for sending traffic towards the root, though may be usable but suboptimal for
traffic coming from the direction of the root. The term downwards qualifies the
same wording, only for opposite directions.</t>
<t>The term parenting applied to instances refers to the directional association
of two instances. The meta graph formed by parented instances must be a DAG. Traffic
may be transferred from an instance onto a parent instance under specified
circumstances.
</t>
<t> The draft also uses the following terminology:
<!--
o bi-directional
(traffic confirmed possible in both direction)
o uni-directional
(traffic confirmed possible only in one direction)
o symmetric
(bi-directional, with identical link characteristics in both directions)
o asymmetric
(bi-directional, with different link characteristics in both directions)
-->
<list style="hanging">
<t hangText="bi-directional:"> A link is bi-directional when traffic is confirmed
possible in both directions, in a fashion that is sufficient to operate RPL control.
</t>
<!--t hangText="uni-directional:">traffic confirmed possible only in one direction
</t>
<t hangText="symmetric:">bi-directional, with identical link characteristics in both directions
</t -->
<t hangText="asymmetric:"> A link is asymmetric if it is bi-directional, yet exhibits
major differences in link characteristics for both directions.
</t>
</list>
</t>
</section>
<section title="The Asymmetrical Link Problem">
</section>
<section title="Solution Overview">
<t>With the core RPL specification, <xref target="I-D.ietf-roll-rpl"/>
each instance is a separate routing topology, and packets must
be forwarded within the same topology / same instance. One direct
consequence of that design choice is that a topology must be
operational at an acceptable level for both upwards and downwards traffic;
otherwise, traffic between two nodes in the RPL instance may suffer.
</t>
<t>RPL is designed to operate on bi-directional links. When
the link properties do not widely differ between the upwards
and the downwards directions, a single DAG is adequate as the routing
topology for both upwards and downwards traffic. In that case,
an asymmetrical link, that can only be used for traffic in one direction,
cannot participate to the routing topology. This results in an
sub-optimal bandwidth utilization and/or a reduction of the possible path
diversity.
</t>
<t>
This issue can be addressed with <xref target="I-D.ietf-roll-rpl"/>,
by constructing two DAGs, one that is used for upwards traffic and one
that is used for downwards traffic. This solves the issue for all traffic
that transits through the root of the DODAG, whether it is originated
in the DODAG going out or is injected into the DODAG from the outside,
since in both cases a packet will mostly use the asymmetric links in the
appropriate direction.
</t>
<t>On the other hand, with RPL as it is specified, a packet follows the topology
that is generated for its instance all the way through a DAG, and transferring
a packet from an instance to another is not permitted.
As a result, the 2 DAGs solution would penalize Peer to peer traffic that would
have to go through the root in order to leave the upward instance and then reenter
at the root in order to join the downwards instance.
This is not an issue in non-storing mode since the packet has to go through the
root to load the routing header downwards anyway, but going through the root
stretches the path in storing mode.
</t>
<t>In order to benefit from both instances and yet avoid extra stretch through the
root in storing mode, it is required to extend RPL rules so as to allow traffic to be
transferred from one instance to the next before reaching the root on the way up.
This document specifies conditions under which 2 instances can be bound together
so that a node may transfer traffic from a RPL instance onto another, e.g.
from an upwards RPL instance onto the downwards RPL instance.
</t>
<t>It can be noted at this point that with <xref target="I-D.ietf-roll-rpl"/>,
traffic that goes down does not generally go back up again, whereas P2P
traffic within a DODAG might go up to a common parent and then down
to the destination. In terms of instance relationship, this means
that when an upwards and a downwards instances are bound together,
traffic from the former may be transferred to the latter, but not
the other way around. In other words, there is an order, a
parent-child relationship, between the two instances.
</t>
<t>Additionally, if there is no next-hop for a packet going down within
the instance, then with <xref target="I-D.ietf-roll-rpl"/> the packet
will be dropped or sent back with an error along the wrong direction
of an asymmetric link. In order to avoid those unwanted behaviors, it is
tempting though inefficient to lower the constraints that are applied
to build the topology. It can be more efficient to actually keep the
constraints as they should be, but, instead, enable a less constrained,
more spanning, fallback topology into which traffic can be transferred.
</t>
<t>For that reason, this solution allows for more complex instance
relationships than plain child-parent associations. In order to
avoids loops which could be created when transferring packets from
one instance to the next, this solution requires that the instances
be themselves organized as a Directed Acyclic Graph, and
enforce that inter-DAG transfers occur only within that meta DAG.
</t>
</section>
<section anchor="DAGInformationObject"
title="Modified DODAG Information Object (DIO)">
<t>The DODAG Information Object <xref target="I-D.ietf-roll-rpl"/>
carries information that allows a node to discover a RPL instance,
learn its configuration parameters, select a DODAG parent set, and
maintain the DODAG. This specification defines a new flag bit to
indicate that the DAG is directional.</t>
<t><figure anchor="DIObase" title="The DIO Base Object">
<artwork><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RPLInstanceID |Version Number | Rank |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|G|D| MOP | Prf | DTSN | Flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ DODAGID +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option(s)...
+-+-+-+-+-+-+-+-+
]]></artwork>
</figure></t>
<t><list hangIndent="6" style="hanging">
<t hangText="Directional (D):">The Directional (D) flag is set
to indicate that the instance is intended for directional operation,
and is reset otherwise. When the Directional (D) flag is set
a value of 0 for the MOP field indicates
upwards whereas any other value specified in
<xref target="I-D.ietf-roll-rpl"/> indicates downwards.
All other values of MOP shall be considered downwards unless
explicitly specified otherwise.</t>
</list></t>
</section>
<section title="Operations">
<t>This specification allows an organization of Instances as follows:
<list>
<t>Instances MUST be organized as a Directed Acyclic Graph. This
information MUST be commissioned into the devices so they know both
which instances they should participate in, and which direction of
transfer is allowed between instances.</t>
<t>A spanning instance using OF0 <xref target="I-D.ietf-roll-of0"/>
MAY be used as root in that instance DAG.</t>
</list>
</t>
<t>This specification defines a new bit in the
<xref target="I-D.ietf-roll-rpl">RPL</xref>
DODAG Information Object (DIO) with the Directional (D) flag that
indicates a directional operation for a given instance.
An implementation that does not support that new bit will not be able to
propagate it. </t>
<t>In case of a directional operation,
<list>
<t>The direction is indicated by the MOP field, a MOP set to a value
0 means upwards and any other setting indicates downwards.</t>
<t>Links are still REQUIRED to allow bidirectional operations</t>
<t>Only the metrics that correspond to the DAG direction are used for
the parent selection. </t>
<t>An upward instance SHOULD install routes that lead to the root and beyond -
typically the default route. </t>
<t>A downwards instance MAY ONLY install more specific routes that are
injected by nodes in the DODAG through the DAO process.</t>
<t>P2P operations are achieved by associating a child upwards instance with
a parent downwards instance.</t>
<t>A packet MUST NOT be transferred from a parent instance to a child instance. </t>
<t>A packet MAY be transferred from a child instance to its parent instance
if and only if the child instance does not provide a route to the destination,
or the parent instance provides a more specific route (longer match) to the
destination.
</t>
<t>Transferring from an upwards instance to a downwards instance is
desirable for Point to Point communication within a RPL domain.
</t>
<t>
Other forms of transfer do not denote a classical operation of the protocol
and as a general guidance they SHOULD be avoided. It is possible,
though, that such transfer becomes useful in a controlled environment,
for instance in the case of a transfer onto a last resort spanning instance.
Policies MAY be put in place to override the general guidance and allow such
transfers.
</t>
</list>
</t>
</section>
<section anchor="back" title="Backwards Compatibility">
<t>An OF is generally designed to compute a Rank of a directional
link in a fashion that is different from a bidirectional link, and
in particular will not use the same metrics and thus obtain different
ranks for a same situation. For that
reason, it is important that the OF is aware that an instance is
supposed to define a directional DODAG, and it is RECOMMENDED that
only devices that support directional DODAGs are allowed in a directional
instance. </t>
<t>It might happen that for some purposes like higher availability,
an implementation that does not support directional links is administratively
allowed to join a directional DODAG. In that case, the extension of the DODAG that starts
at that device will not be directional, but the instance will still be functional. </t>
<t>In that case, it might also happen that a device that supports directional DODAGs
per this specification sees candidate neighbors that expose the Directional flag
and some others that do not. An OF that supports directional links
SHOULD favor directional links over non directional links, in a fashion
that is to be specified by the OF. In the case of <xref target="I-D.ietf-roll-of0">
OF0 </xref>, the 'D' flag should be accounted for before the computation of item 8
in the "Selection Of The Preferred Parent" section 4.2.1, that is before ranks are
calculated and can be compared.
</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This specification requires that a bit in DIO shall be assigned to
indicate directional link operations as specified in
<xref target="DAGInformationObject"/> </t>
</section>
<section anchor="Sec" title="Security Considerations">
<t>Security considerations for this proposal are to be developed in accordance
with recommendations laid out in, for example, <xref
target="I-D.tsao-roll-security-framework"></xref>.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The author wishes to recognize Richard Kelsey, JP Vasseur, Tom Phinney, Robert Assimiti,
Don Sturek, Thomas Clausen and Yoav Ben-Yehezkel for their various contributions.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include='reference.I-D.ietf-roll-rpl.xml'?>
<?rfc include='reference.I-D.ietf-roll-terminology.xml'?>
</references>
<references title="Informative References">
<?rfc include='reference.I-D.ietf-roll-of0.xml'?>
<?rfc include="reference.RFC.5548"?>
<?rfc include="reference.RFC.5673"?>
<?rfc include="reference.RFC.5826"?>
<?rfc include="reference.RFC.5867"?>
<?rfc include='reference.I-D.tsao-roll-security-framework.xml'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 03:24:15 |