7. Less-Constrained Variations

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

7.  Less-Constrained Variations

7.1.  Storing Mode Main DODAG

   This specification expects that the main DODAG is operated in Non-
   Storing Mode.  The reasons for that limitation are mostly related to
   LLN operations, power, and spectrum conservation:

   *  In Non-Storing Mode, the Root already knows the DODAG topology, so
      the additional topological information is reduced to the siblings.

   *  The downward routes are updated with unicast messages to the Root,
      which ensures that the Root can reach back to the LLN nodes after
      a repair faster than in the case of Storing Mode.  Also, the Root
      can control the use of path diversity in the DODAG to reach the
      LLN nodes.  For both reasons, Non-Storing Mode provides better
      capabilities for the Root to maintain the P-Routes.

   *  When the main DODAG is operated in Non-Storing Mode, P-Routes
      enable loose source routing, which is only an advantage in that
      mode.  Storing Mode does not use Source Routing Headers and does
      not derive the same benefits from this capability.

   On the other hand, since RPL is a Layer 3 routing protocol, its
   applicability extends beyond LLNs to a generic IP network.  RPL
   requires fewer resources than alternative IGPs such as OSPF, IS-IS,
   the Enhanced Interior Gateway Routing Protocol (EIGRP), BABEL, or RIP
   when using routing stretch rather than the shortest path routes to a
   destination that those protocols compute.  P-Routes add the
   capability to install the shortest and/or constrained routes to
   special destinations as discussed in Appendix A.9.4 of "An Autonomic
   Control Plane (ACP)" [RFC8994].

   In a powered and wired network, when enough memory to store the
   needed routes is available, the RPL Storing Mode proposes a better
   trade-off than the Non-Storing Mode, as it reduces the routing
   stretch and lowers the load on the Root.  In that case, the control
   path between the Root and the RPL nodes can be maintained more
   aggressively and with more redundancy than in LLNs, and the nodes can
   be reached to maintain the P-Routes at most times for a finer and
   more reactive control.

   This section specifies the additions that are needed to support
   P-Routes when the main DODAG is operated in Storing Mode.  As long as
   the RPI can be processed adequately by the data plane, the changes in
   this specification are limited to the DAO message.  The Track
   structure, routes, and forwarding operations remain the same.  Since
   there is no capability negotiation, the expectation is that all the
   nodes in the network support this specification in the same fashion
   or are configured the same way through management.

   In Storing Mode, the Root misses the Child-to-Parent relationship
   that forms the main DODAG as well as the sibling information.  To
   provide that knowledge, the nodes in the network MUST send additional
   DAO messages that are unicast to the Root just like Non-Storing DAO
   messages are.

   In the DAO message, the originating router advertises a set of
   neighbor nodes using SIOs, regardless of the relative position in the
   DODAG of the advertised node versus this router.

   The DAO message MUST be formed as follows:

   *  The originating router is identified by the source address of the
      DAO.  That address MUST be the one that this router registers to
      the neighbor routers so the Root can correlate the DAOs from those
      routers when they advertise this router as their neighbor.  The
      DAO contains one or more sequences of one TIO and one or more
      SIOs.  There is no RPL Target Option so that the Root is not
      confused into adding a Storing Mode route to the Target.

   *  The TIO is formed as in Storing Mode, and the Parent Address is
      not present.  The Path Sequence and Path Lifetime fields are
      aligned with the values used in the Address Registration of the
      node(s) advertised in the SIO, as explained in Section 9.1 of
      [RFC9010].  Having similar values in all nodes allows factorizing
      the TIO for multiple SIOs as done in [RPL].

   *  The TIO is followed by one or more SIOs that provide an address
      (ULA or GUA) of the advertised neighbor node.

   However, the RPL routing information headers may not be supported on
   all types of routed network infrastructures, especially not in high-
   speed routers.  When the RPI is not supported in the data plane,
   there cannot be Local RPL Instances and RPL can only operate as a
   single topology (the main DODAG).  The RPL Instance is the one that
   runs the main DODAG, and the ingress node that encapsulates the RPL
   Instance is not the Root.  The routes along the Tracks are alternate
   routes to those available along the main DODAG.  They MAY conflict
   with routes to children and MUST take precedence in the routing
   table.  The Targets MUST be adjacent to the Track egress to avoid
   loops that may form if the packet is reinjected in the main DODAG.

7.2.  A Track as a Full DODAG

   This specification builds Tracks with parallel or interleaved
   protection paths as opposed to a more complex DODAG with
   interconnections at any place desirable.  The reason for that
   limitation is related to constrained node operations and the
   capability to store a large amount of topological information and
   compute complex paths:

   *  With this specification, the node in the LLN has no topological
      awareness and does not need to maintain dynamic information about
      the link quality and availability.

   *  The Root has complete topological information and statistical
      metrics that allow it, or its PCE, to perform a global
      optimization of all Tracks in its DODAG.  Based on that
      information, the Root computes the protection path and produces
      the source route paths.

   *  The node merely selects one of the proposed paths and applies the
      associated pre-computed Routing Header in the encapsulation.  This
      alleviates both the complexity of computing a path and the
      compressed form of the Routing Header.

   The RAW architecture [RAW-ARCH] actually expects the PLR at the Track
   ingress to react to changes in the forwarding conditions along the
   Track and reroute packets to maintain the required degree of
   reliability.  To achieve this, the PLR needs the full richness of a
   DODAG to form any path that could meet the SLO.

   This section specifies the additions that are needed to turn the
   Track into a full DODAG and enable the main Root to provide the
   necessary topological information to the Track ingress.  The
   expectation is that the PLR's metrics will be in a different order
   than the PCE's metrics because of the difference in the timescale
   between routing and forwarding; see more in [RAW-ARCH].  It follows
   that the PLR will learn the metrics it needs from an alternate
   source, e.g., OAM frames.

   To pass the topological information to the ingress, the Root uses a
   P-DAO message that contains sequences of Targets and TIOs that
   collectively represent the Track, expressed in the same fashion as in
   classical Non-Storing Mode.  The difference is that the Root is the
   source as opposed to the destination, and the Root can report
   information on many Targets, possibly the full Track, with one P-DAO.

   Note that the Path Sequence and Lifetime in the TIO are selected by
   the Root and that the Target/Transit information tuples in the P-DAO
   are not those received by the Root in the DAO messages about the said
   Targets.  The Track may follow sibling routes and does not need to be
   congruent with the main DODAG.