Skip to main content

18. Manageability Considerations

The aim of this section is to give consideration to the manageability of RPL, and how RPL will be operated in an LLN. The scope of this section is to consider the following aspects of manageability: configuration, monitoring, fault management, accounting, and performance of the protocol in light of the recommendations set forth in [RFC5706].

18.1. Introduction​

Most of the existing IETF management standards are MIB modules (data models based on the Structure of Management Information (SMI)) to monitor and manage networking devices.

For a number of protocols, the IETF community has used the IETF Standard Management Framework, including the Simple Network Management Protocol [RFC3410], the Structure of Management Information [RFC2578], and MIB data models for managing new protocols.

As pointed out in [RFC5706], the common policy in terms of operation and management has been expanded to a policy that is more open to a set of tools and management protocols rather than strictly relying on a single protocol such as SNMP.

In 2003, the Internet Architecture Board (IAB) held a workshop on Network Management [RFC3535] that discussed the strengths and weaknesses of some IETF network management protocols and compared them to operational needs, especially configuration.

One issue discussed was the user-unfriendliness of the binary format of SNMP [RFC3410]. In the case of LLNs, it must be noted that at the time of writing, the CoRE working group is actively working on resource management of devices in LLNs. Still, it is felt that this section provides important guidance on how RPL should be deployed, operated, and managed.

As stated in [RFC5706]:

A management information model should include a discussion of what is manageable, which aspects of the protocol need to be configured, what types of operations are allowed, what protocol-specific events might occur, which events can be counted, and for which events an operator should be notified.

These aspects are discussed in detail in the following sections.

RPL will be used on a variety of devices that may have resources such as memory varying from a few kilobytes to several hundreds of kilobytes and even megabytes. When memory is highly constrained, it may not be possible to satisfy all the requirements listed in this section. Still it is worth listing all of these in an exhaustive fashion, and implementers will then determine which of these requirements could be satisfied according to the available resources on the device.

18.2. Configuration Management​

This section discusses the configuration management, listing the protocol parameters for which configuration management is relevant.

Some of the RPL parameters are optional. The requirements for configuration are only applicable for the options that are used.

18.2.1. Initialization Mode​

"Architectural Principles of the Internet" [RFC1958], Section 3.8, states: "Avoid options and parameters whenever possible. Any options and parameters should be configured or negotiated dynamically rather than manually". This is especially true in LLNs where the number of devices may be large and manual configuration is infeasible. This has been taken into account in the design of RPL whereby the DODAG root provides a number of parameters to the devices joining the DODAG, thus avoiding cumbersome configuration on the routers and potential sources of misconfiguration (e.g., values of Trickle timers, etc.). Still, there are additional RPL parameters that a RPL implementation should allow to be configured, which are discussed in this section.

18.2.1.1. DIS Mode of Operation upon Boot-Up​

When a node is first powered up:

  1. The node may decide to stay silent, waiting to receive DIO messages from DODAG of interest (advertising a supported OF and metrics/constraints) and not send any multicast DIO messages until it has joined a DODAG.

  2. The node may decide to send one or more DIS messages (optionally, requesting DIO for a specific DODAG) as an initial probe for nearby DODAGs, and in the absence of DIO messages in reply after some configurable period of time, the node may decide to root a floating DODAG and start sending multicast DIO messages.

A RPL implementation SHOULD allow configuring the preferred mode of operation listed above along with the required parameters (in the second mode: the number of DIS messages and related timer).

18.2.2. DIO and DAO Base Message and Options Configuration​

RPL specifies a number of protocol parameters considering the large spectrum of applications where it will be used. That said, particular attention has been given to limiting the number of these parameters that must be configured on each RPL router. Instead, a number of the default values can be used, and when required these parameters can be provided by the DODAG root thus allowing for dynamic parameter setting.

A RPL implementation SHOULD allow configuring the following routing protocol parameters. As pointed out above, note that a large set of parameters is configured on the DODAG root.

18.2.3. Protocol Parameters to Be Configured on Every Router in the LLN​

