PCC-initiated and PCC-controlled LSPs

For PCC-initiated and PCC-controlled LSPs, the user configures the LSP name, primary path name, and optional secondary path name with the path information in the referenced path name, entering a full or partial explicit path with all or some hops to the destination of the LSP. Each hop is specified as an address of a node or an address of the next hop of a TE link. Optionally, each hop can be specified as a SID value that corresponds to the MPLS label to use on a hop. If this option is used, the whole path must consist of SIDs.

To configure the primary path or secondary path to always use a specific link whenever it is up, the strict hop must be entered as an address corresponding to the next hop of an adjacency SID. If the strict hop corresponds to a loopback address, it is translated to an adjacency SID as explained below and therefore there is no guarantee that the same TE link is picked.

To use an SR-TE path that consists of unprotected adjacency SIDs, each hop of the path must be configured as a strict hop with the address matching the next hop of the adjacency SID and protection on each of these adjacencies must be disabled as explained in SR-TE LSP Path Computation.

MPLS assigns a tunnel ID to the SR-TE LSP and a path ID to each new instantiation of the primary path, as for an RSVP-TE LSP. These IDs represent the MBB path of the same SR-TE LSP, which must coexist during the update of the primary path.

Note: The concept of MBB is not exactly accurate in the context of an SR-TE LSP because there is no signaling involved and therefore the new path information immediately overrides the older one.

The router retains full control of the path of the LSP. CSPF is not supported; therefore, the full or partially explicit path is instantiated as is and no other constraint (such as SRLG, admin-group, hop-count, or bandwidth) is checked. Only the LSP path label stack size is checked by MPLS against the maximum value configured for the LSP after the TE database (TE-DB) hop-to-label translation returns the label stack. See SR-TE LSP Path Computation for more information about this check.

The ingress LER performs the following steps to resolve the user-entered path before programming it in the data path:

MPLS passes the path information to the TE-DB, which converts the list of hops into a label stack by scanning the TE-DB for adjacency and node SID information that belongs to the router or link identified by each hop address. If the conversion is successful, the TE-DB will return the actual selected hop SIDs plus labels as well as the configured path hop addresses that were used as the input for this conversion.

Details of this step are as follows:
- A loose hop with an address matching any interface (loopback or not) of a router (identified by router ID) is always translated to a node SID. If the prefix matching the hop address has a node SID in the TE-DB, it will be selected by preference. If not, the node SID of any loopback interface of the same router that owns the hop address is selected. In the latter case, the lowest IP address of that router that has a /32 prefix-SID is selected.
- A strict hop with an address matching any interface (loopback or not) of a router (identified by router ID) is always translated to an adjacency SID. If the hop address matches the host address reachable in a local subnet from the previous hop, the adjacency SID of that adjacency is selected. If the hop address matches a loopback interface, it is translated to the adjacency SID of any link from the previous hop that terminates on the router owning the loopback. The adjacency SID label of the selected link is used.
  
  In both cases, it is possible to have multiple matching previous hops if the interface is a LAN interface. If there are multiple hops, the adjacency SID with the lowest interface address is selected.
- All IGP instances are scanned from the lowest to the highest instance ID, beginning with IS-IS instances and then the OSPF instance; not only the IGP instance that resolved the prefix of the destination address of the LSP in the RTM is used. For the first instance where all specified path hop addresses can be translated, the label stack is selected. The hop-to-SID/label translation tool does not support paths that cross area boundaries. All SID/labels of a given path are therefore taken from the same IGP area and instance.
  
  Note: For the hop-to-label translation to operate, the user must enable TE on the network links by adding the network interfaces to MPLS and RSVP. In addition, the user must enable the traffic-engineering option on all participating router IGP instances. If a router has the database-export option enabled in the participating IGP instances to populate the TE-DB with the learned IGP link-state information, then enabling of the traffic-engineering option is not required. For consistency, it is recommended that the traffic-engineering option always be enabled.
The ingress LER validates the first hop of the path to determine the outgoing interface and next hop to forward the packet to, and programs the data path according to the following conditions.
- If the first hop corresponds to an adjacency SID (host address of next hop on the link’s subnet), the adjacency SID label is not pushed. In other words, the ingress LER treats forwarding to a local interface as a push of an implicit null label.
- If the first hop is a node SID of a downstream router, the node SID label is pushed.
In both cases, the SR-TE LSP tracks and uses the SR shortest path tunnel of the SID of the first hop.
If the router is configured as a PCC and has a PCEP session to a PCE, the router sends a PCRpt message to update the PCE with the Up state and the RRO object for each LSP that has the pce-report option enabled. The PE router does not set the delegation control flag to keep LSP control. The state of the LSP is now synchronized between the router and the PCE.