RFC 8697: Path Computation Element Communication Protocol (PCEP) Extensions for Establishing Relationships between Sets of Label Switched Paths (LSPs)

3.1. Motivations

A stateful PCE provides the ability to update existing LSPs and to instantiate new ones. There are various situations where several LSPs need to share common information. For example, to support PCE-controlled make-before-break, an association between the original path and the reoptimized path is desired. Similarly, for end-to-end protection, an association between working and protection LSPs is required (see [PCE-PROTECTION]). For diverse paths, an association between a group of LSPs could be used (see [PCE-DIVERSITY]). Another use for an LSP grouping would be to apply a common set of configuration parameters or behaviors to a set of LSPs.¶

For a stateless PCE, it might be useful to associate a PCReq message to an association group, thus enabling it to associate a common set of policies, configuration parameters, or behaviors with the request.¶

Some associations could be created dynamically, such as an association between the working and protection LSPs of a tunnel, whereas some associations could be created by the operator manually, such as a policy-based association where the LSP could join an operator-configured existing association.¶

Rather than creating separate mechanisms for each use case, this document defines a generic mechanism that can be reused as needed.¶

3.3. Operational Overview

LSPs are associated with other LSPs with which they interact by adding them to a common association group. Association groups as defined in this document can be applied to LSPs originating at the same headend or different headends.¶

Some associations could be created dynamically by a PCEP speaker, and the associations (along with the set of LSPs) are conveyed to a PCEP peer. Whereas some associations are configured by the operator beforehand on the PCEP peers in question, a PCEP speaker could then ask an LSP to join the Operator-configured Association. Usage of dynamic and configured associations is usually dependent on the type of association.¶

For Operator-configured Associations, the association parameters, such as the Association Identifier (Association ID), Association Type, and the Association Source IP address, are manually configured by the operator. In the case of a dynamic association, the association parameters, such as the Association ID, are allocated dynamically by the PCEP speaker. The Association Source is set as the local PCEP speaker address unless local policy dictates otherwise, in which case the Association Source is set based on the local policy.¶

The dynamically created association can be reported to the PCEP peer via the PCEP messages as per the stateful extensions. When the Operator-configured Association is known to the PCEP peer beforehand, a PCEP peer could ask an LSP to join the Operator-configured Association via the stateful PCEP messages.¶

The associations are properties of the LSP and thus could be stored in the LSP state database. The dynamic association exists as long as the LSP state exists. In the case of PCEP session termination, the LSP state cleanup MUST also take care of associations.¶

Multiple types of associations can exist, each with its own Association ID space. The definition of the different Association Types and their behaviors is outside the scope of this document. The establishment and removal of the association relationship can be done on a per-LSP basis. An LSP may join multiple association groups that have the same Association Type or different Association Types.¶

3.4. Operator-Configured Association Range

Some Association Types are dynamic, some are operator configured, and some could be both. For the Association Types that could be both dynamic and operator configured and use the same Association Source, it is necessary to distinguish a range of Association IDs that are marked for Operator-configured Associations, to avoid any Association ID clashes within the scope of the Association Source. This document assumes that these two ranges are configured.¶

A range of Association IDs for each Association Type (and Association Source) is kept for the Operator-configured Associations. Dynamic associations MUST NOT use the Association ID from this range.¶

This range, as set at the PCEP speaker (a PCC or PCE, as an Association Source), needs to be communicated to a PCEP peer in the Open message. A new TLV is defined in this specification for this purpose (Section 5). See Appendix A for an example.¶

The Association ID range for sources other than the PCEP speaker (for example, a Network Management System (NMS)) is not communicated in PCEP, and the procedure for Operator-configured Association Range settings is outside the scope of this document.¶

5.1. Procedure

A PCEP speaker MAY include an OP-CONF-ASSOC-RANGE TLV within an OPEN object in an Open message sent to a PCEP peer in order to advertise the Operator-configured Association Range for an Association Type. The OP-CONF-ASSOC-RANGE TLV MUST NOT appear more than once in an OPEN object. If it appears more than once, the PCEP session MUST be rejected with Error-Type 1 and Error-value 1 (PCEP session establishment failure / Reception of an invalid Open message).¶

