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