draft-ietf-roll-of0-01.txt   draft-ietf-roll-of0-02.txt 
Networking Working Group P. Thubert, Ed. Networking Working Group P. Thubert, Ed.
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Standards Track February 18, 2010 Intended status: Standards Track June 2, 2010
Expires: August 22, 2010 Expires: December 4, 2010
RPL Objective Function 0 RPL Objective Function 0
draft-ietf-roll-of0-01 draft-ietf-roll-of0-02
Abstract Abstract
The Routing Protocol for Low Power and Lossy Networks (RPL) defines a The Routing Protocol for Low Power and Lossy Networks (RPL) defines a
generic Distance Vector protocol for Low Power and Lossy Networks generic Distance Vector protocol for Low Power and Lossy Networks
(LLNs). RPL is instantiated to honor a particular routing objective/ (LLNs). RPL is instantiated to honor a particular routing objective/
constraint by the adding a specific Objective Function (OF) that is constraint by the adding a specific Objective Function (OF) that is
designed to solve that problem. This specification defines a basic designed to solve that problem. This specification defines a basic
OF, OF0, that uses only the abstract properties exposed in RPL OF, OF0, that uses only the abstract properties exposed in RPL
messages to maximize connectivity. messages to maximize connectivity.
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
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. 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."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on December 4, 2010.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 22, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
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 BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Basic Objective Function . . . . . . . . . . . . . . . . . . . 3 3. Goal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Goal . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Selection of the Preferred Parent . . . . . . . . . . . . . . . 5
3.2. Selection of the Preferred Parent . . . . . . . . . . . . . 5 5. Selection of the Backup next_hop . . . . . . . . . . . . . . . 6
3.3. Selection of the Backup next_hop . . . . . . . . . . . . . 6 6. Abstract Interface with RPL core . . . . . . . . . . . . . . . 6
4. OF0 Constants and Variables . . . . . . . . . . . . . . . . . . 6 7. OF0 Constants and Variables . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 9. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 11.1. Normative References . . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . . 7 11.2. Informative References . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
The IETF ROLL Working Group has defined application-specific routing The IETF ROLL Working Group has defined application-specific routing
requirements for a Low Power and Lossy Network (LLN) routing requirements for a Low Power and Lossy Network (LLN) routing
protocol, specified in [I-D.ietf-roll-building-routing-reqs], protocol, specified in [I-D.ietf-roll-building-routing-reqs],
[I-D.ietf-roll-home-routing-reqs], [RFC5673], and [RFC5548]. [I-D.ietf-roll-home-routing-reqs], [RFC5673], and [RFC5548].
Considering the wide variety of use cases, link types and metrics, Considering the wide variety of use cases, link types and metrics,
the Routing Protocol for Low Power and Lossy Networks the Routing Protocol for Low Power and Lossy Networks
skipping to change at page 3, line 32 skipping to change at page 3, line 32
problem to be addressed by that instance. problem to be addressed by that instance.
the Objective Function selects the DODAG iteration that a device the Objective Function selects the DODAG iteration that a device
joins, and a number of neighbor routers within that iteration as joins, and a number of neighbor routers within that iteration as
parents and siblings. The OF is also responsible for computing the parents and siblings. The OF is also responsible for computing the
Rank of the device, that abstracts a relative position within 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 DODAG and is used by the RPL core to enable a degree of loop
avoidance and verify forward progression towards a destination, as avoidance and verify forward progression towards a destination, as
specified in [I-D.ietf-roll-rpl]. specified in [I-D.ietf-roll-rpl].
This document defines the Objective Function 0 (OF0), which operates This specification defines the Objective Function 0 (OF0), that
on information defined in the RPL specification [I-D.ietf-roll-rpl] corresponds to the Objective Code Point 0. OF0 does not leverage
and does not require any additional option. link layer metrics such as described in the metrics draft
[I-D.ietf-roll-routing-metrics], but is only based on abstract
information from the DIO base container, such as Rank and an
administrative preference, that is transported in DIOs as
DODAGPreference in [I-D.ietf-roll-rpl].
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].
3. Basic Objective Function 3. Goal
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
[I-D.ietf-roll-routing-metrics], but is only based on abstract
information from the DIO base container, such as Rank and
administrative preference.
3.1. Goal
The Goal of the OF0 is to join a DODAG iteration that offers 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 connectivity to a specific set of nodes or to a larger routing
infrastructure. For the purpose of OF0, Grounded thus means that the infrastructure. For the purpose of OF0, Grounded thus means that the
root provides such connectivity. How that connectivity is asserted root provides such connectivity. How that connectivity is asserted
and maintained is out of scope. 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.
In the absence of a Grounded root, LLN inner connectivity is still In the absence of a Grounded root, LLN inner connectivity is still
desirable and floating DAGs will form, rooted at the nodes with the desirable and floating DAGs will form, rooted at the nodes with the
skipping to change at page 4, line 27 skipping to change at page 4, line 21
The metric used in OF0 is the RPL Rank, as defined in The metric used in OF0 is the RPL Rank, as defined in
[I-D.ietf-roll-rpl]. Using a metric that in essence is similar to [I-D.ietf-roll-rpl]. Using a metric that in essence is similar to
hop count implies that the quality of the connectivity should be hop count implies that the quality of the connectivity should be
asserted so that only neighbors with a good enough connectivity are asserted so that only neighbors with a good enough connectivity are
presented to the OF. How that connectivity is asserted and presented to the OF. How that connectivity is asserted and
maintained is out of scope. maintained is out of scope.
The default step of Rank is DEFAULT_RANK_INCREMENT for each hop. An The default step of Rank is DEFAULT_RANK_INCREMENT for each hop. An
implementation MAY allow a step between MINIMUM_RANK_INCREMENT and implementation MAY allow a step between MINIMUM_RANK_INCREMENT and
MAXIMUM_RANK_INCREMENT to reflect a large variation of link quality. MAXIMUM_RANK_INCREMENT to reflect a large variation of link quality
by units of MINIMUM_RANK_INCREMENT. In other words, the least
significant octet in the Rank is not used.
It MAY stretch its step of Rank by up to MAXIMUM_RANK_STRETCH in 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 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 available. For instance, say that a node computes a step of Rank of
4 units of MINIMUM_RANK_INCREMENT from a preferred parent with a Rank 4 units of MINIMUM_RANK_INCREMENT from a preferred parent with a Rank
of 6 units resulting in a Rank of 10 units for this node. Say that of 6 units resulting in a Rank of 10 units for this node. Say that
with that Rank of 10 units, this node would end up with only one with that Rank of 10 units, this node would end up with only one
parent and no sibling, though there is a neighbor with a Rank of 12 parent and no sibling, though there is a neighbor with a Rank of 12
units. In that case, the node is entitled to stretch its step of units. In that case, the node is entitled to stretch its step of
Rank by a value of 2 units, thus using a step of Rank of 6 units so Rank by a value of 2 units, thus using a step of Rank of 6 units so
as to reach a Rank of 12 units and find a sibling. But the node is as to reach a Rank of 12 units and find a sibling. But the node is
not entitled to use a step of Rank larger than 6 units since that not entitled to use a step of Rank larger than 6 units since that
would be a greedy behavior that would deprive the neighbor of this 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 node of a successor. Also, if the neighbor had exposed a Rank of 16
units, the stretch of Rank from 10 to 16 units would have exceeded units, the stretch of Rank from 10 to 16 units would have exceeded
MAXIMUM_RANK_STRETCH of 4 units and thus the neighbor would not have MAXIMUM_RANK_STRETCH of 4 units and thus the neighbor would not have
been selectable even as a sibling. been selectable even as a sibling.
Optionally, the administrative preference of a root MAY be configured Optionally, the administrative preference of a root MAY be configured
to supercede the goal to reach Grounded root. In that case, nodes to supercede the goal to reach Grounded root. 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 a
same multitude of DODAGs, such a configuration may result in possibly same multitude of DODAGs, such a configuration may result in possibly
less but larger DODAGs, as many as roots configured with the highest less but larger DODAGs, as many as roots configured with the highest
priority in the reachable vincinity. priority in the reachable vincinity.
OF0 selects a preferred parent and a backup next_hop if one is 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 available. The backup next_hop might be a parent or a sibling. All
the traffic is routed via the preferred parent. When the link the traffic is routed via the preferred parent. When the link
conditions do not let a packet through the preferred parent, the conditions do not let a packet through the preferred parent, the
packet is passed to the backup next_hop. packet is passed to the backup next_hop.
3.2. Selection of the Preferred Parent 4. 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] spells out the generic rules for a node to 1. [I-D.ietf-roll-rpl] spells out the generic rules for a node to
reparent and in particular the boundaries to augment its Rank reparent and in particular the boundaries to augment its Rank
within a DODAG iteration. A candidate that would not satisfy within a DODAG iteration. A candidate that would not satisfy
those rules MUST NOT be considered. 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
skipping to change at page 6, line 13 skipping to change at page 6, line 13
parent. parent.
9. The DODAG iteration that was in use already SHOULD be preferred. 9. The DODAG iteration that was in use already SHOULD be preferred.
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.
3.3. Selection of the Backup next_hop 5. Selection of the Backup next_hop
o When multiple interfaces are available, a router on a higher order o When multiple interfaces are available, a router on a higher order
interface is preferable. interface is preferable.
o The preferred parent MUST be ignored. o The preferred parent MUST be ignored.
o A Router that is not in the same DODAG as the preferred parent, o A Router that is not in the same DODAG as the preferred parent,
either in the current or a subsequent iteration, MUST be ignored. either in the current or a subsequent iteration, MUST be ignored.
o A Router with a Rank that is higher than the Rank computed for o A Router with a Rank that is higher than the Rank computed for
skipping to change at page 6, line 35 skipping to change at page 6, line 35
parent, to avoid greedy behaviors. It MAY still be selected as parent, to avoid greedy behaviors. It MAY still be selected as
sibling if no better Back-up next hop is found. sibling if no better Back-up next hop is found.
o A router with a lesser Rank SHOULD be preferred. o A router with a lesser Rank SHOULD be preferred.
o A router that has been validated as usable by an implementation o A router that has been validated as usable by an implementation
dependant validation process SHOULD be preferred. dependant validation process SHOULD be preferred.
o The backup next_hop that was in use already SHOULD be preferred. o The backup next_hop that was in use already SHOULD be preferred.
4. OF0 Constants and Variables 6. Abstract Interface with RPL core
Objective Function 0 interacts with the core RPL in the following
ways:
Processing DIO: This core RPL triggers the OF when a new DIO was
received. OF0 analyses the information in the DIO and may
select the source as a parent or sibling.
Providing DAG information The OF0 support can be required to provide
the DAG information for a given instance to the RPL core.
This includes the material that is contained in a DIO base
header.
Providing a Parent List The OF0 support can be required to provide
the list of the parents for a given instance to the RPL
core. This includes the material that is contained in the
transit option for that parent.
Trigger The OF0 support may trigger the RPL core to inform it that
a change occurred. This indicates whether the change
requires a new DIO to be fired, trickle timers to be
reset, etc...
7. OF0 Constants and Variables
OF0 uses the following constants: OF0 uses the following constants:
MinHopRankIncrease: 256 MinHopRankIncrease: 256
DEFAULT_RANK_INCREMENT: 4 * MinHopRankIncrease DEFAULT_RANK_INCREMENT: 4 * MinHopRankIncrease
MINIMUM_RANK_INCREMENT: 1 * MinHopRankIncrease MINIMUM_RANK_INCREMENT: 1 * MinHopRankIncrease
MAXIMUM_RANK_INCREMENT: 16 * MinHopRankIncrease MAXIMUM_RANK_INCREMENT: 16 * MinHopRankIncrease
MAXIMUM_RANK_STRETCH: 4 * MinHopRankIncrease MAXIMUM_RANK_STRETCH: 4 * MinHopRankIncrease
5. IANA Considerations 8. IANA Considerations
IThis specification requires the assignment of an OCP for OF0. The IThis specification requires the assignment of an OCP for OF0. The
value of 0 is suggested. value of 0 is suggested.
6. Security Considerations 9. Security Considerations
Security Considerations for OCP/OF are to be developed in accordance Security Considerations for OCP/OF are to be developed in accordance
with recommendations laid out in, for example, with recommendations laid out in, for example,
[I-D.tsao-roll-security-framework]. [I-D.tsao-roll-security-framework].
7. Acknowledgements 10. Acknowledgements
Most specific thanks to Tim Winter, JP Vasseur, Julien Abeille and Most specific thanks to Tim Winter, JP Vasseur, Julien Abeille and
Mathilde Durvy for in-depth review and first hand implementer's Mathilde Durvy for in-depth review and first hand implementer's
feedback. feedback.
8. References 11. References
11.1. Normative References
8.1. Normative References
[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.
8.2. Informative References 11.2. Informative References
[I-D.ietf-roll-building-routing-reqs] [I-D.ietf-roll-building-routing-reqs]
Martocci, J., Riou, N., Mil, P., and W. Vermeylen, Martocci, J., Riou, N., Mil, P., and W. Vermeylen,
"Building Automation Routing Requirements in Low Power and "Building Automation Routing Requirements in Low Power and
Lossy Networks", draft-ietf-roll-building-routing-reqs-07 Lossy Networks", draft-ietf-roll-building-routing-reqs-07
(work in progress), September 2009. (work in progress), September 2009.
[I-D.ietf-roll-home-routing-reqs] [I-D.ietf-roll-home-routing-reqs]
Brandt, A., Buron, J., and G. Porcu, "Home Automation Brandt, A., Buron, J., and G. Porcu, "Home Automation
Routing Requirements in Low Power and Lossy Networks", Routing Requirements in Low Power and Lossy Networks",
draft-ietf-roll-home-routing-reqs-08 (work in progress), draft-ietf-roll-home-routing-reqs-08 (work in progress),
September 2009. September 2009.
[I-D.ietf-roll-routing-metrics] [I-D.ietf-roll-routing-metrics]
Vasseur, J. and D. Networks, "Routing Metrics used for Vasseur, J., Kim, M., Networks, D., and H. Chong, "Routing
Path Calculation in Low Power and Lossy Networks", Metrics used for Path Calculation in Low Power and Lossy
draft-ietf-roll-routing-metrics-04 (work in progress), Networks", draft-ietf-roll-routing-metrics-06 (work in
December 2009. progress), April 2010.
[I-D.ietf-roll-rpl] [I-D.ietf-roll-rpl]
Winter, T., Thubert, P., and R. Team, "RPL: IPv6 Routing Winter, T., Thubert, P., and R. Team, "RPL: IPv6 Routing
Protocol for Low power and Lossy Networks", Protocol for Low power and Lossy Networks",
draft-ietf-roll-rpl-06 (work in progress), February 2010. draft-ietf-roll-rpl-08 (work in progress), May 2010.
[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-02 (work in Networks", draft-ietf-roll-terminology-03 (work in
progress), October 2009. progress), March 2010.
[I-D.tsao-roll-security-framework] [I-D.tsao-roll-security-framework]
Tsao, T., Alexander, R., Dohler, M., Daza, V., and A. Tsao, T., Alexander, R., Daza, V., and A. Lozano, "A
Lozano, "A Security Framework for Routing over Low Power Security Framework for Routing over Low Power and Lossy
and Lossy Networks", draft-tsao-roll-security-framework-01 Networks", draft-tsao-roll-security-framework-02 (work in
(work in progress), September 2009. progress), March 2010.
[RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel, [RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel,
"Routing Requirements for Urban Low-Power and Lossy "Routing Requirements for Urban Low-Power and Lossy
Networks", RFC 5548, May 2009. Networks", RFC 5548, May 2009.
[RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney, [RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney,
"Industrial Routing Requirements in Low-Power and Lossy "Industrial Routing Requirements in Low-Power and Lossy
Networks", RFC 5673, October 2009. Networks", RFC 5673, October 2009.
Author's Address Author's Address
 End of changes. 23 change blocks. 
63 lines changed or deleted 78 lines changed or added

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