The IESG has approved the following document: - 'RPL: IPv6 Routing Protocol for Low power and Lossy Networks' (draft-ietf-roll-rpl-19.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-rpl/ Technical Summary Low power and Lossy Networks (LLNs) are a class of network in which both the routers and their interconnects are constrained: LLN routers typically operate with constraints on (any subset of) processing power, memory and energy (battery), and their interconnects are characterized by (any subset of) high loss rates, low data rates and instability. LLNs are comprised of anything from a few dozen and up to thousands of routers, and support point-to-point traffic (between devices inside the LLN), point-to-multipoint traffic (from a central control point to a subset of devices inside the LLN) and multipoint- to-point traffic (from devices inside the LLN towards a central control point). The latter is especially common, as it represents all forms for sensor data acquisition and meter reading. The document specifies the IPv6 Routing Protocol for LLNs (RPL), which provides a mechanism whereby multipoint-to-point traffic from devices inside the LLN towards a central control point, as well as point-to- multipoint traffic from the central control point to the devices inside the LLN, is supported. Support for point-to-point traffic is also available. RPL was designed with the objective to meet the requirements spelled out in [RFC5867], [RFC5826], [RFC5673], and [RFC5548]. Working Group Summary Considering that there were a number of discussed items, several decisions had to be made that required WG consensus. All decisions were driven by good/excellent consensus. Very few decisions were made with only a rough consensus (extensions to carry MTU, SLLA options or support of siblings). That being said, the document has been written so as to allow for future extensions including the ones listed above, which was seen an acceptable approach. Considerable amounts of WG time were spent discussing the IPR claims associated with this document and there is WG consensus to proceed with the -11 version of this document considering the modifications made to the document since the IPR disclosures were filed and considering the license terms published. Document Quality Good. During the course of the design of this document, a number of implementations have been reported (more than 10) and two interoperability events took place under the control of the IPSO (IP for Smart Object) alliance and the Zigbee alliance. Interoperability results were shared on the ROLL WG mailing list, concerns have been addressed and all issues known so far have been fixed. Personnel David Culler (culler@eecs.berkeley.edu) is the Document Shepherd. Adrian Farrel (adrian.farrel@huawei.com) is the Responsible AD. RFC Editor Note Section 9.4 *Second* bullet list. Bullet 2 OLD If the 'L' flag is cleared, indicating a subnet operation, and the 'R' flag is set, indicating that the parent provides its own address in the PIO, then the parent MUST advertise that address as a DAO target. NEW If the 'L' flag is cleared and the 'R' flag is set, indicating that the parent provides its own address in the PIO, then the parent MUST advertise that address as a DAO target. END --- Section 6.7.10 New final paragraph in the section NEW If the only desired effect of a received PIO in a DIO is to provide the global address of the parent node to the receiving node then the sender resets the 'A' and 'L' bits and sets the 'R' bit. Upon receipt, the RPL will not autoconfigure an address or a connected route from the prefix [RFC4862]. As in all cases, when the 'L' bit is not set, the RPL node MAY include the prefix in PIOs it sends to its children. END --- Section 12, paragraph 1 OLD This section describes further a multicast routing operation over an IPv6 RPL network, and specifically how unicast DAOs can be used to relay group registrations up. The same DODAG construct can used to forward unicast and multicast traffic. The registration uses DAO messages that are identical to unicast except for the type of address that is transported. The main difference is that the multicast traffic going down is copied to all the children that have registered to the multicast group whereas unicast traffic is passed to one child only. NEW This section describes a multicast routing operation over an IPv6 RPL network, and specifically how unicast DAOs can be used to relay group registrations. The same DODAG construct can used to forward unicast and multicast traffic. This section is limited to a description of how group registrations may be exchanged and how the forwarding infrastructure operates. It does not provide a full description of multicast with in an LLN and, in particular, does not describe the generation of DODAGs specifically targeted at multicast nor the details of operating RPL for multicast - that will be the subject of further specifications. The multicast group registration uses DAO messages that are identical to unicast except for the type of address that is transported. The main difference is that the multicast traffic going down is copied to all the children that have registered to the multicast group whereas unicast traffic is passed to one child only. END _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