As specified in [RFC5440], a PCEP peer that does not recognize the OP-CONF-ASSOC-RANGE TLV will silently ignore it.¶

The Operator-configured Association Range SHOULD be included for each Association Type that could be both dynamic and operator configured. For Association Types that are only dynamic or only operator configured, this TLV MAY be skipped, in which case the full range of Association IDs is considered dynamic or operator configured, respectively. Each Association Type (to be defined in future documents) can specify the default value for its Operator-configured Association Range.¶

The absence of the OP-CONF-ASSOC-RANGE TLV in an OPEN object MUST be interpreted as an absence of an explicit Operator-configured Association Range at the PCEP peer. In this case, the default behavior as per each Association Type applies. If the Association Source is not a PCEP speaker, the default value for the Operator-configured Association Range is used for the Association Source.¶

If the Assoc-Type is not recognized or supported by the PCEP speaker, it MUST ignore that respective (Start-Assoc-ID + Range). If the Assoc-Type is recognized/supported but Start-Assoc-ID or Range is set incorrectly, the PCEP session MUST be rejected with Error-Type 1 and Error-value 1 (PCEP session establishment failure / Reception of an invalid Open message). The incorrect range includes the case when the (Start-Assoc-ID + Range) crosses the largest Association ID value of 0xffff.¶

A given Assoc-Type MAY appear more than once in the OP-CONF-ASSOC-RANGE TLV in the case of a non-contiguous Operator-configured Association Range. The PCEP speaker originating this TLV MUST NOT send overlapping ranges for an Association Type. If a PCEP peer receives overlapping ranges for an Association Type, it MUST consider the Open message malformed and MUST reject the PCEP session with Error-Type 1 and Error-value 1 (PCEP session establishment failure / Reception of an invalid Open message).¶

There may be cases where an Operator-configured Association was configured with association parameters (such as an Association ID, Association Type, and Association Source) at the local PCEP speaker, and the PCEP session is later established with the Association Source and a new operator-configured range is learned during session establishment. At this time, the local PCEP speaker MUST remove any associations that are not in the new operator-configured range (by disassociating any LSPs that are part of it (and notifying the PCEP peer of this change)). If a PCEP speaker receives an association for an Operator-configured Association and the Association ID is not in the Operator-configured Association Range for the Association Type and Association Source, it MUST generate an error (as described in Section 6.4).¶

6.1. Object Definition

Association groups and their memberships are defined using a new ASSOCIATION object.¶

The ASSOCIATION Object-Class value is 40.¶

The ASSOCIATION Object-Type value is 1 for IPv4, and its format is shown in Figure 3:¶

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |         Reserved              |            Flags            |R|
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |      Association Type         |      Association ID           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |              IPv4 Association Source                          |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  //                   Optional TLVs                             //
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  

The ASSOCIATION Object-Type value is 2 for IPv6, and its format is shown in Figure 4:¶

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |         Reserved              |            Flags            |R|
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |      Association Type         |      Association ID           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
  |                    IPv6 Association Source                    |
  |                                                               |
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  //                   Optional TLVs                             //
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

Reserved (2 bytes):

MUST be set to 0 and ignored upon receipt.¶

Flags (2 bytes):

The following flag is currently defined:¶

R (Removal - 1 bit):

When set, the requesting PCEP peer requires the removal of an LSP from the association group. When unset, the PCEP peer indicates that the LSP is added or retained as part of the association group. This flag is used for the ASSOCIATION object in the Path Computation Report (PCRpt) and Path Computation Update (PCUpd) messages. It is ignored in other PCEP messages.¶

The unassigned flags MUST be set to 0 on transmission and MUST be ignored on receipt.¶

Association Type (2 bytes):

The Association Type (Section 7.4). The Association Types will be defined in future documents.¶

Association ID (2 bytes):

The identifier of the association group. When combined with other association parameters, such as an Association Type and Association Source, this value uniquely identifies an association group. The values 0xffff and 0x0 are reserved. The value 0xffff is used to indicate all association groups and could be used with the R flag to indicate removal for all associations for the LSP within the scope of the Association Type and Association Source.¶

