datatracker.ietf.org
Sign in
Version 5.3.0, 2014-04-12
Report a bug

RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks
draft-ietf-roll-rpl-19

Approval Announcement

Draft of message to be sent after approval:

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: RFC Editor <rfc-editor@rfc-editor.org>,
    roll mailing list <roll@ietf.org>,
    roll chair <roll-chairs@tools.ietf.org>
Subject: Protocol Action: 'RPL: IPv6 Routing Protocol for Low power and Lossy Networks' to Proposed Standard (draft-ietf-roll-rpl-19.txt)

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