draft-ietf-roll-of0-12.txt   draft-ietf-roll-of0-13.txt 
ROLL P. Thubert, Ed. ROLL P. Thubert, Ed.
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Standards Track May 17, 2011 Intended status: Standards Track June 15, 2011
Expires: November 18, 2011 Expires: December 17, 2011
RPL Objective Function 0 RPL Objective Function 0
draft-ietf-roll-of0-12 draft-ietf-roll-of0-13
Abstract Abstract
The Routing Protocol for Low Power and Lossy Networks (RPL) The Routing Protocol for Low Power and Lossy Networks (RPL)
specification defines a generic Distance Vector protocol that is specification defines a generic Distance Vector protocol that is
adapted to a variety of networks types by the application of a adapted to a variety of networks types by the application of specific
specific Objective Function. This document specifies a basic 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 objects that are defined Objective Function that relies only on the objects that are defined
in RPL and does not use any extension. in RPL and does not use any extension.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Status of this Memo Status of this Memo
skipping to change at page 1, line 41 skipping to change at page 1, line 43
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 18, 2011. This Internet-Draft will expire on December 17, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 17 skipping to change at page 2, line 20
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Objective Function 0 Overview . . . . . . . . . . . . . . . . 4 3. Objective Function 0 Overview . . . . . . . . . . . . . . . . 4
4. OF0 operations . . . . . . . . . . . . . . . . . . . . . . . . 5 4. OF0 Operations . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Computing Rank . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Computing Rank . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Feasible successors selection . . . . . . . . . . . . . . 6 4.2. Feasible Successors Selection . . . . . . . . . . . . . . 7
4.2.1. Selection of the Preferred Parent . . . . . . . . . . 6 4.2.1. Selection Of The Preferred Parent . . . . . . . . . . 7
4.2.2. Selection of the backup feasible successor . . . . . . 7 4.2.2. Selection Of The Backup Feasible Successor . . . . . . 8
5. Abstract Interface with RPL core . . . . . . . . . . . . . . . 8 5. Abstract Interface to OF0 . . . . . . . . . . . . . . . . . . 8
6. OF0 Operands . . . . . . . . . . . . . . . . . . . . . . . . . 8 6. OF0 Operands . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Variables . . . . . . . . . . . . . . . . . . . . . . . . 8 6.1. Variables . . . . . . . . . . . . . . . . . . . . . . . . 9
6.2. Configurable parameters . . . . . . . . . . . . . . . . . 8 6.2. Configurable Parameters . . . . . . . . . . . . . . . . . 9
6.3. Constants . . . . . . . . . . . . . . . . . . . . . . . . 9 6.3. Constants . . . . . . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. Manageability Considerations . . . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7.1. Device Configuration . . . . . . . . . . . . . . . . . . . 10
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 7.2. Device Monitoring . . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
10.1. Normative References . . . . . . . . . . . . . . . . . . . 10 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . . 10 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
11.1. Normative References . . . . . . . . . . . . . . . . . . . 12
11.2. Informative References . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
The Routing Protocol for Low Power and Lossy Networks The Routing Protocol for LLN (RPL) [I-D.ietf-roll-rpl] specification
[I-D.ietf-roll-rpl] was designed as a generic core that is agnostic defines a generic Distance Vector protocol that is adapted to a
to metrics and that is adapted to a given problem using Objective variety of Low Power and Lossy Networks (LLN) types by the
Functions (OF). This separation of Objective Functions from the core application of specific Objective Functions. An Objective Function
protocol specification allows RPL to adapt to meet the different defines how a RPL node selects and optimizes routes within a RPL
optimization criteria required by the wide range of use cases. 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.
RPL forms Destination Oriented Directed Acyclic Graphs (DODAGs) RPL forms Directed Acyclic Graphs (DAGs) as collections of
within instances of the protocol. Each instance is associated with a Destination Oriented DAGs (DODAGs) within instances of the protocol.
specialized Objective Function. A DODAG is periodically Each instance is associated with a specialized Objective Function. A
reconstructed in a new Version to enable a global reoptimization of DODAG is periodically reconstructed as a new DODAG Version to enable
the graph. a global reoptimization of the graph.
An Objective Function selects the DODAG Version that a device joins An instance of RPL running on a device uses an Objective Function to
within an instance, and a number of neighbor routers within that help it determine which DODAG Version it should join. The OF is also
DODAG Version as parents or feasible successors. The OF generates used by the RPL instance to select a number of routers within the
the Rank of the device, that represents an abstract distance to the DODAG Version to serve as parents or as feasible successors.
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 [I-D.ietf-roll-rpl].
The Objective Function 0 (OF0) operates on parameters that are The RPL instance uses the OF to compute a Rank for the device. This
obtained from provisionning, the RPL DODAG Configuration option and 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 [I-D.ietf-roll-rpl].
The Objective Function Zero (OF0) operates on parameters that are
obtained from provisioning, the RPL DODAG Configuration option and
the RPL DIO base container [I-D.ietf-roll-rpl]. the RPL DIO base container [I-D.ietf-roll-rpl].
The Rank of a node is obtained by adding a normalized scalar, The Rank of a node is obtained by adding a normalized scalar,
rank_increase, to the Rank of a selected preferred parent. The rank_increase (Section 6.1), to the Rank of a selected preferred
rank_increase can vary with a ratio from 1 ( excellent) to 9 (worst parent. The rank_increase can vary with a ratio from 1 (excellent)
acceptable) to represent the link properties. As a result, OF0 with to 9 (worst acceptable) to represent the link properties. By
default settings allows to encode a minimum of 28 (worst acceptable) 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. hops and a maximum of 255 (excellent) hops.
Since there is no default OF or metric container in the RPL main It is important that devices deployed in a particular network or
specification, it might happen that, unless two given implementations environment use the same OF to build and operate DODAGs. If they do
follow the same guidance for a specific problem or environment, those not, it is likely that sub-optimal paths will be selected). In
implementations will not support a common OF with which they could practice, without a common definition of an OF, RPL implementations
interoperate. cannot guarantee to interoperate correctly. The RPL specification
[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.
OF0 is designed as a default OF that will allow interoperation OF0 is designed as a default OF that will allow interoperation
between implementations in a wide spectrum of use cases. This is why between implementations in a wide spectrum of use cases. This is why
it is not specific as to how the link properties are transformed into it is not specific as to how the link properties are transformed into
a rank_increase and leaves that responsibility to the implementation; a rank_increase and leaves that responsibility to the implementation;
rather, OF0 enforces normalized values for the rank_increase of a rather, OF0 enforces normalized values for the rank_increase of a
normal link and its acceptable range, as opposed to formulating the normal link and its acceptable range, as opposed to formulating the
details of its computation. This is also why OF0 ignores metric details of its computation. This is also why OF0 ignores metric
containers. containers.
2. Terminology 2. Terminology
The terminology used in this document is consistent with and The Terminology used in this document is consistent with and
incorporates that described in `Terminology in Low power And Lossy incorporates that described in `Terminology in Low power And Lossy
Networks' [I-D.ietf-roll-terminology] and [I-D.ietf-roll-rpl]. Networks' [I-D.ietf-roll-terminology] and [I-D.ietf-roll-rpl].
The term feasible successor is used to refer to a neighbor that can 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 possibly be used as a next-hop for upwards traffic following the loop
avoidance and forwarding rules that the nodes implements and that are avoidance and forwarding rules that the nodes implements and that are
defined in the RPL specification [I-D.ietf-roll-rpl]. defined in the RPL specification [I-D.ietf-roll-rpl].
3. Objective Function 0 Overview 3. Objective Function 0 Overview
The RPL specification describes constraints on how nodes select The RPL specification describes constraints on how nodes select
potential parents, called a parent set, from their neighbors. All potential parents, called a parent set, from their neighbors. All
parents are feasible successors for upgoing traffic (towards the parents are feasible successors for upward traffic (towards the
root). Additionally, RPL allows the use of parents in a subsequent root). Additionally, RPL allows the use of parents in a subsequent
Version of a same DODAG as feasible successors, in which case this Version of a same DODAG as feasible successors, in which case this
node acts as a leaf in the subsequent DODAG Version. node acts as a leaf in the subsequent DODAG Version.
The Goal of the OF0 is for a node to join a DODAG Version that offers 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 good enough connectivity to a specific set of nodes or to a larger
routing infrastructure though there is no guarantee that the path routing infrastructure though there is no guarantee that the path
will be optimized according to a specific metric. For the purpose of will be optimized according to a specific metric. Thus, for the
OF0, Grounded thus means that the root provides such connectivity. purpose of OF0, the term Grounded [I-D.ietf-roll-rpl] means that the
How that connectivity is asserted and maintained is out of scope. DODAG 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. Objective Function 0 is designed to find the nearest Grounded root.
This can be achieved if the Rank of a node represents closely its This can be achieved if the Rank of a node is very close to an
distance to the root. This need is balanced with the other need of abstract function of its distance to the root. This need is balanced
maintaining some path diversity, which may be achieved by increasing with the other need of maintaining some path diversity, which may be
the Rank. In the absence of a Grounded root, LLN inner connectivity achieved by increasing the Rank. In the absence of a Grounded root,
is still desirable and floating DAGs will form, rooted at the nodes inner connectivity within the Low Power and Lossy Network is still
with the highest administrative preference. desirable and floating DAGs will form, rooted at the nodes with the
highest administrative preference.
OF0 selects a preferred parent and a backup feasible successor if one OF0 selects a preferred parent and a backup feasible successor if one
is available. All the upward traffic is normally routed via the is available. All the upward traffic is normally routed via the
preferred parent with no attempt to perform any load balancing. When preferred parent with no attempt to perform any load balancing. When
the link conditions do not let an upward packet through the preferred the link conditions do not let an upward packet through the preferred
parent, the packet is passed to the backup feasible successor. parent, the packet is passed to the backup feasible successor.
OF0 assigns a rank_increase to each link to another node that it A RPL node monitors links to a number of neighbor nodes, and can use
monitors. Though the exact method for computing the rank_increase is OF0 to assign a rank_increase to each link. Though the exact method
implementation-dependent, the computation must follow the rules that for computing the rank_increase is implementation-dependent, the
are specified in Section 4.1. computation must follow the rules that are specified in Section 4.1.
4. OF0 operations 4. OF0 Operations
4.1. Computing Rank 4.1. Computing Rank
An OF0 implementation first computes a step_of_rank associated with a An OF0 implementation first computes a variable step_of_rank
given parent from relevant link properties and metrics. (Section 6.1) 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.
Computing a step_of_rank based on a static metric such as an Computing a step_of_rank based on a static metric such as an
administrative cost implies that the OF0 implementation only administrative cost implies that the OF0 implementation only
considers parents with good enough connectivity, and results in a considers parents with good enough connectivity, and results in a
Rank that is analoguous to hop-count. In most LLNs, this favors Rank that is analogous to hop-count. In most LLNs, this favors paths
paths with less but longer hops of poorer connectivity; it is thus with fewer but longer hops of poorer connectivity; it is thus
recommended to base the computation of the step_of_rank on dynamic RECOMMENDED to base the computation of the step_of_rank on dynamic
link properties such as the expected transmission count metric (ETX) link properties such as the expected transmission count metric (ETX)
[DeCouto03]. The Minimum Rank Objective Function with Hysteresis [I-D.ietf-roll-routing-metrics],[DeCouto03]. The Minimum Rank
Objective Function with Hysteresis
[I-D.ietf-roll-minrank-hysteresis-of] provides guidance on how link [I-D.ietf-roll-minrank-hysteresis-of] provides guidance on how link
cost can be computed and on how hysteresis can improve Rank cost can be computed and on how hysteresis can improve Rank
stability. stability.
An implementation MAY allow to stretch the step_of_rank with a OF0 allows an implementation to stretch the step_of_rank in order to
stretch_of_rank up to no more than MAXIMUM_RANK_STRETCH in order to
enable the selection of at least one feasible successor and thus enable the selection of at least one feasible successor and thus
maintain path diversity. The use of a stretch_of_rank is not maintain path diversity. Stretching the step_of_rank is NOT
recommended as it augments the apparent distance from the node to the RECOMMENDED, because it augments the apparent distance from the node
root, distorts the DODAG from the optimal shape and may cause to the root, distorts the DODAG from the optimal shape and may cause
instabilities due to greedy behaviours whereby depending nodes instabilities due to greedy behaviors whereby depending nodes augment
augment their Ranks to use each other as parents in a loop. An their Ranks to use each other as parents in a loop. Still, an
implementation MUST maintain the stretched step_of_rank between implementation MAY stretch the step_of_rank with at most a
MINIMUM_STEP_OF_RANK and MAXIMUM_STEP_OF_RANK, which allows to configurable stretch_of_rank (Section 6.2) of any value between 0 (no
reflect a large variation of link quality. stretch) and the fixed constant MAXIMUM_RANK_STRETCH (Section 6.3).
An implementation MUST maintain the stretched step_of_rank between
the fixed constants MINIMUM_STEP_OF_RANK and MAXIMUM_STEP_OF_RANK
(Section 6.3). This range allows to reflect a large variation of
link quality.
The gap between MINIMUM_STEP_OF_RANK and MAXIMUM_RANK_STRETCH may not The gap between MINIMUM_STEP_OF_RANK and MAXIMUM_RANK_STRETCH may not
be sufficient in every case to strongly distinguish links of be sufficient in every case to strongly distinguish links of
different types or categories in order to favor, say, powered over different types or categories in order to favor, say, powered over
battery-operated or wired over wireless, within a same DAG. battery-operated or wired over wireless, within a same DAG. An
implementation SHOULD allow to configure a factor called rank_factor
An implementation SHOULD allow a configurable factor called (Section 6.2) and to apply the factor on all links and peers to
rank_factor and to apply the factor on all links and peers. multiply the effect of the stretched step_of_rank in the
rank_increase computation as further detailed below.
An implementation MAY recognize categories of peers and links, such Additionally, an implementation MAY recognize categories of peers and
as different MAC types, in which case it SHOULD be able to configure links, such as different MAC types, in which case it SHOULD be able
a more specific rank_factor to those categories. The rank_factor to configure a more specific rank_factor to those categories. The
SHOULD be set between MINIMUM_RANK_FACTOR and MAXIMUM_RANK_FACTOR. rank_factor MUST be set between the fixed constants
MINIMUM_RANK_FACTOR and MAXIMUM_RANK_FACTOR (Section 6.3) .
The rank_increase is expressed in units of MinHopRankIncrease, which The variable rank_increase is represented in units expressed by the
defaults to DEFAULT_MIN_HOP_RANK_INCREASE; with that setting, the variable MinHopRankIncrease which defaults to the fixed constant
least significant octet in the RPL Rank is not used. DEFAULT_MIN_HOP_RANK_INCREASE ([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.
The step_of_rank Sp that is computed for that link is multiplied by The step_of_rank Sp that is computed for that link is multiplied by
the rank_factor Rf and then possibly stretched by a stretch_of_rank the rank_factor Rf and then possibly stretched by a stretch_of_rank
Sr. The resulting rank_increase is added to the Rank of preferred Sr. The resulting rank_increase is added to the Rank of preferred
parent R(P) to obtain that of this node R(N): parent R(P) to obtain that of this node R(N):
R(N) = R(P) + rank_increase where: R(N) = R(P) + rank_increase where:
rank_increase = (Rf*Sp + Sr) * MinHopRankIncrease rank_increase = (Rf*Sp + Sr) * MinHopRankIncrease
Optionally, the administrative preference of a root MAY be configured Optionally, the administrative preference of a root MAY be configured
to supersede the goal to join a Grounded DODAG. In that case, nodes to supersede the goal to join a Grounded DODAG. In that case, nodes
will associate to the root with the highest preference available, will associate to the root with the highest preference available,
regardless of whether that root is Grounded or not. Compared to a regardless of whether that root is Grounded or not. Compared to a
deployment with a multitude of Grounded roots that would result in a deployment with a multitude of Grounded roots that would result in
same multitude of DODAGs, such a configuration may result in possibly the same multitude of DODAGs, such a configuration may result in
less but larger DODAGs, as many as roots configured with the highest possibly less but larger DODAGs, as many as roots configured with the
priority in the reachable vicinity. highest priority in the reachable vicinity.
4.2. Feasible successors selection 4.2. Feasible Successors Selection
4.2.1. Selection of the Preferred Parent 4.2.1. Selection Of The Preferred Parent
As it scans all the candidate neighbors, OF0 keeps the parent that is As it scans all the candidate neighbors, OF0 keeps the parent that is
the best for the following criteria (in order): the best for the following criteria (in order):
1. [I-D.ietf-roll-rpl] section 8 spells out the generic rules for a 1. [I-D.ietf-roll-rpl] section 8 spells out the generic rules for a
node to reparent and in particular the boundaries to augment its node to re-parent and in particular the boundaries to augment
Rank within a DODAG Version. A candidate that would not satisfy its Rank within a DODAG Version. A candidate that would not
those rules MUST NOT be considered. satisfy those rules MUST NOT be considered.
2. An implementation should validate a router prior to selecting it 2. An implementation SHOULD validate a router prior to selecting it
as preferred. This validation process is implementation and as preferred. This validation process is implementation and
link type dependent, and is out of scope. A router that link type dependent, and is out of scope. A router that
succeeded that validation process is preferable. succeeded that validation process is preferable.
3. When multiple interfaces are available, a policy might be 3. When multiple interfaces are available, a policy might be
locally configured to order them and that policy applies first; locally configured to order them and that policy applies first;
that is a router on a higher order interface in the policy is that is a router on a higher order interface in the policy is
preferable. preferable.
4. If the administrative preference of the root is configured to 4. If the administrative preference of the root is configured to
skipping to change at page 7, line 16 skipping to change at page 7, line 46
SHOULD be preferred. SHOULD be preferred.
7. When comparing 2 parents that belong to the same DODAG, a router 7. When comparing 2 parents that belong to the same DODAG, a router
that offers connectivity to the most recent DODAG Version SHOULD that offers connectivity to the most recent DODAG Version SHOULD
be preferred. be preferred.
8. The parent that causes the lesser resulting Rank for this node, 8. The parent that causes the lesser resulting Rank for this node,
as specified in Section 4.1, SHOULD be preferred. as specified in Section 4.1, SHOULD be preferred.
9. A DODAG Version for which there is an alternate parent SHOULD be 9. A DODAG Version for which there is an alternate parent SHOULD be
preferred. This check is optional. It is performed by preferred. This check is OPTIONAL. It is performed by
computing the backup feasible successor while assuming that the computing the backup feasible successor while assuming that the
router that is currently examined is finally selected as router that is currently examined is finally selected as
preferred parent. preferred parent.
10. The preferred parent that was in use already SHOULD be 10. The preferred parent that was in use already SHOULD be
preferred. preferred.
11. A router that has announced a DIO message more recently SHOULD 11. A router that has announced a DIO message more recently SHOULD
be preferred. be preferred.
4.2.2. Selection of the backup feasible successor These rules and their order MAY be varied by an implementation
according to configured policy.
4.2.2. Selection Of The Backup Feasible Successor
When selecting a backup feasible successor, the OF performs in order When selecting a backup feasible successor, the OF performs in order
the following checks: the following checks:
1. When multiple interfaces are available, a router on a higher 1. When multiple interfaces are available, a router on a higher
order interface is preferable. order interface is preferable.
2. The backup feasible successor MUST NOT be the preferred parent. 2. The backup feasible successor MUST NOT be the preferred parent.
3. The backup feasible successor MUST be either in the same DODAG 3. The backup feasible successor MUST be either in the same DODAG
skipping to change at page 8, line 5 skipping to change at page 8, line 36
this node MUST NOT be selected as a feasible successor. this node MUST NOT be selected as a feasible successor.
5. A router with a lesser Rank SHOULD be preferred. 5. A router with a lesser Rank SHOULD be preferred.
6. A router that has been validated as usable by an implementation- 6. A router that has been validated as usable by an implementation-
dependant validation process SHOULD be preferred. dependant validation process SHOULD be preferred.
7. The backup feasible successor that was in use already SHOULD be 7. The backup feasible successor that was in use already SHOULD be
preferred. preferred.
5. Abstract Interface with RPL core These rules and their order MAY be varied by an implementation
according to configured policy.
Objective Function 0 interacts with the RPL core in the following 5. Abstract Interface to OF0
ways:
Processing DIO: When a new DIO is received, the RPL core calls the Objective Function 0 interacts for its management and operations in
OF that corresponds to the Objective Code Point OCP) in the DIO . the following ways:
OF0 corresponds to the OCP 0 (to be validated by IANA).
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 Section 8).
Providing DAG information: The OF0 support provides an interface Providing DAG information: The OF0 support provides an interface
that returns information about a given instance. This includes that returns information about a given instance. This includes
material from the DIO base header, the role (router, leaf), and material from the DIO base header, the role (router, leaf), and
the Rank of this node. the Rank of this node.
Providing a Parent List: The OF0 support provide an interface that Providing a Parent List: The OF0 support provide an interface that
returns the ordered list of the parents and feasible successors returns the ordered list of the parents and feasible successors
for a given instance to the RPL core. This includes the material for a given instance to the RPL core. This includes the material
that is contained in the transit option for each entry. that is contained in the transit option for each entry.
Calling back: The RPL core provides a call back interface for the Triggered Updates: the OF0 support provides events to inform it that
OF0 support to inform it that a change in DAG information or a change in DAG information or Parent List as occurred. This can
Parent List as occurred. This can be caused by an interaction be caused by an interaction with another system component such as
with another system component such as configuration, timers, and configuration, timers, and device drivers, and the change may
device drivers, and the change may cause the RPL core to fire a cause the RPL core to fire a new DIO or reset trickle timers.
new DIO or reset trickle timers.
6. OF0 Operands 6. OF0 Operands
On top of variables and constants defined in [I-D.ietf-roll-rpl],
this specification introduces the following variables and constants:
6.1. Variables 6.1. Variables
OF0 uses the following variables: OF0 uses the following variables:
step_of_rank (unsigned integer): an intermediate computation based step_of_rank (unsigned integer): an intermediate computation based
on the link properties with a certain neighbor. on the link properties with a certain neighbor.
rank_increase (unsigned integer): delta between the Rank of the rank_increase (unsigned integer): delta between the Rank of the
preferred parent and self preferred parent and self
6.2. Configurable parameters 6.2. Configurable Parameters
OF0 can use the following optional parameters: OF0 can use the following optional configurable values that are used
as parameters to the rank_increase computation:
stretch_of_rank (unsigned integer): an optional augmentation to the stretch_of_rank (unsigned integer): the maximum augmentation to the
step-of-rank of the preferred parent to allow the selection of step-of-rank of a preferred parent to allow the selection of an
additional parents. additional feasible successor. If none is configured to the
device, then the step_of_rank is not stretched.
rank_factor (unsigned integer): A configurable factor that is used rank_factor (unsigned integer): A configurable factor that is used
to multiply the effect of the link properties in the rank_increase to multiply the effect of the link properties in the rank_increase
computation. computation. If none is configured, then a rank_factor of 1 is
used.
6.3. Constants 6.3. Constants
OF0 fixes the following constants: Section 17 of [I-D.ietf-roll-rpl] defines RPL constants. OF0 fixes
the values of the following constants:
DEFAULT_MIN_HOP_RANK_INCREASE: 256
DEFAULT_STEP_OF_RANK: 3 DEFAULT_STEP_OF_RANK: 3
MINIMUM_STEP_OF_RANK: 1 MINIMUM_STEP_OF_RANK: 1
MAXIMUM_STEP_OF_RANK: 9 MAXIMUM_STEP_OF_RANK: 9
DEFAULT_RANK_STRETCH: 0 DEFAULT_RANK_STRETCH: 0
MAXIMUM_RANK_STRETCH: 5 MAXIMUM_RANK_STRETCH: 5
DEFAULT_RANK_FACTOR: 1 DEFAULT_RANK_FACTOR: 1
MINIMUM_RANK_FACTOR: 1 MINIMUM_RANK_FACTOR: 1
MAXIMUM_RANK_FACTOR: 4 MAXIMUM_RANK_FACTOR: 4
7. IANA Considerations 7. Manageability Considerations
This specification requires the assignment of a RPL Objective Code Section 18 of [I-D.ietf-roll-rpl] depicts the management of the
Point (OCP) for OF0. The value of 0 is suggested. protocol. This specification inherits from that section and its
subsections, with the exception that metrics as specified in
[I-D.ietf-roll-routing-metrics] are not used and do not require
management.
8. Security Considerations 7.1. Device Configuration
Security Considerations for OCP/OF are to be developed in accordance An implementation SHOULD allow to configure at least a global
with recommendations laid out in, for example, rank_factor that applies to all links. Additionally, the
[I-D.tsao-roll-security-framework]. implementation may allow to group interfaces, links and/or neighbors
and configure a more specific rank_factor to such groups.
9. Acknowledgements An implementation MAY allow to configure a maximum stretch_of_rank as
discussed in Section 4.1. If none is configured, a value of 0 is
assumed and the step_of_rank is not stretched.
An OF0 implementation SHOULD support the DODAG Configuration option
as specified in section 6.7.6 of [I-D.ietf-roll-rpl] and apply the
parameters contained therein. 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 [I-D.ietf-roll-rpl] with a fixed value of 256.
At build-time, the default constant values should be used, that is:
the rank_factor is set to the fixed constant DEFAULT_RANK_FACTOR
(Section 6.3).
the maximum stretch_of_rank is set to the fixed constant
DEFAULT_RANK_STRETCH (Section 6.3).
the MinHopRankIncrease is set to the fixed constant
DEFAULT_MIN_HOP_RANK_INCREASE ([I-D.ietf-roll-rpl]).
The values can be overridden at anytime and apply at the next Version
of the DODAG.
7.2. Device Monitoring
As discussed in Section 5, the OF support must be able to provide
information about its operations, and trigger events when tthat
information changes. At a minimum, the information should include:
DAG information as specified in Section 6.3.1 of
[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.
A list of neighbors indicating the preferred parent and an
alternate feasible if available. For each neighbor, the Rank, he
current Version Number, and the value of the Grounded flag should
be indicated
8. IANA Considerations
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 [I-D.ietf-roll-rpl].
OCP code: The value of 0 is suggested.
Description: A basic Objective Function that relies only on the
objects that are defined in [I-D.ietf-roll-rpl].
Defining RFC: This.
9. Security Considerations
This specification inherits from [I-D.ietf-roll-rpl] for its messages
and security mechanisms. Section 19 of [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.
For RPL operations in general but applicable to the operations
described in this document, [I-D.ietf-roll-security-framework]
evaluates the security threats and identifies applicable
countermeasures.
10. Acknowledgements
Most specific thanks to Philip Levis and Phoebus Chen for their help Most specific thanks to Philip Levis and Phoebus Chen for their help
in finalizing this document. in finalizing this document.
Many thanks also to Tim Winter, JP Vasseur, Julien Abeille, Mathilde Many thanks also to Adrian Farrel, Tim Winter, JP Vasseur, Julien
Durvy, Teco Boot, Navneet Agarwal and Henning Rogge for in-depth Abeille, Mathilde Durvy, Teco Boot, Navneet Agarwal, Meral
review and first hand implementer's feedback. Shirazipour and Henning Rogge for in-depth review and first hand
implementers' feedback.
10. References 11. References
10.1. Normative References 11.1. Normative References
[I-D.ietf-roll-rpl]
Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J.,
Kelsey, R., Levis, P., Pister, K., Struik, R., and J.
Vasseur, "RPL: IPv6 Routing Protocol for Low power and
Lossy Networks", draft-ietf-roll-rpl-19 (work in
progress), March 2011.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
10.2. Informative References 11.2. Informative References
[DeCouto03] [DeCouto03]
De Couto, Aguayo, Bicket, and Morris, "A High-Throughput De Couto, Aguayo, Bicket, and Morris, "A High-Throughput
Path Metric for Multi-Hop Wireless Routing", MobiCom Path Metric for Multi-Hop Wireless Routing", MobiCom
'03 The 9th ACM International Conference on Mobile '03 The 9th ACM International Conference on Mobile
Computing and Networking, San Diego, California,, 2003, <h Computing and Networking, San Diego, California,, 2003, <h
ttp://pdos.csail.mit.edu/papers/grid:mobicom03/paper.pdf>. ttp://pdos.csail.mit.edu/papers/grid:mobicom03/paper.pdf>.
[I-D.ietf-roll-minrank-hysteresis-of] [I-D.ietf-roll-minrank-hysteresis-of]
Gnawali, O. and P. Levis, "The Minimum Rank Objective Gnawali, O. and P. Levis, "The Minimum Rank Objective
Function with Hysteresis", Function with Hysteresis",
draft-ietf-roll-minrank-hysteresis-of-03 (work in draft-ietf-roll-minrank-hysteresis-of-04 (work in
progress), May 2011. progress), May 2011.
[I-D.ietf-roll-rpl] [I-D.ietf-roll-routing-metrics]
Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J., Vasseur, J., Kim, M., Pister, K., Dejean, N., and D.
Kelsey, R., Levis, P., Pister, K., Struik, R., and J. Barthel, "Routing Metrics used for Path Calculation in Low
Vasseur, "RPL: IPv6 Routing Protocol for Low power and Power and Lossy Networks",
Lossy Networks", draft-ietf-roll-rpl-19 (work in draft-ietf-roll-routing-metrics-19 (work in progress),
progress), March 2011. March 2011.
[I-D.ietf-roll-security-framework]
Tsao, T., Alexander, R., Dohler, M., Daza, V., and A.
Lozano, "A Security Framework for Routing over Low Power
and Lossy Networks", draft-ietf-roll-security-framework-05
(work in progress), April 2011.
[I-D.ietf-roll-terminology] [I-D.ietf-roll-terminology]
Vasseur, J., "Terminology in Low power And Lossy Vasseur, J., "Terminology in Low power And Lossy
Networks", draft-ietf-roll-terminology-05 (work in Networks", draft-ietf-roll-terminology-05 (work in
progress), March 2011. progress), March 2011.
[I-D.tsao-roll-security-framework]
Tsao, T., Alexander, R., Daza, V., and A. Lozano, "A
Security Framework for Routing over Low Power and Lossy
Networks", draft-tsao-roll-security-framework-02 (work in
progress), March 2010.
Author's Address Author's Address
Pascal Thubert (editor) Pascal Thubert (editor)
Cisco Systems Cisco Systems
Village d'Entreprises Green Side Village d'Entreprises Green Side
400, Avenue de Roumanille 400, Avenue de Roumanille
Batiment T3 Batiment T3
Biot - Sophia Antipolis 06410 Biot - Sophia Antipolis 06410
FRANCE FRANCE
 End of changes. 56 change blocks. 
155 lines changed or deleted 282 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/