Technical Summary
The Routing Protocol for Low Power and Lossy Networks (RPL)
was designed as a generic core protocol that is agnostic to
metrics and that is adapted to a given problem using Objective
Functions (OF). This separation of Objective Functions from the core
protocol specification allows RPL to adapt to meet the different
optimization criteria required by the wide range of use cases.
RPL forms Destination Oriented Directed Acyclic Graphs (DODAGs)
within instances of the protocol. Each instance is associated with a
specialized Objective Function. A DODAG is periodically
reconstructed in a new Version to enable a global reoptimization of
the graph.
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 RPL to avoid
loops and verify forward progression towards a destination.
This document defines Objective Function 0 (OF0) which operates on
parameters that are obtained from provisionning, from the RPL DODAG
Configuration option, and from the RPL DIO base container.
OF0 is designed as a default OF that will allow interoperation
between implementations in a wide spectrum of use cases.
Working Group Summary
No discontent.
There has been some confusion about the WG process because of the
large number of revisions since the first WG last call. Here is the timeline:
> 01/05 New revision -05
> 02/22 WG last call on -05
> 03/13 On-list discussions of changes
> 03/13 New revision -06
> 03/13 New revision -07
> 03/14 WG last call on -07
> 03/16,, On-list discussions
> 03/30 New revision -08
> 04/05 New revision -09
> 04/11 Comment on list
> 04/11 New revision -10
> 04/21 Comment on list
> 05/05 Notice to list about changes
> 05/05 New revision -11
> 05/08 WG chair review posted to list
> 05/10 Comment on list
> 05/17 Notice to list about changes
> 05/17 New revision -12
> 05/18.. On-list discussion
> 05/24 Publication request
> 06/01 AD review posted to list
> 06/11 AD review :: Revised I-D needed
> 06/17 New revision -13
> 06/20 New revision -14
> 06/20 IETF Last Call
> 07/04 IETF Last Call ends
> 07/08 New revision -15
> 07/16 Ballot issued
> 08/09 IESG Discusses
> 08/09.. On-list discussions
> 08/11 IESG telechat
Thus: all changes as a result of comments made on the list. Plenty of explanation to
the list about what was changing and why.
A further poll of the WG will be carried out after changes to address IESG Discusses
Document Quality
The OF0 has been extensively discussed and reviewed by key contributors
of the Working Group. There are believed to be two implementations.
Personnel
JP Vasseur (jvasseur@cisco.com) is the Document Shepherd.
Adrian Farrel (adrian@olddog.co.uk) is the Responsible AD.
RFC Editor Note
Section 4.2.1
OLD
2. An implementation SHOULD validate a router prior to selecting it
as preferred as discussed in Section 3. The validation involves
layer 2 connectivity to the router, layer 3 connectivity offered
by the router, and may involve other factors such as policies.
In most cases, a router that does not succeed the validation
process cannot be further considered for selection as preferred
parent. In any case a router that succeeded that validation
process SHOULD be preferred.
NEW
2. Prior to selecting a router as the preferred parent, an
implementation SHOULD validate the connectivity and suitability
of the router as discussed in Section 3. This validation
involves checking the layer 2 connectivity to the router, the
layer 3 connectivity offered by the router, and may involve
examination of other factors such as locally or globally
configured policies.
In most cases, a router that does not succeed the validation
process cannot be further considered for selection as preferred
parent. In any case a router that succeeded that validation
process SHOULD be preferred over one that does not succeed.
END