A RPL implementation MUST allow configuring the following RPL parameters:

  • RPLInstanceID [DIO message, in DIO Base message]. Although the RPLInstanceID must be configured on the DODAG root, it must also be configured as a policy on every node in order to determine whether or not the node should join a particular DODAG. Note that a second RPLInstanceID can be configured on the node, should it become root of a floating DODAG.

  • List of supported Objective Code Points (OCPs)

  • List of supported metrics: [RFC6551] specifies a number of metrics and constraints used for the DODAG formation. Thus, a RPL implementation should allow configuring the list of metrics that a node can accept and understand. If a DIO is received with a metric and/or constraint that is not understood or supported, as specified in Section 8.5, the node would join as a leaf node.

  • Prefix Information, along with valid and preferred lifetime and the 'L' and 'A' flags. [DIO message, Prefix Information Option]. A RPL implementation SHOULD allow configuring if the Prefix Information option must be carried with the DIO message to distribute the Prefix Information for autoconfiguration. In that case, the RPL implementation MUST allow the list of prefixes to be advertised in the PIO along with the corresponding flags.

  • Solicited Information [DIS message, in Solicited Information option]. Note that a RPL implementation SHOULD allow configuring when such messages should be sent and under which circumstances, along with the value of the RPLInstance ID, 'V'/'I'/'D' flags.

  • 'K' flag: when a node should set the 'K' flag in a DAO message [DAO message, in DAO Base message].

  • MOP (Mode of Operation) [DIO message, in DIO Base message].

  • Route Information (and preference) [DIO message, in Route Information option]

18.2.4. Protocol Parameters to Be Configured on Every Non-DODAG-Root Router in the LLN​

A RPL implementation MUST allow configuring the Target prefix [DAO message, in RPL Target option].

Furthermore, there are circumstances where a node may want to designate a Target to allow for specific processing of the Target (prioritization, etc.). Such processing rules are out of scope for this specification. When used, a RPL implementation SHOULD allow configuring the Target Descriptor on a per-Target basis (for example, using access lists).

A node whose DODAG parent set is empty may become the DODAG root of a floating DODAG. It may also set its DAGPreference such that it is less preferred. Thus, a RPL implementation MUST allow configuring the set of actions that the node should initiate in this case:

  • Start its own (floating) DODAG: the new DODAGID must be configured in addition to its DAGPreference.

  • Poison the broken path (see procedure in Section 8.2.2.5).

  • Trigger a local repair.

18.2.5. Parameters to Be Configured on the DODAG Root​

In addition, several other parameters are configured only on the DODAG root and advertised in options carried in DIO messages.

As specified in Section 8.3, a RPL implementation makes use of Trickle timers to govern the sending of DIO messages. The operation of the Trickle algorithm is determined by a set of configurable parameters, which MUST be configurable and that are then advertised by the DODAG root along the DODAG in DIO messages.

  • DIOIntervalDoublings [DIO message, in DODAG Configuration option]

  • DIOIntervalMin [DIO message, in DODAG Configuration option]

  • DIORedundancyConstant [DIO message, in DODAG Configuration option]

In addition, a RPL implementation SHOULD allow for configuring the following set of RPL parameters:

  • Path Control Size [DIO message, in DODAG Configuration option]

  • MinHopRankIncrease [DIO message, in DODAG Configuration option]

  • The DODAGPreference field [DIO message, DIO Base object]

  • DODAGID [DIO message, in DIO Base option] and [DAO message, when the 'D' flag of the DAO message is set]

DAG root behavior: in some cases, a node may not want to permanently act as a floating DODAG root if it cannot join a grounded DODAG. For example, a battery-operated node may not want to act as a floating DODAG root for a long period of time. Thus, a RPL implementation MAY support the ability to configure whether or not a node could act as a floating DODAG root for a configured period of time.

DAG Version Number Increment: a RPL implementation may allow, by configuration at the DODAG root, refreshing the DODAG states by updating the DODAGVersionNumber. A RPL implementation SHOULD allow configuring whether or not periodic or event triggered mechanisms are used by the DODAG root to control DODAGVersionNumber change (which triggers a global repair as specified in Section 3.2.2).