Association Source:

Contains a valid IPv4 address (4 bytes) if the ASSOCIATION Object-Type is 1 or a valid IPv6 address (16 bytes) if the ASSOCIATION Object-Type is 2. The address provides scoping for the Association ID. See Section 6.1.3 for details.¶

Optional TLVs:

The optional TLVs follow the PCEP TLV format defined in [RFC5440]. This document defines two optional TLVs. Other documents can define more TLVs in the future.¶

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |         Type                  |            Length             |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |              Global Association Source                        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |         Type                  |            Length             |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  //                Extended Association ID                      //
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

6.3. Object Encoding in PCEP Messages

Message formats in this document are expressed using Routing BNF (RBNF) as used in [RFC5440] and defined in [RFC5511].¶

   <PCRpt Message> ::= <Common Header>
                       <state-report-list>

      <state-report-list> ::= <state-report>[<state-report-list>]

      <state-report> ::= [<SRP>]
                         <LSP>
                         [<association-list>]
                         <path>

      <path>::= <intended-path>
                [<actual-attribute-list><actual-path>]
                <intended-attribute-list>

      <association-list> ::= <ASSOCIATION> [<association-list>]

 <PCUpd Message> ::= <Common Header>
                     <update-request-list>

    <update-request-list> ::= <update-request>[<update-request-list>]

    <update-request> ::= <SRP>
                         <LSP>
                         [<association-list>]
                         <path>

    <path>::= <intended-path><intended-attribute-list>

    <association-list> ::= <ASSOCIATION> [<association-list>]

<PCInitiate Message> ::= <Common Header>
                         <PCE-initiated-lsp-list>

<PCE-initiated-lsp-list> ::= <PCE-initiated-lsp-request>
                             [<PCE-initiated-lsp-list>]

<PCE-initiated-lsp-request> ::= (<PCE-initiated-lsp-instantiation>|
                                <PCE-initiated-lsp-deletion>)

<PCE-initiated-lsp-instantiation> ::= <SRP>
                                      <LSP>
                                      [<END-POINTS>]
                                      <ERO>
                                      [<association-list>]
                                      [<attribute-list>]

<association-list> ::= <ASSOCIATION> [<association-list>]

<PCReq Message>::= <Common Header>
                   [<svec-list>]
                   <request-list>

   <svec-list>::= <SVEC>[<svec-list>]
   <request-list>::= <request>[<request-list>]

   <request>::= <RP>
                <END-POINTS>
                [<LSP>]
                [<LSPA>]
                [<BANDWIDTH>]
                [<metric-list>]
                [<association-list>]
                [<RRO>[<BANDWIDTH>]]
                [<IRO>]
                [<LOAD-BALANCING>]

   <association-list> ::= <ASSOCIATION> [<association-list>]

<PCRep Message> ::= <Common Header>
                    <response-list>

   <response-list>::=<response>[<response-list>]

   <response>::=<RP>
                [<LSP>]
                [<NO-PATH>]
                [<association-list>]
                [<attribute-list>]
                [<path-list>]

   <association-list> ::= <ASSOCIATION> [<association-list>]

6.4. Processing Rules

Association groups can be operator configured on the necessary PCEP speakers, and the PCEP speakers can join the existing association groups. In addition, a PCC or a PCE can create association groups dynamically, and the PCEP speaker can also report the associations to its peer via PCEP messages. The Operator-configured Associations are created via configurations (where all association parameters are manually set) and exist until explicitly removed via configurations. The PCEP speaker can add LSPs to these configured associations and provide this information via stateful PCEP messages. The dynamic associations are created dynamically by the PCEP speaker (where all association parameters are populated dynamically). The association group is attached to the LSP state, and the association group exists until there is at least one LSP as part of the association. As described in Section 6.1.4, the association parameters are the combination of Association Type, Association ID, and Association Source, as well as the optional Global Association Source and Extended Association ID TLVs; this combination uniquely identifies an association group. The information related to the Association Types encoded via the TLVs of a particular Association Type (not described in this document) is the association information (Section 6.1.4).¶

