Path Computation Element Communication Protocol (PCEP) Extensions for Topology Filter
draft-ietf-pce-topology-filter-01
| Document | Type | Active Internet-Draft (pce WG) | |
|---|---|---|---|
| Authors | Quan Xiong , Shaofu Peng , Vishnu Pavan Beeram , Tarek Saad , Mike Koldychev | ||
| Last updated | 2026-05-07 | ||
| Replaces | draft-xpbs-pce-topology-filter | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Document shepherd | (None) | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-pce-topology-filter-01
PCE Q. Xiong
Internet-Draft S. Peng
Intended status: Standards Track ZTE Corporation
Expires: 8 November 2026 V. Beeram
Juniper Networks
T. Saad
Cisco Systems
M. Koldychev
Ciena Corporation
7 May 2026
Path Computation Element Communication Protocol (PCEP) Extensions for
Topology Filter
draft-ietf-pce-topology-filter-01
Abstract
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.
Status of This Memo
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 Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
Xiong, et al. Expires 8 November 2026 [Page 1]
Internet-Draft PCEP Extensions for Topology Filter May 2026
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Topology Filter with PCE . . . . . . . . . . . . . . . . . . 4
3. PCEP Extensions . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. TOPOLOGY-FILTER Object . . . . . . . . . . . . . . . . . 4
3.1.1. IGP Domain Identifier . . . . . . . . . . . . . . . . 5
3.1.1.1. Protocol ID TLV . . . . . . . . . . . . . . . . . 5
3.1.1.2. Multi-topology ID TLV . . . . . . . . . . . . . . 6
3.1.1.3. Algorithm ID TLV . . . . . . . . . . . . . . . . 7
3.1.1.4. Domain ID TLV . . . . . . . . . . . . . . . . . . 7
3.1.2. TE Topology Identifier . . . . . . . . . . . . . . . 7
3.1.2.1. Provider ID TLV . . . . . . . . . . . . . . . . . 7
3.1.2.2. Client ID TLV . . . . . . . . . . . . . . . . . . 8
3.1.2.3. Topology ID TLV . . . . . . . . . . . . . . . . . 8
3.1.3. Filtering Rules . . . . . . . . . . . . . . . . . . . 9
3.1.3.1. Admin Group Filtering Rules . . . . . . . . . . . 9
3.1.3.2. Information Source Filtering Rules . . . . . . . 10
3.2. OPEN Object . . . . . . . . . . . . . . . . . . . . . . . 13
3.2.1. TOPOLOGY-FILTER-CAPABILITY TLV . . . . . . . . . . . 13
4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
5.1. PCEP Object . . . . . . . . . . . . . . . . . . . . . . . 16
5.2. PCEP TLVs . . . . . . . . . . . . . . . . . . . . . . . . 16
5.3. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 18
5.4. Flags in the TOPOLOGY-FILTER-CAPABILITY TLV . . . . . . . 18
5.5. Flags in the Info Source sub-TLV . . . . . . . . . . . . 19
6. Operational Considerations . . . . . . . . . . . . . . . . . 19
7. Security Considerations . . . . . . . . . . . . . . . . . . . 19
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
9.1. Infomative References . . . . . . . . . . . . . . . . . . 20
9.2. Normative References . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
Xiong, et al. Expires 8 November 2026 [Page 2]
Internet-Draft PCEP Extensions for Topology Filter May 2026
1. Introduction
[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.
1.1. Terminology
The terminology is defined as [RFC5440], [RFC9552] and [RFC8795].
1.2. Requirements Language
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.
Xiong, et al. Expires 8 November 2026 [Page 3]
Internet-Draft PCEP Extensions for Topology Filter May 2026
2. Topology Filter with PCE
[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.
3. PCEP Extensions
3.1. TOPOLOGY-FILTER Object
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.
Xiong, et al. Expires 8 November 2026 [Page 4]
Internet-Draft PCEP Extensions for Topology Filter May 2026
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 //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: TOPOLOGY-FILTER Body Object Format
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.
3.1.1. IGP Domain Identifier
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.
3.1.1.1. Protocol ID TLV
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 :
Xiong, et al. Expires 8 November 2026 [Page 5]
Internet-Draft PCEP Extensions for Topology Filter May 2026
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Protocol ID TLV
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.
3.1.1.2. Multi-topology ID TLV
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Multi-topology ID TLV
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].
Xiong, et al. Expires 8 November 2026 [Page 6]
Internet-Draft PCEP Extensions for Topology Filter May 2026
Reserved (16 bits): This field MUST be set to zero on transmission
and MUST be ignored on receipt.
3.1.1.3. Algorithm ID TLV
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].
3.1.1.4. Domain ID TLV
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.
3.1.2. TE Topology Identifier
This document defines some TE Topology Identifier TLVs for topology
filter to identify a predefined TE topology within a referenced
topology.
3.1.2.1. Provider ID TLV
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Provider ID TLV
Xiong, et al. Expires 8 November 2026 [Page 7]
Internet-Draft PCEP Extensions for Topology Filter May 2026
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].
3.1.2.2. Client ID TLV
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Client ID TLV
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].
3.1.2.3. Topology ID TLV
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Topology ID TLV
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].
Xiong, et al. Expires 8 November 2026 [Page 8]
Internet-Draft PCEP Extensions for Topology Filter May 2026
3.1.3. Filtering Rules
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.
3.1.3.1. Admin Group Filtering Rules
3.1.3.1.1. Include-Any Admin Group TLV
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 |
+- -+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Include-Any Admin Group TLV
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].
3.1.3.1.2. Include-All Admin Group TLV
The Include-All Admin Group TLV is used to include the links with
include-all rule that is used during the path calculation.
Xiong, et al. Expires 8 November 2026 [Page 9]
Internet-Draft PCEP Extensions for Topology Filter May 2026
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 |
+- -+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Include-All Admin Group TLV
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].
3.1.3.1.3. Exclude Admin Group TLV
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 |
+- -+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Exclude Admin Group TLV
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].
3.1.3.2. Information Source Filtering Rules
Xiong, et al. Expires 8 November 2026 [Page 10]
Internet-Draft PCEP Extensions for Topology Filter May 2026
3.1.3.2.1. Include-Any Information Source TLV
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Include-Any Information Source TLV
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 //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: Info Source sub-TLV
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.
Xiong, et al. Expires 8 November 2026 [Page 11]
Internet-Draft PCEP Extensions for Topology Filter May 2026
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.
3.1.3.2.2. Include-All Information Source 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: Include-All Information Source TLV
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.
3.1.3.2.3. Exclude Information Source TLV
The Exclude Information Source TLV is used to exclude the IGP
topology information source that is used during the path calculation.
Xiong, et al. Expires 8 November 2026 [Page 12]
Internet-Draft PCEP Extensions for Topology Filter May 2026
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: Exclude Information Source TLV
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.
3.2. OPEN Object
3.2.1. TOPOLOGY-FILTER-CAPABILITY TLV
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|
+---------------------------------------------------------------+
Figure 14: TOPOLOGY-FILTER-CAPABILITY TLV Format
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):
Xiong, et al. Expires 8 November 2026 [Page 13]
Internet-Draft PCEP Extensions for Topology Filter May 2026
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.
Xiong, et al. Expires 8 November 2026 [Page 14]
Internet-Draft PCEP Extensions for Topology Filter May 2026
4. Operation
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.
5. IANA Considerations
Xiong, et al. Expires 8 November 2026 [Page 15]
Internet-Draft PCEP Extensions for Topology Filter May 2026
5.1. PCEP Object
IANA is requested to make new allocations within the "PCEP Objects"
subregistry of the "Path Computation Element Protocol (PCEP) Numbers"
registry:
+==============+=======================+===========+
| Object-Class | Object-Type | Reference |
| Value | Value:Name | |
+==============+=======================+===========+
| TBD1 | 0: Reserved | [this |
| | | document] |
| | TBD2: TOPOLOGY-FILTER | |
+--------------+-----------------------+-----------+
Table 1
Object-Type values are managed via the IETF Review policy as per
[RFC8126].
5.2. PCEP TLVs
IANA is requested to make new allocations in the "PCEP TLV Type
Indicators" registry:
Xiong, et al. Expires 8 November 2026 [Page 16]
Internet-Draft PCEP Extensions for Topology Filter May 2026
+================+================================+=================+
| 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 | [this document] |
| | Source | |
+----------------+--------------------------------+-----------------+
| TBD13 | Include-All Information | [this document] |
| | Source | |
+----------------+--------------------------------+-----------------+
| TBD14 | Exclude Information Source | [this document] |
+----------------+--------------------------------+-----------------+
| TBD15 | TOPOLOGY-FILTER-CAPABILITY | [this document] |
| | TLV | |
+----------------+--------------------------------+-----------------+
Table 2
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] |
+-------+---------------------+-----------------+
Table 3
Xiong, et al. Expires 8 November 2026 [Page 17]
Internet-Draft PCEP Extensions for Topology Filter May 2026
5.3. PCEP-Error Object
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] |
+----------------------+-------------------------------+-----------+
Table 4
5.4. Flags in the TOPOLOGY-FILTER-CAPABILITY TLV
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] |
+-----+---------------------------------------+-----------------+
Table 5
Xiong, et al. Expires 8 November 2026 [Page 18]
Internet-Draft PCEP Extensions for Topology Filter May 2026
5.5. Flags in the Info Source sub-TLV
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] |
+-----+----------------------------------+-----------------+
Table 6
6. Operational Considerations
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.
7. Security Considerations
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.
Xiong, et al. Expires 8 November 2026 [Page 19]
Internet-Draft PCEP Extensions for Topology Filter May 2026
8. Acknowledgements
The authors would like to thank Dhruv Dhody, Andrew Stone and Samuel
Sidor for their review, suggestions and comments to this document.
9. References
9.1. Infomative References
[I-D.ietf-pce-pcep-yang]
Dhody, D., Beeram, V. P., Hardwick, J., and J. Tantsura,
"A YANG Data Model for Path Computation Element
Communications Protocol (PCEP)", Work in Progress,
Internet-Draft, draft-ietf-pce-pcep-yang-30, 26 January
2025, <https://datatracker.ietf.org/doc/html/draft-ietf-
pce-pcep-yang-30>.
[I-D.ietf-teas-ns-ip-mpls]
Saad, T., Beeram, V. P., Dong, J., Halpern, J. M., and S.
Peng, "Realizing Network Slices in IP/MPLS Networks", Work
in Progress, Internet-Draft, draft-ietf-teas-ns-ip-mpls-
07, 28 February 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-teas-ns-
ip-mpls-07>.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<https://www.rfc-editor.org/info/rfc3209>.
[RFC9543] Farrel, A., Ed., Drake, J., Ed., Rokui, R., Homma, S.,
Makhijani, K., Contreras, L., and J. Tantsura, "A
Framework for Network Slices in Networks Built from IETF
Technologies", RFC 9543, DOI 10.17487/RFC9543, March 2024,
<https://www.rfc-editor.org/info/rfc9543>.
9.2. Normative References
[I-D.ietf-pce-pcep-nrp]
Dong, J., Fang, S., Xiong, Q., Peng, S., Han, L., Wang,
M., Beeram, V. P., and T. Saad, "Path Computation Element
Communication Protocol (PCEP) Extensions for Network
Resource Partition (NRP)", Work in Progress, Internet-
Draft, draft-ietf-pce-pcep-nrp-00, 6 November 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-pce-
pcep-nrp-00>.
Xiong, et al. Expires 8 November 2026 [Page 20]
Internet-Draft PCEP Extensions for Topology Filter May 2026
[I-D.ietf-pce-sid-algo]
Sidor, S., Rose, Z., Peng, S., Peng, S., and A. Stone,
"Carrying SR-Algorithm in Path Computation Element
Communication Protocol (PCEP)", Work in Progress,
Internet-Draft, draft-ietf-pce-sid-algo-29, 15 October
2025, <https://datatracker.ietf.org/doc/html/draft-ietf-
pce-sid-algo-29>.
[I-D.ietf-teas-yang-topology-filter]
Beeram, V. P., Saad, T., Gandhi, R., and X. Liu, "YANG
Data Model for Topology Filter", Work in Progress,
Internet-Draft, draft-ietf-teas-yang-topology-filter-02,
19 October 2025, <https://datatracker.ietf.org/doc/html/
draft-ietf-teas-yang-topology-filter-02>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630,
DOI 10.17487/RFC3630, September 2003,
<https://www.rfc-editor.org/info/rfc3630>.
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
Computation Element (PCE)-Based Architecture", RFC 4655,
DOI 10.17487/RFC4655, August 2006,
<https://www.rfc-editor.org/info/rfc4655>.
[RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P.
Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF",
RFC 4915, DOI 10.17487/RFC4915, June 2007,
<https://www.rfc-editor.org/info/rfc4915>.
[RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi
Topology (MT) Routing in Intermediate System to
Intermediate Systems (IS-ISs)", RFC 5120,
DOI 10.17487/RFC5120, February 2008,
<https://www.rfc-editor.org/info/rfc5120>.
[RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions
in Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008,
<https://www.rfc-editor.org/info/rfc5307>.
Xiong, et al. Expires 8 November 2026 [Page 21]
Internet-Draft PCEP Extensions for Topology Filter May 2026
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440,
DOI 10.17487/RFC5440, March 2009,
<https://www.rfc-editor.org/info/rfc5440>.
[RFC7308] Osborne, E., "Extended Administrative Groups in MPLS
Traffic Engineering (MPLS-TE)", RFC 7308,
DOI 10.17487/RFC7308, July 2014,
<https://www.rfc-editor.org/info/rfc7308>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path
Computation Element Communication Protocol (PCEP)
Extensions for Stateful PCE", RFC 8231,
DOI 10.17487/RFC8231, September 2017,
<https://www.rfc-editor.org/info/rfc8231>.
[RFC8685] Zhang, F., Zhao, Q., Gonzalez de Dios, O., Casellas, R.,
and D. King, "Path Computation Element Communication
Protocol (PCEP) Extensions for the Hierarchical Path
Computation Element (H-PCE) Architecture", RFC 8685,
DOI 10.17487/RFC8685, December 2019,
<https://www.rfc-editor.org/info/rfc8685>.
[RFC8776] Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin,
"Common YANG Data Types for Traffic Engineering",
RFC 8776, DOI 10.17487/RFC8776, June 2020,
<https://www.rfc-editor.org/info/rfc8776>.
[RFC8795] Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and
O. Gonzalez de Dios, "YANG Data Model for Traffic
Engineering (TE) Topologies", RFC 8795,
DOI 10.17487/RFC8795, August 2020,
<https://www.rfc-editor.org/info/rfc8795>.
[RFC9552] Talaulikar, K., Ed., "Distribution of Link-State and
Traffic Engineering Information Using BGP", RFC 9552,
DOI 10.17487/RFC9552, December 2023,
<https://www.rfc-editor.org/info/rfc9552>.
Xiong, et al. Expires 8 November 2026 [Page 22]
Internet-Draft PCEP Extensions for Topology Filter May 2026
Authors' Addresses
Quan Xiong
ZTE Corporation
China
Email: xiong.quan@zte.com.cn
Shaofu Peng
ZTE Corporation
No.50 Software Avenue
Nanjing
Jiangsu, 210012
China
Email: peng.shaofu@zte.com.cn
Vishnu Pavan Beeram
Juniper Networks
Email: vbeeram@juniper.net
Tarek Saad
Cisco Systems
Email: tsaad.net@gmail.com
Mike Koldychev
Ciena Corporation
Email: mkoldych@ciena.com
Xiong, et al. Expires 8 November 2026 [Page 23]