DAO messages are optional and used in DODAGs that require Downward routing operation. This section deals with the set of parameters related to DAO messages and provides recommendations on their configuration.

As stated in Section 9.5, it is recommended to delay the sending of DAO message to DAO parents in order to maximize the chances to perform route aggregation. Upon receiving a DAO message, the node should thus start a DelayDAO timer. The default value is DEFAULT_DAO_DELAY. A RPL implementation MAY allow for configuring the DelayDAO timer.

In a Storing mode of operation, a storing node may increment DTSN in order to reliably trigger a set of DAO updates from its immediate children, as part of routine routing table updates and maintenance. A RPL implementation MAY allow for configuring a set of rules specifying the triggers for DTSN increment (manual or event-based).

When a DAO entry times out or is invalidated, a node SHOULD make a reasonable attempt to report a No-Path to each of the DAO parents. That number of attempts MAY be configurable.

An implementation should support rate-limiting the sending of DAO messages. The related parameters MAY be configurable.

As described in Section 10, the security features described in this document are optional to implement and a given implementation may support a subset (including the empty set) of the described security features.

To this end, an implementation supporting described security features may conceptually implement a security policy database. In support of the security mechanisms, a RPL implementation SHOULD allow for configuring a subset of the following parameters:

  • Security Modes accepted [Unsecured mode, Preinstalled mode, Authenticated mode]

  • KIM values accepted [Secure RPL control messages, in Security section]

  • Level values accepted [Secure RPL control messages, in Security section]

  • Algorithm values accepted [Secure RPL control messages, in Security section]

  • Key material in support of Authenticated or Preinstalled key modes.

In addition, a RPL implementation SHOULD allow for configuring a DODAG root with a subset of the following parameters:

  • Level values advertised [Secure DIO message, in Security section]

  • KIM value advertised [Secure DIO message, in Security section]

  • Algorithm value advertised [Secure DIO message, in Security section]

18.2.8. Default Values​

This document specifies default values for the following set of RPL variables:

  • DEFAULT_PATH_CONTROL_SIZE
  • DEFAULT_DIO_INTERVAL_MIN
  • DEFAULT_DIO_INTERVAL_DOUBLINGS
  • DEFAULT_DIO_REDUNDANCY_CONSTANT
  • DEFAULT_MIN_HOP_RANK_INCREASE
  • DEFAULT_DAO_DELAY

It is recommended to specify default values in protocols; that being said, as discussed in [RFC5706], default values may make less and less sense. RPL is a routing protocol that is expected to be used in a number of contexts where network characteristics such as the number of nodes and link and node types are expected to vary significantly. Thus, these default values are likely to change with the context and as the technology evolves. Indeed, LLNs' related technology (e.g., hardware, link layers) have been evolving dramatically over the past few years and such technologies are expected to change and evolve considerably in the coming years.

The proposed values are not based on extensive best current practices and are considered to be conservative.

18.3. Monitoring of RPL Operation​

Several RPL parameters should be monitored to verify the correct operation of the routing protocol and the network itself. This section lists the set of monitoring parameters of interest.

18.3.1. Monitoring a DODAG Parameters​

A RPL implementation SHOULD provide information about the following parameters:

  • DODAG Version number [DIO message, in DIO Base message]

  • Status of the 'G' flag [DIO message, in DIO Base message]

  • Status of the MOP field [DIO message, in DIO Base message]

  • Value of the DTSN [DIO message, in DIO Base message]

  • Value of the Rank [DIO message, in DIO Base message]

  • DAOSequence: Incremented at each unique DAO message, echoed in the DAO-ACK message [DAO and DAO-ACK messages]

  • Route Information [DIO message, Route Information Option] (list of IPv6 prefixes per parent along with lifetime and preference]

  • Trickle parameters:

    • DIOIntervalDoublings [DIO message, in DODAG Configuration option]
    • DIOIntervalMin [DIO message, in DODAG Configuration option]
    • DIORedundancyConstant [DIO message, in DODAG Configuration option]

  • Path Control Size [DIO message, in DODAG Configuration option]

  • MinHopRankIncrease [DIO message, in DODAG Configuration option]

