1.1. Design Principles

RPL was designed with the objective to meet the requirements spelled out in [RFC5867], [RFC5826], [RFC5673], and [RFC5548].

A network may run multiple instances of RPL concurrently. Each such instance may serve different and potentially antagonistic constraints or performance criteria. This document defines how a single instance operates.

In order to be useful in a wide range of LLN application domains, RPL separates packet processing and forwarding from the routing optimization objective. Examples of such objectives include minimizing energy, minimizing latency, or satisfying constraints. This document describes the mode of operation of RPL. Other companion documents specify routing Objective Functions. A RPL implementation, in support of a particular LLN application, will include the necessary Objective Function(s) as required by the application.

RPL operations require bidirectional links. In some LLN scenarios, those links may exhibit asymmetric properties. It is required that the reachability of a router be verified before the router can be used as a parent. RPL expects an external mechanism to be triggered during the parent selection phase in order to verify link properties and neighbor reachability. Neighbor Unreachability Detection (NUD) is such a mechanism, but alternates are possible, including Bidirectional Forwarding Detection (BFD) [RFC5881] and hints from lower layers via Layer 2 (L2) triggers like [RFC5184]. In a general fashion, a detection mechanism that is reactive to traffic is favored in order to minimize the cost of monitoring links that are not being used.

RPL also expects an external mechanism to access and transport some control information, referred to as the "RPL Packet Information", in data packets. The RPL Packet Information is defined in Section 11.2 and enables the association of a data packet with a RPL Instance and the validation of RPL routing states. The RPL option [RFC6553] is an example of such mechanism. The mechanism is required for all packets except when strict source routing is used (that is for packets going Downward in Non-Storing mode as detailed further in Section 9), which by nature prevents endless loops and alleviates the need for the RPL Packet Information. Future companion specifications may propose alternate ways to carry the RPL Packet Information in the IPv6 packets and may extend the RPL Packet Information to support additional features.

RPL provides a mechanism to disseminate information over the dynamically formed network topology. This dissemination enables minimal configuration in the nodes, allowing nodes to operate mostly autonomously. This mechanism uses Trickle [RFC6206] to optimize the dissemination as described in Section 8.3.

In some applications, RPL assembles topologies of routers that own independent prefixes. Those prefixes may or may not be aggregatable depending on the origin of the routers. A prefix that is owned by a router is advertised as on-link.

RPL also introduces the capability to bind a subnet together with a common prefix and to route within that subnet. A source can inject information about the subnet to be disseminated by RPL, and that source is authoritative for that subnet. Because many LLN links have non-transitive properties, a common prefix that RPL disseminates over the subnet must not be advertised as on-link.

In particular, RPL may disseminate IPv6 Neighbor Discovery (ND) information such as the [RFC4861] Prefix Information Option (PIO) and the [RFC4191] Route Information Option (RIO). ND information that is disseminated by RPL conserves all its original semantics for router to host, with limited extensions for router to router, though it is not to be confused with routing advertisements and it is never to be directly redistributed in another routing protocol. A RPL node often combines host and router behaviors. As a host, it will process the options as specified in [RFC4191], [RFC4861], [RFC4862], and [RFC6275]. As a router, the RPL node may advertise the information from the options as required for the specific link, for instance, in an ND Router Advertisement (RA) message, though the exact operation is out of scope.

A set of companion documents to this specification will provide further guidance in the form of applicability statements specifying a set of operating points appropriate to the Building Automation, Home Automation, Industrial, and Urban application scenarios.