RPL Objective Function 0
Cisco Systems
Village d'Entreprises Green Side
400, Avenue de Roumanille
Batiment T3
Biot - Sophia Antipolis
06410
FRANCE
+33 497 23 26 34
pthubert@cisco.com
Routing Area
Networking Working Group
Draft
The Routing Protocol for Low Power and Lossy Networks (RPL)
defines a generic Distance Vector protocol for
Low Power and Lossy Networks (LLNs). RPL is instantiated
to honor a particular routing objective/constraint
by the adding a specific Objective Function (OF) that
is designed to solve that problem. This specification defines a basic OF,
OF0, that uses only the abstract properties exposed in RPL messages
to maximize connectivity.
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 RFC 2119.
The IETF ROLL Working Group has defined
application-specific routing requirements for a Low Power and Lossy
Network (LLN) routing protocol, specified in , , , and .
Considering the wide variety of use cases, link types and metrics,
the Routing Protocol for Low Power and Lossy Networks
was designed as a generic core that is agnostic to metrics and instantiated using Objective Functions.
RPL forms Destination Oriented Directed Acyclic Graphs (DODAGs) within instances of the protocol,
each instance being set up to honor a particular routing objective/constraint of a given deployment.
This instantiation is achieved by plugging into the RPL core a specific Objective Function (OF) that is designed to solve
that problem to be addressed by that instance.
the Objective Function selects the DODAG iteration that a device joins, and a number
of neighbor routers within that iteration as parents and siblings.
The OF is also responsible for computing the Rank of the device,
that abstracts a relative position within the DODAG and is used by the RPL core
to enable a degree of loop avoidance and verify forward progression towards a destination,
as specified in .
This document defines the Objective Function 0 (OF0), which operates
on information defined in the RPL specification
and does not require any additional option.
The terminology used in this document is consistent with and
incorporates that described in `Terminology in Low power And Lossy
Networks'
and .
This specification defines the basic Objective Function, that is
also called OF0 since it corresponds to the Objective Code Point 0.
OF0 does not leverage link layer metrics such as
described in ,
but is only based on abstract information from the DIO base
container, such as Rank and administrative preference.
The Goal of the OF0 is to join a DODAG iteration that
offers connectivity to a specific set of nodes or to
a larger routing infrastructure.
For the purpose of OF0, Grounded thus means that the root
provides such connectivity. How that connectivity is asserted
and maintained is out of scope.
Objective Function 0 is designed to find the nearest Grounded
root. In the absence of a Grounded root, LLN inner connectivity
is still desirable and floating DAGs will form, rooted at the
nodes with the highest administrative preference.
The metric used in OF0 is the RPL Rank, as defined in .
Using a metric that in essence is similar to hop count
implies that the quality of the connectivity should be asserted so that
only neighbors with a good enough connectivity are presented to the OF.
How that connectivity is asserted and maintained is out of scope.
The default step of Rank is DEFAULT_RANK_INCREMENT for each hop. An implementation
MAY allow a step between MINIMUM_RANK_INCREMENT and MAXIMUM_RANK_INCREMENT to reflect a large variation
of link quality. It MAY stretch its step of Rank by up to MAXIMUM_RANK_STRETCH in order
to enable the selection of a sibling when only one parent is available.
For instance, say that a node computes a step of Rank of 4 from a
preferred parent with a Rank of 6 resulting in a Rank of 10 for this node.
Say that with that Rank of 10, this node would end up with only one
parent and no sibling, though there is a neighbor with a Rank of 12.
In that case, the node is entitled to stretch its step of Rank by a value of 2,
thus using a step of Rank of 6 so as to reach a Rank of 12 and find a sibling.
But the node is not entitled to use a step of Rank larger than 6
since that would be a greedy behavior that would deprive the neighbor
of this snode as a successor.
Also, if the neighbor had exposed a Rank of 16, the stretch
of Rank from 10 to 16 would have exceeded MAXIMUM_RANK_STRETCH of 4
and thus the neighbor would not have been selectable even as a sibling.
Optionally, the administrative preference of a root MAY be configured
to supercede the goal to reach Grounded root. 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 a 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 vincinity.
OF0 selects a preferred parent and a backup next_hop if one is
available. The backup next_hop might be a parent or a sibling. All
the traffic is routed via the preferred parent. When the link
conditions do not let a packet through the preferred parent,
the packet is passed to the backup next_hop.
As it scans all the candidate neighbors, OF0 keeps the parent
that is the best for the following criteria (in order):
spells out the generic
rules for a node to reparent and in particular the boundaries
to augment its Rank within a DODAG iteration.
A candidate that would not satisfy those rules MUST NOT be considered.
An implementation should validate a router prior to selecting it
as preferred. This validation process is implementation and link type
dependent, and is out of scope. A router that has been validated
is preferrable.
When multiple interfaces are available,
a policy might be locally configured to prioritize them and that policy applies first;
that is a router on a higher order interface is preferable.
In the absence of a Grounded DODAG iteration, the router with a higher
administrative preference SHOULD be preferred. Optionally, this selection applies
regardless of whether the DODAG is Grounded or not.
A router that offers connectivity to a grounded DODAG iteration SHOULD be
preferred over one that does not.
When comparing 2 routers that belong to the same DODAG, a router that
offers connectivity to the freshest sequence SHOULD be preferred.
When computing a resulting Rank for this node from a parent Rank and a Step of Rank
from that parent, the parent that causes the lesser resulting Rank SHOULD be preferred.
A DODAG iteration for which there is an alternate parent SHOULD be preferred.
This check is optional. It is performed by computing the
backup next_hop while assuming that the router that is currently examined
is finally selected as preferred parent.
The DODAG iteration that was in use already SHOULD be preferred.
The preferred parent that was in use already SHOULD be preferred.
A router that has announced a DIO message more recently SHOULD be preferred.
When multiple interfaces are available,
a router on a higher order interface is preferable.
The preferred parent MUST be ignored.
A Router that is not in the same DODAG as the preferred
parent, either in the current or a subsequent iteration, MUST be ignored.
A Router with a Rank that is higher than the Rank computed for this node
out of the preferred parent SHOULD NOT be selected as parent, to avoid greedy behaviors.
It MAY still be selected as sibling if no better Back-up next hop is found.
A router with a lesser Rank SHOULD be preferred.
A router that has been validated as usable by an implementation dependant
validation process SHOULD be preferred.
The backup next_hop that was in use already SHOULD be preferred.
OF0 uses the following constants:
4
1
16
4
IThis specification requires the assignment of an OCP for OF0. The value of 0 is suggested.
Security Considerations for OCP/OF are to be developed in accordance
with recommendations laid out in, for example, .
Most specific thanks to Tim Winter, JP Vasseur, Julien Abeille and Mathilde
Durvy for in-depth review and first hand implementer's feedback.