Values that may be monitored only on the DODAG root:

  • Transit Information [DAO, Transit Information option]: A RPL implementation SHOULD allow configuring whether the set of received Transit Information options should be displayed on the DODAG root. In this case, the RPL database of received Transit Information should also contain the Path Sequence, Path Control, Path Lifetime, and Parent Address.

18.3.2. Monitoring a DODAG Inconsistencies and Loop Detection​

Detection of DODAG inconsistencies is particularly critical in RPL networks. Thus, it is recommended for a RPL implementation to provide appropriate monitoring tools. A RPL implementation SHOULD provide a counter reporting the number of a times the node has detected an inconsistency with respect to a DODAG parent, e.g., if the DODAGID has changed.

When possible more granular information about inconsistency detection should be provided. A RPL implementation MAY provide counters reporting the number of following inconsistencies:

  • Packets received with 'O' bit set (to Down) from a node with a higher Rank

  • Packets received with 'O' bit cleared (to Up) from a node with a lower Rank

  • Number of packets with the 'F' bit set

  • Number of packets with the 'R' bit set

18.4. Monitoring of the RPL Data Structures​

18.4.1. Candidate Neighbor Data Structure​

A node in the candidate neighbor list is a node discovered by the same means and qualified to potentially become a parent (with high enough local confidence). A RPL implementation SHOULD provide a way to allow for the candidate neighbor list to be monitored with some metric reflecting local confidence (the degree of stability of the neighbors) as measured by some metrics.

A RPL implementation MAY provide a counter reporting the number of times a candidate neighbor has been ignored, should the number of candidate neighbors exceed the maximum authorized value.

18.4.2. Destination-Oriented Directed Acyclic Graph (DODAG) Table​

For each DODAG, a RPL implementation is expected to keep track of the following DODAG table values:

  • RPLInstanceID

  • DODAGID

  • DODAGVersionNumber

  • Rank

  • Objective Code Point

  • A set of DODAG parents

  • A set of prefixes offered Upward along the DODAG

  • Trickle timers used to govern the sending of DIO messages for the DODAG

  • List of DAO parents

  • DTSN

  • Node status (router versus leaf)

A RPL implementation SHOULD allow for monitoring the set of parameters listed above.

18.4.3. Routing Table and DAO Routing Entries​

A RPL implementation maintains several information elements related to the DODAG and the DAO entries (for storing nodes). In the case of a non-storing node, a limited amount of information is maintained (the routing table is mostly reduced to a set of DODAG parents along with characteristics of the DODAG as mentioned above); whereas in the case of storing nodes, this information is augmented with routing entries.

A RPL implementation SHOULD allow for the following parameters to be monitored:

  • Next Hop (DODAG parent)

  • Next Hop Interface

  • Path metrics value for each DODAG parent

A DAO Routing Table entry conceptually contains the following elements (for storing nodes only):

  • Advertising Neighbor Information

  • IPv6 address

  • Interface ID to which DAO parents has this entry been reported

  • Retry counter

  • Logical equivalent of DAO Content:

    • DAO-Sequence
    • Path Sequence
    • DAO Lifetime
    • DAO Path Control

  • Destination Prefix (or address or Mcast Group)

A RPL implementation SHOULD provide information about the state of each DAO Routing Table entry states.

18.5. Fault Management​

Fault management is a critical component used for troubleshooting, verification of the correct mode of operation of the protocol, and network design; also, it is a key component of network performance monitoring. A RPL implementation SHOULD allow the provision of the following information related to fault managements:

  • Memory overflow along with the cause (e.g., routing tables overflow, etc.)

  • Number of times a packet could not be sent to a DODAG parent flagged as valid

  • Number of times a packet has been received for which the router did not have a corresponding RPLInstanceID

  • Number of times a local repair procedure was triggered

  • Number of times a global repair was triggered by the DODAG root

  • Number of received malformed messages

  • Number of seconds with packets to forward and no next hop (DODAG parent)

  • Number of seconds without next hop (DODAG parent)

  • Number of times a node has joined a DODAG as a leaf because it received a DIO with a metric/constraint that was not understood and it was configured to join as a leaf node in this case (see Section 18.6)

