SRĀ OS supports the use of PCEP Association Groups to reference SR-TE LSP path constraints. PCEP Association Groups allow LSPs to share common information, such as common policies or common configuration parameters. Users can use association groups for PCC-initiated, PCE-initiated, and on-demand SR-TE auto-LSPs. Association groups are supported on both the PCC and NSP PCE.
The PCEP ASSOCIATION object defines an Association ID and an Association Type to signal any type of association between LSPs (as defined in RFC 8697). Association groups are identified by a tuple consisting of an Association ID, Association Type, and Association Source. Association groups offer a disaggregated approach to specifying association, where the Association ID is equivalent to the path group ID, and the tuple (Association ID, Association Type, Association Source) is equivalent to the path profile ID. The tuple is the key to the association group. Both IPv4 and IPv6 PCEP control planes support signaling of the Association IDs. The NSP uses the Association ID to reference a path profile.
Path diversity constraints are signaled using the Disjoint Association Type defined in RFC 8800, while policy constraints are signaled using the policy Association Type defined in draft-ietf-pce-association-policy-16. The Association ID for a policy association is also used by the PCE to signal which LSP template to bind to a PCE-initiated SR-TE LSP.
Use the following CLI syntax to configure PCE associations on the PCC under the following contexts:
classic CLI
configure router pcep
pcc
pce-associations
[no] diversity association-name
association-id [1..65535]
no association-id
association-source ip-address
no association-source
disjointness-reference
no disjointness-reference
disjointness-type {loose | strict}
no disjointness-type
diverity-type {link | node | srlg-link | srlg-node}
no diversity-type
[no] policy association-name
association-id association-id
no association-id
association-source ip-address
no association-source
MD-CLI
configure router pcep
pcc
pce-associations
diversity [assoc-name] string
association-id number
association-source ipv4-address
disjointness-reference {true|false}
disjointness-type {strict | loose}
diversity-type {none | link | node | srlg-link | srlg-node}
policy [assoc-name] string
association-id number
association-source ip-address
The user must configure the Association ID and Association Source address. In most cases, the Association Source address (which may be IPv4 or IPv6) is the PCC source address. Configuring the Association Source address allows interoperability with third-party controllers that assume a specific allocation scheme, which supports cases such as the diversity between LSPs that originate on different PCC nodes but are configured with the same Association Source address for a specific Association ID and Association Type.
See Diversity Association Group and Policy Association Group for more details about the configuration of these association types.
A PCC-initiated SR-TE LSP can have up to five associations, as follows. These associations must be defined under the PCC context.
Use the following CLI syntax to configure a PCC-initiated SR-TE LSP:
classic CLI
configure router mpls
lsp lsp-name sr-te
pce-associations
[no] policy policy-assoc-name
[no] diversity diversity-assoc-name
MD-CLI
configure router mpls
lsp [lsp-name] type p2p-sr-te
pce-associations
policy policy-name
diversity diversity-name
On-demand SR-TE auto-LSPs are bound to association groups using the pce-associations context in the LSP template, with up to five associations per template
classic CLI
configure router mpls
lsp-template template-name on-demand-p2p-srte
pce-associations
[no] policy policy-assoc-name
[no] diversity diversity-assoc-name
MD-CLI
configure router mpls
lsp-template template-name type p2p-sr-te-on-demand
pce-associations
policy policy-name
diversity diversity-name
The configuration of a PCE association for an LSP or LSP template and the configuration of the path profile ID and path group ID are mutually exclusive. Path profile and association group are also not interoperable. That is, LSPs with path profile and those with association group cannot be considered in the same group and cannot be compared against each other.
The PCC can signal one or more ASSOCIATION objects for each Association Type based on the configuration of the PCC-initiated LSP. This information is passed by MPLS to the PCC module. The PCC can include the ASSOCIATION object and its TLVs in any of the following PCEP messages: PCReq, PCRpt. The PCE may reflect the same ASSOCIATION objects and TLVs in any of the following PCEP messages: PCRep, PCUpd. In the specific case of the Diversity ASSOCIATION object, the PCE includes the status of the diversity as computed by PCE in the DISJOINTNESS-STATUS-TLV.
The only ASSOCIATION object applicable to a PCE-initiated LSP is the policy type. The PCE uses the Association ID for the policy type to signal a reference to the required PCE-initiated LSP template to use on the router for the associated PCE-initiated SR-TE LSP. The ASSOCIATION object is included in the following PCEP messages: PCInitiate, PCUpd. This information is also included in subsequent PCRpt messages from the PCC to the PCE. The NSP uses this information to reference a policy association for the LSP.
If the ASSOCIATION objects in the PCE do not match the ones sent by PCC in the PCReq or PCRpt messages, the PCC returns an error.
If the PCC rejects a request for a particular association from MPLS with a "path not found" message, the PCC updates the reason code and tears down the path if it is up, and retries until the retry limit is exceeded.
The router handles consistency between the association group configuration for a set of LSPs on a specific PCC. That is, an association group can only have one set of parameters within an association (for example, Diversity Type and Disjointness Type), which ensures that LSPs added to the same association group do not have inconsistent parameters. However, LSPs that originate on different PCCs can be added to the same association group, but those association groups have different parameters configured on the different PCCs. In that case, only the NSP can detect parameter inconsistencies.
For LSPs that are delegated and have inconsistent association parameters, the NSP sends a PCUpd down message followed by a PCErr message with the appropriate error message. This causes the affected LSPs to go operationally down. For non-delegated LSPs, the NSP sends a PCErr message.
If an LSP is added to an association group that has inconsistent parameters when compared with the same association group to which operationally up LSPs are already assigned, the NSP only registers an error on the new LSP and leaves the existing LSPs undisturbed.