The IESG has approved the following document: - 'Reactive Discovery of Point-to-Point Routes in Low Power and Lossy Networks' (draft-ietf-roll-p2p-rpl-17.txt) as Experimental RFC 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-p2p-rpl/ Technical Summary Targeting Low power and Lossy Networks (LLNs), the RPL routing protocol [RFC6550] provides paths along a Directed Acyclic Graph (DAG) rooted at a single router in the network. Establishment and maintenance of a DAG is performed by routers in the LLN using DODAG Information Object (DIO) messages. When two arbitrary routers (neither of which is the DAG's root) need to communicate, the data packets are restricted to travel only along the links in the DAG. Such point-to-point (P2P) routing functionality may not be sufficient for several Home and Building Automation applications [RFC5826] [RFC5867] due to the following reasons: o The need to pre-establish routes: each potential destination in the network must declare itself as such ahead of the time a source needs to reach it. o The need to route only along the links in the DAG: A DAG is built to optimize the routing cost to reach the root. Restricting P2P routes to use only the in-DAG links may result in significantly suboptimal routes and severe traffic congestion near the DAG root. This document describes an extension to core RPL that enables an IPv6 router in the LLN to discover routes to one or more IPv6 routers in the LLN "on demand", such that the discovered routes meet the specified metrics constraints, without necessarily going along the links in an existing DAG. This reactive P2P route discovery mechanism is henceforth referred to as P2P-RPL. P2P-RPL does not guarantee discovery of a route. Also, the discovered routes may not be optimal. However, any discovered routes are guaranteed to satisfy the desired constraints in terms of the routing metrics and are thus considered "good enough" from the application's perspective. A mechanism to measure the end-to-end cost of an existing route is specified in [I-D.ietf-roll-p2p-measurement]. As discussed in Section 4, measuring the end-to-end cost of an existing route may help decide whether to initiate the discovery of a better route using P2P-RPL and the metric constraints to be used for this purpose. Working Group Summary: No discontent. Once again, few comments, request for clarifications that have all been addressed in this revision. Document Quality: Yes there are several known implementations of these specification, with interop testing. An interoperability event was carried out Oct 2012 with INRIA's implementation against Sigma Design's implementation. The report can be found: http://hal.inria.fr/docs/00/66/16/29/PDF/RR-7864.pdf Experiments with P2P-RPL have also taken place on the Senslab testbed gathering boards based on MSP430 and 802.15.4 at 2.4GHz: http://hal.archives-ouvertes.fr/docs/00/65/16/03/PDF/SOFTCOM-2011.pdf Personnel: The Document Shepherd is JP Vasseur (jvasseur@cisco.com) The responsible AD is Adrian Farrel (adrian@olddog.co.uk) RFC Editor Note The reference to RFC 5226 may be removed. --- Section 6.1 New bullet on page 13. In the list of bullets under The DODAG Configuration Option, inside a P2P mode DIO MUST be set in the following manner: Add a new penultimate bullet as follows: o As discussed in Section 14, P2P-RPL does not distinguish between the "preinstalled" and "authenticated" security modes described in [RFC6550]. Consequently, the Origin MUST set the Authentication Enabled (A) flag to zero. A received P2P mode DIO MUST be discarded if the A flag inside the DODAG Configuration Option is not zero. --- Section 6.1 New bullet on page 14 In the list of bullets under A P2P mode DIO: Add a new bullet to the end of the list as follows: o MAY carry one DODAG Configuration Option. If a P2P mode DIO does not carry an explicit DODAG Configuration Option, the default DODAG Configuration Option defined in this section is considered to be in effect.