It is RECOMMENDED to report faults via at least error log messages. Other protocols may be used to report such faults.

18.6. Policy​

Policy rules can be used by a RPL implementation to determine whether or not the node is allowed to join a particular DODAG advertised by a neighbor by means of DIO messages.

This document specifies operation within a single DODAG. A DODAG is characterized by the following tuple (RPLInstanceID, DODAGID). Furthermore, as pointed out above, DIO messages are used to advertise other DODAG characteristics such as the routing metrics and constraints used to build to the DODAG and the Objective Function in use (specified by OCP).

The first policy rules consist of specifying the following conditions that a RPL node must satisfy to join a DODAG:

  • RPLInstanceID

  • List of supported routing metrics and constraints

  • Objective Function (OCP values)

A RPL implementation MUST allow configuring these parameters and SHOULD specify whether the node must simply ignore the DIO if the advertised DODAG is not compliant with the local policy or whether the node should join as the leaf node if only the list of supported routing metrics and constraints, and the OF is not supported. Additionally, a RPL implementation SHOULD allow for the addition of the DODAGID as part of the policy.

A RPL implementation SHOULD allow configuring the set of acceptable or preferred Objective Functions (OFs) referenced by their Objective Code Points (OCPs) for a node to join a DODAG, and what action should be taken if none of a node's candidate neighbors advertise one of the configured allowable Objective Functions, or if the advertised metrics/constraint is not understood/supported. Two actions can be taken in this case:

  • The node joins the DODAG as a leaf node as specified in Section 8.5.

  • The node does not join the DODAG.

A node in an LLN may learn routing information from different routing protocols including RPL. In this case, it is desirable to control, via administrative preference, which route should be favored. An implementation SHOULD allow for the specification of an administrative preference for the routing protocol from which the route was learned.

Internal Data Structures: some RPL implementations may limit the size of the candidate neighbor list in order to bound the memory usage; in which case, some otherwise viable candidate neighbors may not be considered and simply dropped from the candidate neighbor list.

A RPL implementation MAY provide an indicator on the size of the candidate neighbor list.

18.7. Fault Isolation​

It is RECOMMENDED to quarantine neighbors that start emitting malformed messages at unacceptable rates.

18.8. Impact on Other Protocols​

RPL has very limited impact on other protocols. Where more than one routing protocol is required on a router, such as an LBR, it is expected for the device to support routing redistribution functions between the routing protocols to allow for reachability between the two routing domains. Such redistribution SHOULD be governed by the use of user configurable policy.

With regard to the impact in terms of traffic on the network, RPL has been designed to limit the control traffic thanks to mechanisms such as Trickle timers (Section 8.3). Thus, the impact of RPL on other protocols should be extremely limited.

18.9. Performance Management​

Performance management is always an important aspect of a protocol, and RPL is not an exception. Several metrics of interest have been specified by the IP Performance Monitoring (IPPM) working group: that being said, they will be hardly applicable to LLN considering the cost of monitoring these metrics in terms of resources on the devices and required bandwidth. Still, RPL implementations MAY support some of these, and other parameters of interest are listed below:

  • Number of repairs and time to repair in seconds (average, variance)

  • Number of times and time period during which a devices could not forward a packet because of a lack of a reachable neighbor in its routing table

  • Monitoring of resources consumption by RPL in terms of bandwidth and required memory

  • Number of RPL control messages sent and received

18.10. Diagnostics​

There may be situations where a node should be placed in "verbose" mode to improve diagnostics. Thus, a RPL implementation SHOULD provide the ability to place a node in and out of verbose mode in order to get additional diagnostic information.

Last updated on