If a PCEP speaker does not recognize the ASSOCIATION object in the stateful message, it will return a PCErr message with Error-Type "Unknown Object" as described in [RFC5440]. In the case of a PCReq message, the PCE would react based on the P flag as per [RFC5440]. If a PCEP speaker understands the ASSOCIATION object but does not support the Association Type, it MUST return a PCErr message with Error-Type 26 "Association Error" and Error-value 1 "Association Type is not supported". If any association parameters are invalid in the ASSOCIATION object, the PCEP speaker would consider this object malformed and process it as a malformed message [RFC5440]. On receiving a PCEP message with an ASSOCIATION object, if a PCEP speaker finds that too many LSPs belong to the association group, it MUST return a PCErr message with Error-Type 26 "Association Error" and Error-value 2 "Too many LSPs in the association group". If a PCEP speaker cannot handle a new association, it MUST return a PCErr message with Error-Type 26 "Association Error" and Error-value 3 "Too many association groups". These numbers MAY be set by the operator or chosen based on a local policy.¶

If a PCE peer is unwilling or unable to process the ASSOCIATION object in the stateful message, it MUST return a PCErr message with the Error-Type "Not supported object" and follow the relevant procedures described in [RFC5440]. In the case of a PCReq message, the PCE would react based on the P flag as per [RFC5440]. On receiving a PCEP message with an ASSOCIATION object, if a PCEP speaker could not add the LSP to the association group for any reason, it MUST return a PCErr message with Error-Type 26 "Association Error" and Error-value 7 "Cannot join the association group".¶

If a PCEP speaker receives an ASSOCIATION object for an Operator-configured Association and the Association ID is not in the Operator-configured Association Range for the Association Type and Association Source, it MUST return a PCErr message with Error-Type 26 "Association Error" and Error-value 8 "Association ID not in range".¶

If a PCEP speaker receives an ASSOCIATION object in a PCReq message and the association is not known (the association is not configured, was not created dynamically, or was not learned from a PCEP peer), it MUST return a PCErr message with Error-Type 26 "Association Error" and Error-value 4 "Association unknown".¶

If the association information (related to the association group as a whole) received from the peer does not match the local operator-configured information, it MUST return a PCErr message with Error-Type 26 "Association Error" and Error-value 5 "Operator-configured association information mismatch". On receiving association information (related to the association group as a whole) that does not match the association information previously received about the same association from a peer, it MUST return a PCErr message with Error-Type 26 "Association Error" and Error-value 6 "Association information mismatch". Note that information related to each LSP within the association as part of the association information TLVs could be different.¶

If a PCEP speaker receives an ASSOCIATION object with the R bit set for removal and the association group (identified by association parameters) is not known, it MUST return a PCErr message with Error-Type 26 "Association Error" and Error-value 4 "Association unknown".¶

The dynamic associations are cleared along with the LSP state information as per [RFC8231]. When a PCEP session is terminated, after expiry of the State Timeout Interval at the PCC, the LSP state associated with that PCEP session is reverted to operator-defined default parameters or behaviors. The same procedure is also followed for the association groups. On session termination at the PCE, when the LSP state reported by the PCC is cleared, the association groups are also cleared. When there are no LSPs in an association group, the association is considered empty and thus deleted.¶

If the LSP is delegated to another PCE on session failure, the associations (and association information) set by the PCE remain intact, unless updated by the new PCE that takes over.¶

Upon LSP delegation revocation, the PCC MAY clear the association created by the PCE, but in order to avoid traffic loss, it SHOULD perform this action in a make-before-break fashion (same as [RFC8231]).¶

7.4. Association Type

Per this document, IANA has created a subregistry of the "Path Computation Element Protocol (PCEP) Numbers" registry for the Association Type field of the ASSOCIATION object. The subregistry is called "ASSOCIATION Type Field". New values are assigned by Standards Action [RFC8126]. Each value is tracked with the following qualities:¶

Values 2-65535 are Unassigned. Future documents should request the assignment of Association Types from this subregistry.¶