1. Introduction

This section preserves the RFC text for RPL DAO Projection and root-initiated routing state, including P-DAO, P-DAO-ACK, P-DAO-REQ, PDR-ACK, VIO, SIO, RPI, SRH, Storing and Non-Storing P-Routes, Tracks, IANA registrations, and normative behavior.

Original RFC Text

1.  Introduction

   The Routing Protocol for Low-Power and Lossy Networks (RPL) [RPL], is
   a Distance Vector protocol that is well-suited for application in a
   variety of low-energy Internet of Things (IoT) networks where
   constrained nodes cannot maintain the full view of the topology and
   stretched paths are acceptable (as opposed to the signaling and state
   overhead involved in maintaining the shortest paths across).
   Additionally, RPL is anisotropic, meaning that its operation depends
   on the orientation of the links, down from or up towards the Root,
   with the default route advertised down and more-specific paths
   advertised up along a limited set of links.

   RPL forms Destination-Oriented Directed Acyclic Graphs (DODAGs) in
   which the Root often acts as the border router to connect the RPL
   domain to the IP backbone.  Routers inside the DODAG route along the
   graph up towards the Root for the default route and down towards
   destinations in the RPL domain for more-specific routes.  As a
   prerequisite, this specification expects a pre-existing RPL Instance
   with an associated DODAG and RPL Root, which are referred to as the
   main Instance, main DODAG, and main Root, respectively.  The main
   Instance is operated in RPL Non-Storing Mode of Operation (MOP).

   With this specification, an abstract routing function called a Path
   Computation Element (PCE) (e.g., located in a central controller or
   collocated with the main Root) interacts with the main Root to
   compute additional paths between nodes in the main Instance.  In Non-
   Storing Mode, the base topological information to be passed to the
   PCE, i.e., the knowledge of the main DODAG, is already available at
   the Root.  This specification introduces protocol extensions that
   enrich the topological information available to the Root with sibling
   relationships that are usable but not leveraged to form the main
   DODAG.

   Based on usage, path length, and knowledge of available resources
   such as battery levels and reservable buffers in the nodes, the PCE,
   which has a global visibility of the system, can optimize the
   computed routes for application needs, including the capability to
   provide path redundancy.  This specification also introduces protocol
   extensions that enable the Root to project (i.e., advertise from a
   remote location) the computed paths in the RPL domain as Projected
   Routes (a.k.a. P-Routes) on behalf of the PCE.

   A P-Route may be installed in either Storing or Non-Storing Mode,
   potentially resulting in hybrid situations where the Mode in which
   the P-Route operates is different from that of the RPL main Instance.
   P-Routes can be used as stand-alone segments meant to reduce the size
   of the Source Routing Headers (SRHs), leveraging loose source routing
   operations down the main RPL DODAG.  A P-Route can also be used as a
   protection path, and it can be combined and interleaved with other
   P-Routes to form a recovery graph called a Track.  A Track is
   signaled as a separate RPL Instance that is associated with a main
   RPL Instance such that the RPL routers that form the Track are also
   members of the main DODAG.  The Track provides underlay shortcuts
   using its own RIB, which is separate from the RIB of the main
   Instance and has a higher precedence.