8. Profiles

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

8.  Profiles

   This document provides a set of tools that may or may not be needed
   by an implementation depending on the type of application it serves.
   This section describes profiles that can be implemented separately,
   e.g., using only a portion of this specification to meet a particular
   use case, and can be used to discriminate what an implementation can
   and cannot do.

   Profiles 0 to 2 operate in the main Instance and do not require the
   support of Local RPL Instances or the indication of the RPL Instance
   in the data plane.  Profile 3 and above leverage Local RPL Instances
   to build arbitrary Tracks rooted at the Track ingress, using the
   namespace of the Track ingress for the TrackID.

   Profiles 0 and 1 are REQUIRED by all implementations that may be used
   in LLNs; Profile 1 leverages Storing Mode to reduce the size of the
   RPL Source Route Header in the most common LLN deployments.  Profile
   2 is RECOMMENDED in a high-speed (e.g., wired) environment to enable
   Traffic Engineering and network automation.  All the other profile/
   environment combinations are OPTIONAL.

   Profile 0:
      Profile 0 is the legacy support of [RPL] Non-Storing Mode, with
      default routing Northwards (up) and strict source routing
      Southwards (down the main DODAG).  It provides the minimal common
      functionality that must be implemented as a prerequisite to all
      the Track-supporting profiles.  The other profiles extend Profile
      0 with selected capabilities that this specification introduces.

   Profile 1 (Storing Mode P-Route segments along the main DODAG):
      Profile 1 does not create new paths; compared to Profile 0, it
      combines Storing and Non-Storing Modes to balance the size of the
      Routing Header in the packet and the amount of state in the
      intermediate routers in a Non-Storing Mode RPL DODAG.

   Profile 2 (Non-Storing Mode P-Route segments along the main
   DODAG):
      Profile 2 extends Profile 0 with strict source-routed Non-Storing
      Mode P-Routes along the main DODAG, which is the same as Profile 1
      but using NSM-VIOs as opposed to SM-VIOs.  Profile 2 provides the
      same capability to compress the SRH in packets down the main DODAG
      as Profile 1, but it requires an encapsulation in order to insert
      an additional SRH between the loose source routing hops.  With
      Profile 2, the Tracks MUST be installed as subTracks of the main
      DODAG, and the main Instance MUST be used as the TrackID.  Note
      that the ingress node encapsulates but is not the Root, as it does
      not own the DODAGID.

   Profile 3:
      In order to form the best path possible, this profile requires the
      support of an SIO to inform the Root of additional possible hops.
      Profile 3 extends Profile 1 with additional Storing Mode P-Routes
      that install segments that do not follow the main DODAG.  If the
      segment ingress (in the SM-VIO) is the same as the IPv6 address of
      the Track ingress (in the Projected DAO Base Object), the P-DAO
      creates an implicit Track between the segment ingress and the
      segment egress.

   Profile 4:
      Profile 4 extends Profile 2 with strict source-routed Non-Storing
      Mode P-Routes to form forward Tracks that are inside the main
      DODAG but do not necessarily follow it.  A Track is formed as one
      or more strict source-routed paths between the Root that is the
      Track ingress and the Track egress that is the last node.

   Profile 5:
      Profile 5 combines Profile 4 with Profile 1 and enables loose
      source routing between the ingress and the egress of the Track.
      As in Profile 1, Storing Mode P-Routes form the connections in the
      loose source route.

   Profile 6:
      Profile 6 combines Profile 4 with Profile 2 and enables loose
      source routing between the ingress and the egress of the Track.

   Profile 7:
      Profile 7 implements Profile 5 in a main DODAG that is operated in
      Storing Mode as presented in Section 7.1.  As in Profiles 1 and 2,
      the TrackID is the RPLInstanceID of the main DODAG.  Longest match
      rules decide whether a packet is sent along the main DODAG or
      rerouted in a Track.

   Profile 8:
      Profile 8 is offered in preparation of the RAW work and for use
      cases where an arbitrary node in the network can afford the same
      code complexity as the RPL Root in a traditional deployment.  It
      offers a full DODAG visibility to the Track ingress, as specified
      in Section 7.2, in a Non-Storing Mode main DODAG.

   Profile 9:
      Profile 9 combines Profiles 7 and 8, operating the Track as a full
      DODAG within a Storing Mode main DODAG, using only the main DODAG
      RPLInstanceID as the TrackID.