Skip to main content

16. Summary of Requirements for Interoperable Implementations

This section summarizes basic interoperability and references normative text for RPL implementations operating in one of three major modes. Implementations are expected to support either no Downward routes, Non-Storing mode only, or Storing mode only. A fourth mode, operation as a leaf, is also possible.

Implementations conforming to this specification may contain different subsets of capabilities as appropriate to the application scenario. It is important for the implementer to support a level of interoperability consistent with that required by the application scenario. To this end, further guidance may be provided beyond this specification (e.g., as applicability statements), and it is understood that in some cases such further guidance may override portions of this specification.

16.1. Common Requirements​

In a general case, the greatest level of interoperability may be achieved when all of the nodes in a RPL LLN are cooperating to use the same MOP, OF, metrics, and constraints, and are thus able to act as RPL routers. When a node is not capable of being a RPL router, it may be possible to interoperate in a more limited manner as a RPL leaf.

All RPL implementations need to support the use of RPL Packet Information transported within data packets (Section 11.2). One such mechanism is described in [RFC6553].

RPL implementations will need to support the use of Neighbor Unreachability Detection (NUD), or an equivalent mechanism, to maintain the reachability of neighboring RPL nodes (Section 8.2.1). Alternate mechanisms may be optimized to the constrained capabilities of the implementation, such as hints from the link layer.

This specification provides means to obtain a PIO and thus form an IPv6 address. When that mechanism is used, it may be necessary to perform address resolution and duplicate address detection through an external process, such as IPv6 ND [RFC4861] or 6LoWPAN ND [6LOWPAN-ND].

16.2. Operation as a RPL Leaf Node (Only)​

  • An implementation of a leaf node (only) does not ever participate as a RPL router. Interoperable implementations of leaf nodes behave as summarized in Section 8.5.

  • Support of a particular MOP encoding is not required, although if the leaf node sends DAO messages to set up Downward routes, the leaf node should do so in a manner consistent with the mode of operation indicated by the MOP.

  • Support of a particular OF is not required.

  • In summary, a leaf node does not generally issue DIO messages, it may issue DAO and DIS messages. A leaf node accepts DIO messages though it generally ignores DAO and DIS messages.

16.3. Operation as a RPL Router​

If further guidance is not available then a RPL router implementation MUST at least support the metric-less OF0 [RFC6552].

For consistent operation a RPL router implementation needs to support the MOP in use by the DODAG.

All RPL routers will need to implement Trickle [RFC6206].

16.3.1. Support for Upward Routes (Only)​

An implementation of a RPL router that supports only Upward routes supports the following:

  • Upward routes (Section 8)

  • MOP encoding 0 (Section 20.3)

  • In summary, DIO and DIS messages are issued, and DAO messages are not issued. DIO and DIS messages are accepted, and DAO messages are ignored.

16.3.2. Support for Upward Routes and Downward Routes in Non-Storing Mode​

An implementation of a RPL router that supports Upward routes and Downward routes in Non-Storing mode supports the following:

  • Upward routes (Section 8)

  • Downward routes (Non-Storing) (Section 9)

  • MOP encoding 1 (Section 20.3)

  • Source-routed Downward traffic ([RFC6554])

  • In summary, DIO and DIS messages are issued, and DAO messages are issued to the DODAG root. DIO and DIS messages are accepted, and DAO messages are ignored by nodes other than DODAG roots. Multicast is not supported through the means described in this specification, though it may be supported through some alternate means.

16.3.3. Support for Upward Routes and Downward Routes in Storing Mode​

An implementation of a RPL router that supports Upward routes and Downward routes in Storing mode supports the following:

  • Upward routes (Section 8)

  • Downward routes (Storing) (Section 9)

  • MOP encoding 2 (Section 20.3)

  • In summary, DIO, DIS, and DAO messages are issued. DIO, DIS, and DAO messages are accepted. Multicast is not supported through the means described in this specification, though it may be supported through some alternate means.

16.3.3.1. Optional Support for Basic Multicast Scheme​

A Storing mode implementation may be enhanced with basic multicast support through the following additions:

  • Basic Multicast Support (Section 12)

  • MOP encoding 3 (Section 20.3)

16.4. Items for Future Specification​

A number of items are left to future specification, including but not limited to the following:

  • How to attach a non-RPL node such as an IPv6 host, e.g., to consistently distribute at least PIO material to the attached node.

  • How to obtain authentication material in support if authenticated mode is used (Section 10.3).

  • Details of operation over multiple simultaneous instances.

  • Advanced configuration mechanisms, such as the provisioning of RPLInstanceIDs, parameterization of Objective Functions, and parameters to control security. (It is expected that such mechanisms might extend the DIO as a means to disseminate information across the DODAG).

Last updated on