The IESG has approved the following document: - 'RPL Objective Function Zero' (draft-ietf-roll-of0-20.txt) as a Proposed Standard This document is the product of the Routing Over Low power and Lossy networks Working Group. The IESG contact persons are Adrian Farrel and Stewart Bryant. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-roll-of0/ 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 _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
