| Internet-Draft | PCEP Extensions for Topology Filter | May 2026 |
| Xiong, et al. | Expires 8 November 2026 | [Page] |
A topology filter is a data construct that is used to filter network topologies. The Path Computation Element (PCE) MUST take into account the topology related constraints during the path computation. This document proposes a set of extensions for Path Computation Element Communication Protocol (PCEP) to support the topology filter.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 8 November 2026.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
[RFC5440] describes the Path Computation Element Computation Protocol (PCEP) which is used between a Path Computation Element (PCE) and a Path Computation Client (PCC) (or other PCE) to enable computation of Multi-protocol Label Switching (MPLS) for Traffic Engineering Label Switched Path (TE LSP). PCEP Extensions for the Stateful PCE Model [RFC8231] describes a set of extensions to PCEP to enable active control of MPLS-TE and Generalized MPLS (GMPLS) tunnels. As depicted in [RFC4655], a PCE MUST be able to compute the path of a TE LSP by operating on the TED and considering bandwidth and other constraints applicable to the TE LSP service request.¶
A PCE may perform path computation based on the network topology information collected through BGP-LS [RFC9552] or YANG [RFC8776]. It can get multiple link-state data from multiple IGP instance, or multiple virtual topologies from a single IGP instance. As described in [I-D.ietf-teas-yang-topology-filter], a topology may be associated with an Network Resource Partition (NRP) as per [RFC9543]. In other cases, a topology related constraints are also specified for TE path computation. For example, a path may be computed within a network topology such as a specified topology, a topology associated with a specific IGP domain, a topology learnt from a specific TE information source, and a topology defined by the application of one or more topology filters. The PCE SHOULD also consider the topology related constraints to construct the topology filter during the path computation.¶
As defined in [I-D.ietf-teas-yang-topology-filter], a topology filter is a data construct that is used to filter network topologies. This document proposes a set of extensions for PCEP to support the topology filter during path computation.¶
The terminology is defined as [RFC5440], [RFC9552] and [RFC8795].¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
[I-D.ietf-teas-yang-topology-filter] defined a construct for topology filters and the filtering rules to specify a set of topology constraints and the YANG model can be applied in centrallized controller. And in PCE scenarios, a path is required to be computed within a topology which may apply the topology filters to construct the topology. So the PCE MUST consider the corresponding topology related constraints and filtering rules during path computation.¶
As defined in [I-D.ietf-teas-yang-topology-filter], a logical topology can be associated with an NRP as per [RFC9543] and an NRP can be identified using NRP Identifier (NRP-ID) as per [I-D.ietf-teas-ns-ip-mpls]. An NRP TLV which carries the NRP-ID can be used to filter the NRP topology as per [I-D.ietf-pce-pcep-nrp] section 2.1.¶
Furthermore, as per [I-D.ietf-teas-yang-topology-filter], a topology filter specifies the topology reference and/or a set of filtering rules that can be applied on either the native topology or a user specified topology. The topology reference indicates a predefined TE topology or a specific IGP domain. A TE topology can be identified from a global scope such as a Provider ID, a Client ID, a Topology ID as per [RFC8776]. An IGP domain has a unique IGP representation by using the combination of Area-ID, Router-ID, Protocol-ID, Multi-Topology Identifier (MT-ID), and BGP-LS Instance-ID as per [RFC9552].¶
The filtering rules specify a set of constraints on the topology including include-any, include-all and exclude. A set of attributes that can be used as rules to filter the topology such as link affinity, link name, node prefix, AS number and TE information source. The filtering rules of these attributes can be used to compute path at PCE.¶
This document defines a new TOPOLOGY-FILTER object to carry the topology filter. The TOPOLOGY-FILTER object is optional and specifies the specific topology to be taken into account by the PCE during path computation. The TOPOLOGY-FILTER object must be presented once and other TOPOLOGY-FILTER objects MUST be ignored if multiple TOPOLOGY-FILTER objects appreared.¶
TOPOLOGY-FILTER Object-Class is TBD1.¶
TOPOLOGY-FILTER Object-Type is TBD2.¶
The format of the TOPOLOGY-FILTER object body is:¶
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Optional TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved (24 bits): This field MUST be set to zero on transmission and MUST be ignored on receipt.¶
Flags (8 bits): No flags are currently defined. Unassigned flags MUST be set to zero on transmission and MUST be ignored on receipt.¶
The format of optional TLVs is defined in [RFC5440] and may be used to carry topology filter information as defined in following sections. The existing topology constraints TLVs could also be reused such as Algorithm ID TLV and Domain ID TLV. These TLVs can be carried but each type can only be presented once. And it MUST be applied to filter the resources that match all presenting TLVs at the same time.¶
A specific IGP domain can be identified by a combination of Protocol ID, Instance ID, MT-ID as per [RFC9552] and Division ID as per [RFC8685] and Algorithm ID as per [I-D.ietf-pce-sid-algo]. This document defines some TLVs for topology filter to identify an IGP domain within a referenced topology. The Protocol ID TLV is mandatory to identify an IGP domain and others are optional to carry the additional information to further filter permitted resources within the domain.¶
The Protocol ID TLV is mandatory to identify an IGP domain and it is defined to carry the Protocol ID and Instance ID.¶
The format of the Protocol ID TLV is :¶
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=TBD3 | Length=12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol-ID | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Instance-ID |
| (64 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The code point for the TLV type is TBD3. The TLV length is 12 octets.¶
Protocol-ID (8 bits): defined in [RFC9552] section 5.2.¶
Instance-ID (64 bits): defined in [RFC9552] section 5.2.¶
Reserved: This fields MUST be set to zero on transmission and MUST be ignored on receipt.¶
The Multi-topology ID TLV is optional and is defined to carry the MT-ID.¶
The format of the Multi-topology ID TLV is :¶
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=TBD4 | Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R R R R| Multi-Topology-ID | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The code point for the TLV type is TBD4. The TLV length is 4 octets.¶
Multi-Topology-ID (12 bits): it indicates the IS-IS MT-ID as defined in Sections 7.1 and 7.2 of [RFC5120] or the OSPF MT-ID as defined in Section 3.7 of [RFC4915].¶
Reserved (16 bits): This field MUST be set to zero on transmission and MUST be ignored on receipt.¶
The Algorithm ID TLV is optional and is defined to carry the Algorithm ID.¶
The Algorithm ID TLV MAY be inserted so as to provide the Flex-algo plane information for the computed path. The format of the TLV is defined in [I-D.ietf-pce-sid-algo] section 4.4.¶
The Algorithm ID is a filter constraint for IGP domain iderntifier and it will based on the Flex-algo participation only. It is valid to do path computation for different algorithms using SR-Algorithm TLV as defined in [I-D.ietf-pce-sid-algo].¶
The Domain ID TLV is optional and is defined to carry the Domain-ID.¶
The Domain ID TLV MAY be inserted so as to identify the domains served by the PCE. The format of the TLV is defined in [RFC8685] section 3.2.2.¶
This document defines some TE Topology Identifier TLVs for topology filter to identify a predefined TE topology within a referenced topology.¶
The Provider ID TLV is optional and the format is as following shown:¶
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=TBD5 | Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Provider-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The code point for the TLV type is TBD5. The TLV length is 4 octets.¶
Provider-ID (32 bits): an identifier to uniquely identify a provider as defined in [RFC8776].¶
The Client ID TLV is optional and the format is as following shown:¶
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=TBD6 | Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Client-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The code point for the TLV type is TBD6. The TLV length is 4 octets.¶
Client-ID (32 bits): an identifier to uniquely identify a client as defined in [RFC8776].¶
The Topology ID TLV is optional and the format is as following shown:¶
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=TBD7 | Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Topology-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The code point for the TLV type is TBD7. The TLV length is 4 octets.¶
Topology-ID (32 bits): an identifier for a topology as defined in [RFC8776].¶
This document defines some TLVs for Filtering Rules of topology filter to carry a set of constrains on the topology by include-any, include-all and exclude.¶
The Include-Any Admin Group TLV is used to include the links with include-any rule that is used during the path calculation.¶
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=TBD8 | Length=variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Admin Group |
+- -+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The code point for the TLV type is TBD8. The length is variable and depends on the size of the Extended Admin Group. It MUST be a multiple of 4 octets.¶
Extended Administrative Group: Extended Administrative Group as defined in [RFC7308].¶
The Include-All Admin Group TLV is used to include the links with include-all rule that is used during the path calculation.¶
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=TBD9 | Length=variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Admin Group |
+- -+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The code point for the TLV type is TBD9. The length is variable and depends on the size of the Extended Admin Group. It MUST be a multiple of 4 octets.¶
Extended Administrative Group: Extended Administrative Group as defined in [RFC7308].¶
The Exclude Admin Group TLV is used to exclude the links that is used during the path calculation.¶
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=TBD10 | Length=variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Admin Group |
+- -+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The code point for the TLV type is TBD10. The length is variable and depends on the size of the Extended Admin Group. It MUST be a multiple of 4 octets.¶
Extended Administrative Group: Extended Administrative Group as defined in [RFC7308].¶
The Include-Any Information Source TLV is used to include the IGP topology information source with include-any rule that is used during the path calculation.¶
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=TBD11 | Length=variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| List of Info Source sub-TLVs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The code point for the TLV type is TBD11. The length is variable.¶
sub-TLVs: Include-Any Information Source TLV will carry a list of Info Source sub-TLVs with the following format.¶
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=TBD12 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol-ID | Flags |I|D| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Instance-ID |
| (64 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Domain Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Domain-ID //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The code point for the sub-TLV type is TBD12. The sub-TLV length is variable.¶
Protocol-ID (8 bits): defined in [RFC9552] section 5.2.¶
Instance-ID (64 bits): defined in [RFC9552] section 5.2.¶
Domain Type (8 bits): defined in [RFC8685] section 3.2.2.¶
Domain-ID (variable): defined in [RFC8685] section 3.2.2.¶
The value comprises a single field -- Flags (8 bits):¶
I (Instance ID bit): If set, will signal that the Instance-ID field is present.¶
D (Instance ID bit): If set, will signal that the Domain-ID field is present.¶
The Protocol-ID is mandatory for the Info Source sub-TLV.¶
The Include-All Information Source TLV is used to include the IGP topology information source with include-all rule that is used during the path calculation.¶
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=TBD13 | Length=variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| List of Info Source sub-TLVs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The code point for the TLV type is TBD13. The length is variable.¶
sub-TLVs: Include-All Information Source TLV will carry a list of Info Source sub-TLVs.¶
The Exclude Information Source TLV is used to exclude the IGP topology information source that is used during the path calculation.¶
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=TBD14 | Length=variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| List of Info Source sub-TLVs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The code point for the TLV type is TBD14. The length is variable.¶
sub-TLVs: Exclude Information Source TLV will carry a list of Info Source sub-TLVs.¶
A PCEP speaker indicates whether it supports topology related constraints path computation using a new PCEP capability called "TOPOLOGY-FILTER-CAPABILITY". When the PCEP session is created, it sends an OPEN message with an OPEN Object containing the TOPOLOGY-FILTER-CAPABILITY TLV.¶
The TOPOLOGY-FILTER-CAPABILITY TLV is an optional TLV in OPEN object [RFC5440] to exchange the topology filter capability of PCEP speakers. Its format is shown in the following figure:¶
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=TBD15 | Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |I|G|T|C|P|D|A|M|S|
+---------------------------------------------------------------+
The type of the TLV is TBD1, and it has a fixed length of 4 octets.¶
The value comprises a single field -- Flags (32 bits):¶
S (Source Protocol ID Capability bit): If set, will signal that the PCE or the PCC supports the Protocol ID TLV of the topology filter capability in section 3.1.1.1.¶
M (Multi-topology ID Capability bit): If set, will signal that the PCE or the PCC supports the Multi-topology ID TLV of the topology filter capability in section 3.1.1.2. The S bit MUST be also set when M bit is set.¶
A (Algorithm ID Capability bit): If set, will signal that the PCE or the PCC supports the topology filter capability and the Algorithm ID TLV can be carried in TOPOLOGY-FILTER object as per section 3.1.1.3. The S bit MUST be also set when A bit is set.¶
D (Domain ID Capability bit): If set, will signal that the PCE or the PCC supports the topology filter capability and the Domain ID TLV can be carried in TOPOLOGY-FILTER object as per section 3.1.1.4. The S bit MUST be also set when D bit is set.¶
P (Provider ID Capability bit): If set, will signal that the PCE or the PCC supports the Provider ID TLV of the topology filter capability in section 3.1.2.1.¶
C (Client ID Capability bit): If set, will signal that the PCE or the PCC supports the Client ID TLV of the topology filter capability in section 3.1.2.2.¶
T (Topology ID Capability bit): If set, will signal that the PCE or the PCC supports the Topology ID TLV of the topology filter capability in section 3.1.2.3.¶
G (Admin Group Capability bit): If set, will signal that the PCE or the PCC supports the Admin Group filtering rules TLVs of the topology filter capability in section 3.1.3.1.¶
I (Information Source Capability bit): If set, will signal that the PCE or the PCC supports the Information Source filtering rules TLVs of the topology filter capability in section 3.1.3.2.¶
Unassigned bits MUST be set to 0 on transmission and MUST be ignored on receipt.¶
The PCE could perform path computation based on the topology identified by the topology filter that can be applied on either the native topology or a user specified topology. When the Protocol ID TLV is absent with other TLVs presenting as IGP domain identifiers, the receiving PCEP speaker MUST respond with a PCErr message with Error-Type 19 (Invalid Operation) and Error-Value TBD16 (Protocol ID is absent). The absence of the IGP Domain Identifier TLVs and TE Topology Identifier TLVs indicate that the PCE should compute within a native topology and only Filtering Rules TLVs are applied as the filtering rules.¶
A PCC MAY insert a TOPOLOGY-FILTER object in PCReq message to indicate the specific topology that MUST be considered by the PCE during path computation. The PCE MAY ignore the object when P flag is cleared based on rules describedas per section 7.2 in [RFC5440]. The PCE will compute the path with the constrains with the filtering rules and reply the result to the PCC with a PCRep message. The TOPOLOGY-FILTER object can be carried within a PCRep message in case of unsuccessful path computation. In this unsuccessful case, the PCRep message also contains a NO-PATH object, and the TOPOLOGY-FILTER object is used to indicate the set of topology filter constriants that could not be satisfied.¶
In stateful mode, the following procedures apply:¶
For PCC-initiated LSPs: A PCC MAY include a TOPOLOGY-FILTER object in a PCRpt message when delegating an LSP to the PCE, to indicate the topology filter constraints that MUST be applied during path computation. The PCE SHOULD include the TOPOLOGY-FILTER object in a PCUpd message only when path computation cannot be completed because the referenced topology or domain is not known to the PCE; in that case the PCUpd MUST also include a empty ERO to indicate the failure. If path computation succeeds, the PCE MAY omit the TOPOLOGY-FILTER object from PCUpd.¶
For PCE-initiated LSPs: A PCE MAY include a TOPOLOGY-FILTER object in a PCInitiate message. The PCC MUST reflect the TOPOLOGY-FILTER object in the corresponding PCRpt message and in all subsequent PCRpt messages for the same LSP.¶
IANA is requested to make new allocations within the "PCEP Objects" subregistry of the "Path Computation Element Protocol (PCEP) Numbers" registry:¶
| Object-Class Value | Object-Type Value:Name | Reference |
|---|---|---|
| TBD1 |
0: Reserved¶ TBD2: TOPOLOGY-FILTER¶ |
[this document] |
Object-Type values are managed via the IETF Review policy as per [RFC8126].¶
IANA is requested to make new allocations in the "PCEP TLV Type Indicators" registry:¶
| TLV Type Value | TLV name | Reference |
|---|---|---|
| TBD3 | Protocol ID | [this document] |
| TBD4 | Multi-topology ID | [this document] |
| TBD5 | Provider ID | [this document] |
| TBD6 | Client ID | [this document] |
| TBD7 | Topology ID | [this document] |
| TBD8 | Filtering Rules | [this document] |
| TBD8 | Include-Any Admin Group | [this document] |
| TBD9 | Include-All Admin Group | [this document] |
| TBD10 | Exclude Admin Group | [this document] |
| TBD11 | Include-Any Information Source | [this document] |
| TBD13 | Include-All Information Source | [this document] |
| TBD14 | Exclude Information Source | [this document] |
| TBD15 | TOPOLOGY-FILTER-CAPABILITY TLV | [this document] |
IANA is requested to make allocations for Info Source sub-TLV carried with the Filtering Rules TLVs, as follows:¶
| Value | sub-TLV | Reference |
|---|---|---|
| TBD12 | Info Source sub-TLV | [this document] |
IANA is requested to make new allocations in the "PCEP-ERROR Object Error Types and Values" registry:¶
| Error-Type | Error-Value | Reference |
|---|---|---|
| 19-Invalid Operation | TBD16 - Protocol ID is absent | [this document] |
IANA is requested to create a new registry called "Flags in TOPOLOGY-FILTER-CAPABILITY TLV" to manage the Flag field. New values are to be assigned by "IETF review" [RFC8126].¶
| Bit | Description | Reference |
|---|---|---|
| 0 | S-flag: Source Protocol ID Capability | [this document] |
| 1 | M-flag: Multi-topology ID Capability | [this document] |
| 2 | A-flag: Algorithm ID Capability | [this document] |
| 3 | D-flag: Domain ID Capability | [this document] |
| 4 | P-flag: Provider ID Capability | [this document] |
| 5 | C-flag: Client ID Capability | [this document] |
| 6 | T-flag: Topology ID Capability | [this document] |
| 7 | G-flag: Admin Group Capability | [this document] |
| 8 | I-flag: Information Source Capability | [this document] |
IANA is requested to create a new registry called "Flags in Info Source sub-TLV" to manage the Flag field. New values are to be assigned by "IETF review" [RFC8126].¶
| Bit | Description | Reference |
|---|---|---|
| 0 | I-flag: Instance ID is presented | [this document] |
| 1 | D-flag: Domain ID is presented | [this document] |
A PCE or PCC implementation MAY allow the topology filter capability advertisement supporting the PCEP extensions introduced in this document. All manageability and operational requirements and considerations listed in [RFC5440] and [RFC8231], apply to this document.¶
The PCEP extensions defined in this document do not impose any new requirements on other protocols but rely on the topology information from IGP, BGP-LS or YANG data model.¶
A PCEP implementation supporting this document SHOULD allow the operator to view the topology filter capability defined in this document. and take the topology constraints into account during the path computation especially the topology filtering rules which is defined in [I-D.ietf-teas-yang-topology-filter].¶
The PCEP YANG module is defined in [I-D.ietf-pce-pcep-yang]. In future, this YANG module should be extended or augmented to provide the additional information relating to topology filter.¶
This document defines a new Topology Filter Object, which do not introduce any new security considerations beyond those already listed in [RFC4655], [RFC5440], [RFC8231], [RFC8685] and [I-D.ietf-pce-sid-algo].¶
The security considerations described in [RFC8795] and [I-D.ietf-teas-yang-topology-filter] apply to the topology filter described in this document as well.¶
The authors would like to thank Dhruv Dhody, Andrew Stone and Samuel Sidor for their review, suggestions and comments to this document.¶