One document matched: draft-ietf-roll-of0-18.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-ietf-roll-of0-18" ipr="trust200902">
<front>
<title abbrev="draft-ietf-roll-of0">RPL Objective Function Zero</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 (RPL)
specification defines a generic Distance Vector protocol that is
adapted to a variety of networks types by the application of
specific Objective Functions. An Objective Function defines
how a RPL node selects and optimizes routes within a RPL Instance
based on the information objects available.
This document specifies a basic Objective Function that
relies only on the Protocol Data Units defined for the RPL
generic protocol, as opposed to extensions such as RPL
metric containers.
This document specifies a basic Objective Function that relies only on
the objects that are defined in RPL and does not use any extension.
-->
The Routing Protocol for Low Power and Lossy Networks (RPL)
specification defines a generic Distance Vector protocol that is
adapted to a variety of networks types by the application of specific
Objective Functions (OFs). An OF states the outcome of the process
used by a RPL node to select and optimize routes within a RPL
Instance based on the information objects available; an OF is not an
algorithm.</t>
<t>
This document specifies a basic Objective Function that relies only
on the objects that are defined in RPL and does not use any protocol
extension
</t>
</abstract>
<note title="Requirements Language">
<t> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "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>.
</t
<t> <xref target="I-D.ietf-roll-rpl">The Routing Protocol for LLN (RPL)
</xref> specification defines a generic Distance Vector protocol that is
adapted to a variety of Low Power and Lossy Networks (LLN) types by the
application of specific Objective Functions. An Objective Function defines
how a RPL node selects and optimizes routes within a RPL Instance
based on the information objects available. This separation of Objective Functions from
the core protocol specification allows RPL to be adapted to meet the different optimization
criteria required by the wide range of deployments, applications and network designs.</t>
-->
<t> <xref target="I-D.ietf-roll-rpl">
The Routing Protocol for Low Power and Lossy Networks (RPL)
</xref>specification defines a generic Distance Vector
protocol that is adapted to a variety of Low Power and Lossy Networks
(LLN) types by the application of specific Objective Functions (OFs).
</t>
<t>
An OF states the outcome of the process used by a RPL node to select
and optimize routes within a RPL Instance based on the information
objects available; an OF is not an algorithm. For example, "shortest
path first" is an algorithm where the least cost path between two points is
derived as an outcome; there are a number of algorithms that can be
used to satisfy the OF, of which the well-known Dijkstra algorithm is
an example.
</t>
<t>
The separation of OFs from the core protocol specification allows RPL
to be adapted to meet the different optimization criteria required by
the wide range of deployments, applications, and network designs.
</t>
<t>
RPL forms Directed Acyclic Graphs (DAGs) as collections of Destination Oriented DAGs (DODAGs)
within instances of the protocol.
Each instance is associated with a specialized Objective Function. A DODAG is periodically
reconstructed as a new DODAG Version to enable a global reoptimization of the graph.</t>
<t>
<!-- An Objective Function selects the DODAG Version that a device joins within an instance,
and a number of neighbor routers within that DODAG Version as parents or feasible successors.
The OF generates the Rank of the device, that represents an abstract distance to the root within the DODAG.
In turn, the Rank is used by the generic RPL core to avoid loops
and verify forward progression towards a destination, as specified in
-->
An instance of RPL running on a device uses an Objective Function to
help it determine which DODAG and which Version of that DODAG it should join. The OF is also
used by the RPL instance to select a number of routers within the
DODAG current and subsequent Versions to serve as parents or as feasible successors.</t>
<t>
The RPL instance uses the OF to compute a Rank for the device. This
value represents an abstract distance to the root of the DODAG within
the DODAG Version. The Rank is exchanged between nodes using RPL and
allows other RPL nodes to avoid loops and verify forward progression
toward the destination, as specified in <xref target="I-D.ietf-roll-rpl"/>.
Regardless of the particular OF used by a node, Rank will always
increase and thus, post convergence, loop free paths are always
formed.</t>
<t> The Objective Function Zero (OF0) operates on parameters that are obtained from provisioning,
the RPL DODAG Configuration option and the RPL DIO base container
<xref target="I-D.ietf-roll-rpl"/>.
</t>
<t>
The Rank of a node is obtained by adding a stricly positive, indirectly normalized scalar,
rank_increase (<xref target="vars"/>), to the Rank of a selected preferred parent.
The rank_increase is based on a step_of_rank (<xref target="vars"/>) normalized scalar that can vary with a ratio
from 1 (excellent) to 9 (worst acceptable) to represent the link properties. The step_of_rank
can be multiplied by a configurable factor called rank_factor (<xref target="parms"/>) that amplifies the rank_increase
to reflect the relative preferences between different link types that would be used in a same
RPL instance. The rank_increase can be further adapted as detailed in <xref target="comprank" />.
<!--
Though a Rank value is represented as 2 octets, OF0 with default settings uses
increments of 0x100 so that the value can be stored in one octet, and
allows to encode a minimum of 28 hops and a maximum of 255 hops.
As a result,
OF0 with default settings allows to encode a minimum of 28 (worst acceptable) hops and a
maximum of 255 (excellent) hops. -->
By default, OF0 encodes the 2-octet Rank in units of 256, and the default settings allow to
encode a minimum of 28 (worst acceptable) hops and a maximum of 255 (excellent) hops.
</t>
<!-- t>
How the link properties are transformed into a step_of_rank for a given hop
depends on the link type and on the implementation. It can be as simple as an administrative cost,
but might also derive from a statistical metric with some hysteresis.</t -->
<t> <!-- It is important that devices deployed in a particular network or
environment use the same OF to build and operate DODAGs. If they do
not, it is likely that sub-optimal paths will be selected. In
practice, without a common definition of an OF, RPL implementations
cannot guarantee to interoperate correctly. -->
The RPL specification
<xref target="I-D.ietf-roll-rpl"/> requires the use of a common OF by all nodes
in a network. The possible use of multiple OFs with a single network
is for further study. </t>
<t> The RPL specification <xref target="I-D.ietf-roll-rpl"/>
does not include any OF
definitions. This is left for other documents specific to different
deployments and application environments. Since there is no default OF or metric container in the RPL main specification, it might
happen that, unless two given implementations follow the same guidance for a specific problem
or environment, those implementations will not support a common OF with which they could interoperate.
</t>
<t>OF0 is designed as a default OF that will allow interoperation between implementations in a wide spectrum of use cases.
<!-- that are not specifically designed to
apply to a given case for which further guidance is provided. -->
This is why OF0 does not specify how the link properties are transformed into a rank_increase
and leaves that responsibility to the implementation;
rather, OF0 enforces the values for the rank_increase by normalizing the step_of_rank for
a normal link and its acceptable range, as opposed to formulating the details of the step_of_rank computation.
This is also why OF0 ignores metric containers.
</t>
<!-- t>
Indeed, it is the general design in RPL that the metrics are passed from parent to children in
a specific container and that the OF will derive the Rank from the natural metric.
The separation of Rank and metrics avoids a loss of information as the various metrics are propagated down the DAG.
This specification can be used when the link properties that are considered are
such that they can be turned in a scalar step_of_rank in a reversible fashion and the resulting
step_of_rank is additive over multiple hops. </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 'feasible successor' is used to refer to a neighbor that can possibly be used as
a next-hop for upwards traffic following the loop avoidance and forwarding rules that
the nodes implements and that
are defined in the RPL specification <xref target="I-D.ietf-roll-rpl"/>.
</t>
</section>
<!--
<section title="Objective Functions">
<t>An Objective Function (OF) allows for the selection of a DAG to
join, and a number of peers in that DAG as parents. The OF is used
to compute an ordered list of parents and provides load balancing
guidance. The OF is also responsible to compute the Rank of the
device within the DAG.</t>
<t><xref target="I-D.ietf-roll-rpl"/> defines the operation of RPL
and the generic interfaces that all OFs need to implement. OF0
does not require additional headers and is implemented using
only the information in the DIO Base.</t>
<t>The Objective Function is specified in the RA-DIO message using
an objective code point (OCP) and indicates the objective function
that has been used to compute the DAG (e.g. "minimize the path cost
using the ETX metric and avoid `Blue' links"). The objective code
points are specified in <xref
target="I-D.ietf-roll-routing-metrics" />. This document specifies
the OCP 0, in support of default operation.</t>
<t>OFO follows the same abstract behavior specified in < xref
target="I-D.ietf-roll-rpl" />: </t>
<list style="symbols">
<t>The parent selection is triggered each time an event indicates
that a potential next_hop information is updated. This might
happen upon the reception of a RA-DIO message, a timer elapse, or
a trigger indicating that the state of a candidate neighbor has
changed.</t>
<t>An OF scans all the interfaces on the device. Although there
may typically be only one interface in most application scenarios,
there might be multiple of them and an interface might be
configured to be usable or not for RPL operation. An interface can
also be configured with a preference or dynamically learned to be
better than another by some heuristics that might be link-layer
dependent and are out of scope. Finally an interface might or not
match a required criterion for an Objective Function, for instance
a degree of security. As a result some interfaces might be
completely excluded from the computation, while others might be
more or less preferred.</t>
<t>The OF scans all the candidate neighbors on the possible
interfaces to check whether they can act as an attachment router
for a DAG. There might be multiple of them and a candidate
neighbor might need to pass some validation tests before it can be
used. In particular, some link layers require experience on the
activity with a router to enable the router as a next_hop.</t>
<t>The OF computes self's Rank by adding the step_of_rank to that
candidate to the Rank of that candidate. The step_of_rank is
estimated as follows:</t>
<list style="symbols">
<t>The step_of_rank might vary from MINIMUM_STEP_OF_RANK to
MAXIMUM_STEP_OF_RANK.
</t>
<list style="symbols">
<t>MINIMUM_STEP_OF_RANK indicates a unusually good link, for instance a link
between powered devices in a mostly battery operated
environment.</t>
<t>DEFAULT_STEP_OF_RANK indicates a `normal'/typical link, as qualified by the
implementation.</t>
<t>MAXIMUM_STEP_OF_RANK indicates a link that can hardly be used to forward any
packet, for instance a radio link with quality indicator or
expected transmission count that is close to the acceptable
threshold.</t>
</list>
<t>Candidate neighbors that would cause self's Rank to increase
are ignored</t>
</list>
<t>Candidate neighbors that advertise an OF incompatible with the
set of OF specified by the policy functions are ignored.</t>
<t>As it scans all the candidate neighbors, the OF keeps the
current best parent and compares its capabilities with the current
candidate neighbor. The OF defines a number of tests that are
critical to reach the Objective. A test between the routers
determines an order relation.</t>
<list style="symbols">
<t>If the routers are roughly equal for that relation then the
next test is attempted between the routers,</t>
<t>Else the best of the 2 becomes the current best parent and
the scan continues with the next candidate neighbor</t>
<t>Some OFs may include a test to compare the Ranks that would
result if the node joined either router</t>
</list>
<t>When the scan is complete, the preferred parent is elected and
self's Rank is computed as the preferred parent Rank plus the step
in Rank with that parent.</t>
<t>Other rounds of scans might be necessary to elect alternate
parents and siblings. In the next rounds:</t>
<list style="symbols">
<t>Candidate neighbors that are not in the same DAG are
ignored</t>
<t>Candidate neighbors that are of worse Rank than self are
ignored</t>
<t>Candidate neighbors of a better Rank than self (non-siblings)
are preferred</t>
</list>
</list>
</section>
-->
<!--
<t>This document specifies a default objective metric, called OF0,
and using the OCP 0. OF0 is the default objective function of RPL,
and can be used if allowed by the policy of the processing node when
no objective function is included in the RA-DIO message, or if the
OF indicated in the RA-DIO message is unknown to the node. If not
allowed, then the RA-DIO message is simply ignored and not processed
by the node.</t>
-->
<section title="Objective Function Zero Overview">
<t>The RPL specification describes constraints on how nodes select
potential parents, called a parent set, from their neighbors.
All parents are feasible successors for upward traffic (towards
the root). Additionally, RPL allows the use of parents in a
subsequent Version of a same DODAG as feasible successors, in which
case this node acts as a leaf in the subsequent DODAG Version.
<!--
Further specifications might extend the set of feasible successors,
for instance to nodes of a same Rank, aka siblings. <xref target="I-D.ietf-roll-rpl"/>
-->
</t>
<t> The Goal of the OF0 is for a node to join a DODAG Version that
offers good enough connectivity to a specific set of nodes or to
a larger routing infrastructure though there is no guarantee
that the path will be optimized according to a specific metric.
This validation process for the connectivity is implementation and
link type dependent, and is out of scope. The validation involves
but is not limited to application of <xref target="I-D.ietf-roll-rpl"/>
sections 3.2.3 and 13 as appropriate, and may involve deployment specific policies
as well.
Thus, for the purpose of OF0, the term Grounded <xref target="I-D.ietf-roll-rpl"/>
means that the DODAG root provides such connectivity. How that connectivity is asserted
and maintained is out of scope.</t>
<t>Objective Function Zero is designed to find the nearest Grounded
root.
This can be achieved if the Rank of a node is very close to an
abstract function of its distance to the root.
This need is balanced with the other need of maintaining some path diversity,
which may be achieved by increasing the Rank.
In the absence of a Grounded root, inner connectivity within the LLN
is still desirable and floating DAGs will form, rooted at the
nodes with the highest administrative preference.</t>
<t>OF0 selects a preferred parent and a backup feasible successor if one is
available. All the upward traffic is normally routed via the preferred parent
with no attempt to perform any load balancing.
When the link conditions do not let an upward packet through the preferred parent,
the packet is passed to the backup feasible successor.</t>
<t>A RPL node monitors links to a number of neighbor nodes, and can use OF0 to
assign a rank_increase to each link.
Though the exact method for computing the rank_increase is implementation-dependent,
the computation must follow the rules that are specified in <xref target="comprank"/>.
</t>
</section>
<section title="OF0 Operations">
<section anchor="comprank" title="Computing Rank">
<t>An OF0 implementation first computes a variable step_of_rank
(<xref target="vars"/>) associated with a
given parent from relevant link properties and metrics. The
step_of_rank is used to compute the amount by which to increase the
rank along a particular link, as explained later in this section.
</t>
<t>Computing a step_of_rank based on a static metric such as an
administrative cost implies that the OF0 implementation
only considers parents with good enough connectivity, <!--for instance
neighbors that are reachable over an Ethernet link, or a WIFI link in
infrastructure mode, -->and results in a Rank that is analogous to hop-count.
In most LLNs, this favors paths with fewer but longer hops of poorer connectivity;
it is thus RECOMMENDED to base the computation of the step_of_rank
on dynamic link properties such as the expected transmission count metric (ETX)
as introduced in <xref target="DeCouto03"/> and discussed in
<xref target="I-D.ietf-roll-routing-metrics"/>. The
<xref target="I-D.ietf-roll-minrank-hysteresis-of">
Minimum Rank Objective Function with Hysteresis </xref>
provides guidance on how link cost can be computed and on how
hysteresis can improve Rank stability.</t>
<t>OF0 allows an implementation to stretch the step_of_rank in order to enable
the selection of at least one feasible successor and thus maintain path diversity.
Stretching the step_of_rank is NOT RECOMMENDED, because it augments the apparent
distance from the node to the root, distorts the DODAG from the optimal
shape and may cause instabilities due to greedy behaviors whereby
depending nodes augment their Ranks to use each other as parents in a loop.
Still, an implementation may stretch the step_of_rank with at most a configurable
stretch_of_rank (<xref target="parms"/>) of any value between 0 (no stretch) and
the fixed constant MAXIMUM_RANK_STRETCH (<xref target="consts"/>).</t>
<t>An implementation MUST maintain the stretched step_of_rank between
the fixed constants MINIMUM_STEP_OF_RANK and
MAXIMUM_STEP_OF_RANK (<xref target="consts"/>). This range allows to reflect a
large variation of link quality.</t>
<t>The gap between MINIMUM_STEP_OF_RANK and MAXIMUM_RANK_STRETCH
may not be sufficient in every case to strongly distinguish links of different
types or categories in order to favor, say, powered over battery-operated or wired
over wireless, within a same DAG. An implementation SHOULD allow the operator to configure a factor
called rank_factor (<xref target="parms"/>) and to apply the factor on all links
and peers to multiply the effect of the stretched step_of_rank in the rank_increase
computation as further detailed below.
</t>
<t>Additionally, an implementation MAY recognize categories of peers and links,
such as different link types, in which case it SHOULD be able to configure a more
specific rank_factor to those categories.
The rank_factor MUST be set between the fixed constants
MINIMUM_RANK_FACTOR and MAXIMUM_RANK_FACTOR (<xref target="consts"/>) .
</t>
<t>The variable rank_increase is represented in units expressed by the variable
MinHopRankIncrease which defaults to the fixed constant
DEFAULT_MIN_HOP_RANK_INCREASE (<xref target="I-D.ietf-roll-rpl"/>); with that setting,
the least significant octet in the RPL Rank field in the DIO Base
Object is not used.
</t>
<t>The step_of_rank Sp that is computed for that link is multiplied by the
rank_factor Rf and then possibly stretched by a term Sr that is less than or equal to
the configured stretch_of_rank.
The resulting rank_increase is added
to the Rank of preferred parent R(P) to obtain that of this node R(N):
</t>
<t> R(N) = R(P) + rank_increase where: </t>
<t> rank_increase = (Rf*Sp + Sr) * MinHopRankIncrease
</t>
<t>Optionally, the administrative preference of a root MAY be configured
to supersede the goal to join a Grounded DODAG. In that case, nodes will
associate to the root with the highest preference available, regardless
of whether that root is Grounded or not. Compared to a deployment with
a multitude of Grounded roots that would result in the same multitude of DODAGs,
such a configuration may result in possibly less but larger DODAGs, as many as
roots configured with the highest priority in the reachable vicinity.</t>
</section>
<section title="Parent Selection">
<section title="Selection Of The Preferred Parent">
<t>As it scans all the candidate neighbors, OF0 keeps the parent that is
the best for the following criteria (in order):
<list style="numbers">
<t><xref target="I-D.ietf-roll-rpl"/> section 8 spells out the generic
rules for a node to re-parent and in particular the boundaries
to augment its Rank within a DODAG Version.
A candidate that would not satisfy those rules MUST NOT be considered.</t>
<t>An implementation SHOULD validate a router prior to selecting it
as preferred.In most cases, a router that does not succeed the validation process
can not be further considered for selection as preferred parent. In any case
a router that succeeded that validation process SHOULD be preferred.</t>
<t>If the administrative preference of the root is configured to
supersede the goal to join a Grounded DODAG,
a router that offers connectivity to a more preferable root SHOULD be
preferred.</t>
<t>A router that offers connectivity to a grounded DODAG Version SHOULD be
preferred over one that does not.</t>
<t>A router that offers connectivity to a more preferable root SHOULD be
preferred.</t>
<t>When comparing 2 parents that belong to the same DODAG, a router that
offers connectivity to the most recent DODAG Version SHOULD be preferred.</t>
<t>The parent that causes the lesser resulting Rank
for this node, as specified in <xref target="comprank"/>,
SHOULD be preferred.</t>
<t>A DODAG Version for which there is an alternate parent SHOULD be preferred.
This check is OPTIONAL. It is performed by computing the
backup feasible successor while assuming that the router that is currently examined
is finally selected as preferred parent.</t>
<!-- t>The DODAG Version that was in use already SHOULD be preferred.</t -->
<t>The preferred parent that was in use already SHOULD be preferred.</t>
<t>A router that has announced a DIO message more recently SHOULD be preferred.</t>
</list>
These rules and their order MAY be varied by an implementation according to configured policy.
</t>
</section>
<section title="Selection Of The Backup Feasible Successor">
<t>When selecting a backup feasible successor, the OF performs in order the
following checks:
<list style="numbers">
<t>The backup feasible successor MUST NOT be the preferred parent.</t>
<t>
The backup feasible successor MUST be either in the same DODAG Version as
this node or in an subsequent DODAG Version.</t>
<t>Along with RPL rules, a Router in the same DODAG Version as
this node and with a Rank that is higher than the Rank
computed for this node MUST NOT be selected as a feasible successor.
<!--
Further specifications might allow a node of a same Rank as a feasible successor.
Further specifications might extend the set of feasible successors,
for instance to nodes of a same Rank, aka siblings.It MAY still be selected as sibling if no better Back-up next hop is found. -->
</t>
<t>A router with a lesser Rank SHOULD be preferred.</t>
<t>A router that has been validated as usable by an implementation-dependant
validation process SHOULD be preferred.</t>
<t>When multiple interfaces are available,
a router on a higher order interface is preferable.</t>
<t>The backup feasible successor that was in use already SHOULD be preferred.</t>
</list>
These rules and their order MAY be varied by an implementation according to configured policy.
</t>
</section>
</section>
</section>
<section anchor="API" title="Abstract Interface to OF0">
<t>Objective Function Zero interacts for its management and operations in the following ways:
<list
style="hanging">
<t hangText="Processing DIO:">When a new DIO is received, the OF that corresponds
to the Objective Code Point (OCP) in the DIO is triggered with the content of the DIO.
OF0 is identified by OCP 0 (to be validated by IANA <xref target="IANA"/>).</t>
<t hangText="Providing DAG information:">The OF0 support
provides an interface that returns information about a given instance.
This includes material from the DIO base header, the role (router, leaf),
and the Rank of this node.</t>
<!-- t>
hangText="Generating Options">The OF0 support can be required to
provide the material that is necessary to build a DIO option.</t -->
<t hangText="Providing a Parent List:"> The OF0 support
provides an interface that returns the ordered list of the parents and feasible
successors for a given instance to the RPL core.
This includes the material that is contained in the transit option for
each entry.</t>
<t hangText="Triggered Updates:"> The OF0 support provides events
to inform it that a change in DAG information or Parent List as occurred.
This can be caused by an interaction with another system component such
as configuration, timers, and device drivers, and the change may cause the
RPL core to fire a new DIO
or reset trickle timers.</t>
</list>
</t>
</section>
<section anchor="constvarpar" title="OF0 Operands">
<t>On top of variables and constants defined in <xref target="I-D.ietf-roll-rpl"/>,
this specification introduces the following variables and constants:
</t>
<section anchor="vars" title="Variables">
<t>OF0 uses the following variables:
<list style="hanging">
<t hangText="step_of_rank (strictly positive integer):">an intermediate computation based on the link
properties with a certain neighbor.</t>
<t hangText="rank_increase (strictly positive integer):">delta between the Rank of the preferred parent and self
</t>
</list></t>
</section>
<section anchor="parms" title="Configurable Parameters">
<t>OF0 can use the following optional configurable values that are used as
parameters to the rank_increase computation:
<list style="hanging">
<t hangText="stretch_of_rank (unsigned integer):">the maximum augmentation to
the step-of-rank of a preferred parent to allow the selection of an additional
feasible successor. If none is configured to the device, then the step_of_rank
is not stretched.</t>
<t hangText="rank_factor (strictly positive integer):">A configurable factor that is used
to multiply the effect of the link properties in the rank_increase computation.
If none is configured, then a rank_factor of 1 is used.</t>
</list>
</t>
</section>
<section anchor="consts" title="Constants">
<t> Section 17 of <xref target="I-D.ietf-roll-rpl"/> defines RPL constants.
OF0 fixes the values of the following constants:
<list style="hanging">
<t hangText="DEFAULT_STEP_OF_RANK:">3</t>
<t hangText="MINIMUM_STEP_OF_RANK:">1</t>
<t hangText="MAXIMUM_STEP_OF_RANK:">9</t>
<t hangText="DEFAULT_RANK_STRETCH:">0</t>
<t hangText="MAXIMUM_RANK_STRETCH:">5</t>
<t hangText="DEFAULT_RANK_FACTOR:">1</t>
<t hangText="MINIMUM_RANK_FACTOR:">1</t>
<t hangText="MAXIMUM_RANK_FACTOR:">4</t>
</list></t>
</section>
</section>
<section anchor="mgt" title="Manageability Considerations">
<t>Section 18 of <xref target="I-D.ietf-roll-rpl"/> depicts the management of the protocol.
This specification inherits from that section and its subsections, with the exception that metrics
as specified in <xref target="I-D.ietf-roll-routing-metrics" /> are not used and do not require
management.
</t>
<section anchor="mgtp" title="Device Configuration">
<t>An implementation SHOULD allow to configure at least a global rank_factor that applies
to all links. Additionally, the implementation may allow to group interfaces, links and/or
neighbors and configure a more specific rank_factor to such groups.
</t>
<t>An implementation MAY allow to configure a maximum stretch_of_rank as discussed in
<xref target="comprank"/>. If none is configured, a value of 0 is assumed and the step_of_rank
is not stretched.
</t>
<t>An OF0 implementation SHOULD support the DODAG Configuration option as specified in
section 6.7.6 of <xref target="I-D.ietf-roll-rpl"/> and apply the parameters contained therein.
As discussed in section 16 of <xref target="I-D.ietf-roll-rpl"/>, this requirement might be
overridden by further guidance for certain application scenarios.
When the option is used, the parameters are configured to the nodes that may become DODAG roots,
and the nodes are configured to redistribute the information using the DODAG Configuration option.
In particular, the value of MinHopRankIncrease can be distributed with that option and override
the fixed constant of DEFAULT_MIN_HOP_RANK_INCREASE that is defined section 17 of
<xref target="I-D.ietf-roll-rpl"/> with a fixed value of 256.
</t>
<t>Out of the box, that is at initial factory time, the default constant values SHOULD be used, that is:
<list>
<t>the rank_factor is set to the fixed constant DEFAULT_RANK_FACTOR (<xref target="consts"/>).
</t>
<t>the maximum stretch_of_rank is set to the fixed constant
DEFAULT_RANK_STRETCH (<xref target="consts"/>).
</t>
<t>the MinHopRankIncrease is set to the fixed constant
DEFAULT_MIN_HOP_RANK_INCREASE (<xref target="I-D.ietf-roll-rpl"/>).
</t>
</list>
The values can be overridden at anytime and apply at the next Version of the DODAG.
As discussed in section 16 of <xref target="I-D.ietf-roll-rpl"/>, this requirement
might be overridden by further guidance for certain application scenarios.
</t>
</section>
<section anchor="mgtm" title="Device Monitoring">
<t>As discussed in <xref target="API"/>, the OF support must be able to provide information
about its operations, and trigger events when that information changes.
At a minimum, the information should include:
<list>
<t> DAG information as specified in Section 6.3.1 of <xref target="I-D.ietf-roll-rpl"/>,
and including the DODAGID, the RPLInstanceID, the Mode of Operation, the Rank of this node,
the current Version Number, and the value of the Grounded flag. </t>
<t> A list of neighbors indicating the preferred parent and an alternate feasible if available.
For each neighbor, the Rank, the current Version Number, and the value of the Grounded flag should
be indicated.</t>
</list>
</t>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This specification requires the assignment of an Objective Code Point (OCP) for OF0
in the Objective Code Point Registry that is requested in section 20.5. of
<xref target="I-D.ietf-roll-rpl"/>.
<list hangIndent="6" style="hanging">
<t hangText="OCP code:">The value of 0 is suggested.
</t>
<t hangText="Description:">A basic Objective Function that relies only on
the objects that are defined in <xref target="I-D.ietf-roll-rpl"/>.
</t>
<t hangText="Defining RFC:">This.
</t>
</list>
</t>
</section>
<section anchor="Sec" title="Security Considerations">
<t>
This specification makes simple extensions to RPL and so is
vulnerable to and benefits from the security issues and mechanisms
described in <xref target="I-D.ietf-roll-rpl"/> and
<xref target="I-D.ietf-roll-security-framework"/>. This
document does not introduce new flows or new messages, thus requires
no specific mitigation for new threats. </t>
<t>
OF0 depends on information exchanged in the Rank and OCP protocol
elements. If those elements were compromised, then an implementation
of OF0 might generate the wrong path for a packet, resulting in it
being misrouted. Therefore, deployments are RECOMMENDED to use RPL
security mechanisms if there is a risk that routing information might
be modified or spoofed. </t>
<!--t>
This specification inherits from <xref target="I-D.ietf-roll-rpl"/> for its messages and
security mechanisms. Section 19 of <xref target="I-D.ietf-roll-rpl"/> provides Security
Considerations that are valid for both documents. This document does not introduce new flows
or new messages, thus requires no specific mitigation for new threats.
</t>
<t> For RPL operations in general but applicable to the operations described in this document,
<xref target="I-D.ietf-roll-rpl"/> evaluates the security threats and identifies
applicable countermeasures. <t -->
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>Most specific thanks to Philip Levis and Phoebus Chen for their help
in finalizing this document.</t><t>
Many thanks also to Adrian Farrel, Tim Winter, JP Vasseur, Julien Abeille, Mathilde
Durvy, Teco Boot, Navneet Agarwal, Meral Shirazipour and Henning Rogge for in-depth
review and first hand implementers' feedback.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include='reference.I-D.ietf-roll-rpl.xml'?>
</references>
<references title="Informative References">
<?rfc include='reference.I-D.ietf-roll-terminology.xml'?>
<?rfc include='reference.I-D.ietf-roll-security-framework.xml'?>
<!-- 5867?rfc include='reference.I-D.draft-ietf-roll-building-routing-reqs-07.xml'? -->
<!-- 5826?rfc include='reference.I-D.draft-ietf-roll-home-routing-reqs-08.xml'? -->
<!--
<?rfc include="reference.RFC.5548"?>
<?rfc include="reference.RFC.5826"?>
<?rfc include="reference.RFC.5867"?>
<?rfc include="reference.RFC.5673"?>
-->
<?rfc include='reference.I-D.ietf-roll-routing-metrics.xml'?>
<?rfc include="reference.I-D.ietf-roll-minrank-hysteresis-of"?>
<reference anchor="DeCouto03"
target="http://pdos.csail.mit.edu/papers/grid:mobicom03/paper.pdf">
<front>
<title abbrev="DeCouto03">
A High-Throughput Path Metric for Multi-Hop Wireless Routing
</title>
<author fullname="Douglas S. J. De Couto" surname="De Couto"> </author>
<author fullname="Daniel Aguayo" surname="Aguayo"> </author>
<author fullname="John Bicket" surname="Bicket"> </author>
<author fullname="Robert Morris" surname="Morris"> </author>
<date year="2003" />
</front>
<seriesInfo name="MobiCom '03"
value="The 9th ACM International Conference on Mobile
Computing and Networking, San Diego, California," />
<format target="http://pdos.csail.mit.edu/papers/grid:mobicom03/paper.pdf"
type="HTML" />
</reference>
<!--
<?rfc include="reference.RFC.2453"?>
<?rfc include="reference.RFC.3819"?>
<?rfc include="reference.RFC.4101"?>
<?rfc include="reference.RFC.4191"?>
<?rfc include="reference.RFC.4461"?>
<?rfc include="reference.RFC.4861"?>
<?rfc include="reference.RFC.4875"?>
<?rfc include="reference.RFC.4915"?>
<?rfc include="reference.RFC.5120"?>
<?rfc include="reference.I-D.draft-ietf-bfd-base-09.xml"?>
<?rfc include="reference.I-D.draft-ietf-manet-nhdp-10.xml"?>
<reference anchor="Levis08"
target="http://portal.acm.org/citation.cfm?id=1364804">
<front>
<title abbrev="Levis08">The Emergence of a Networking Primitive in
Wireless Sensor Networks</title>
<author fullname="Philip Levis" initials="P." surname="Levis">
<organization></organization>
</author>
<author fullname="Eric Brewer" initials="E." surname="Brewer">
<organization></organization>
</author>
<author fullname="David Culler" initials="D." surname="Culler">
<organization></organization>
</author>
<author fullname="David Gay" initials="D." surname="Gay">
<organization></organization>
</author>
<author fullname="Samuel Madden" initials="S." surname="Madden">
<organization></organization>
</author>
<author fullname="Neil Patel" initials="N." surname="Patel">
<organization></organization>
</author>
<author fullname="Joe Polastre" initials="J." surname="Polastre">
<organization></organization>
</author>
<author fullname="Scott Shenker" initials="S." surname="Shenker">
<organization></organization>
</author>
<author fullname="Robert Szewczyk" initials="R." surname="Szewczyk">
<organization></organization>
</author>
<author fullname="Alec Woo" initials="A." surname="Woo">
<organization></organization>
</author>
<date month="July" year="2008" />
</front>
<seriesInfo name="Communications of the ACM," value="v.51 n.7" />
<format target="http://portal.acm.org/citation.cfm?id=1364804"
type="HTML" />
</reference>
-->
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 03:36:17 |