Path Computation Element Communication Protocol (PCEP) Extensions for Topology Filter

Introduction 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 describes a set of extensions to PCEP to enable active control of MPLS-TE and Generalized MPLS (GMPLS) tunnels. As depicted in , 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 or YANG . It can get multiple link-state data from multiple IGP instance, or multiple virtual topologies from a single IGP instance. In other cases, as per , 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, a topology defined by the application of one or more topology filters, a topology associated with an Network Resource Partition (NRP) as per and so on. The PCE MUST take the topology related constraints into consideration during the path computation. As defined in , 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.

Terminology The terminology is defined as , and .

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 when, and only when, they appear in all capitals, as shown here.

Topology Filter with PCE As defined in , a topology filter specifies the topology reference or a set of filtering rules. The topology filters carry a list of topology filters and a topology filter-set constitutes a list of topology filter references. 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 . A logical topology can also be associated with an NRP as per and an NRP can be identified using NRP Identifier (NRP-ID) as per . 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 . The PCE should consider these identifiers as topology constraints during path computation. 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.

PCEP Extensions

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. TOPOLOGY-FILTER Object-Class is TBD1. TOPOLOGY-FILTER Object-Type is TBD2. The format of the TOPOLOGY-FILTER object body is:

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 and may be used to carry topology filter information as defined in section. The existing topology constraints TLVs could also be reused such as Algorithm ID TLV and Domain ID TLV.

IGP Domain Identifier A specific IGP domain can be identified by a combination of Protocol ID, Instance ID, MT-ID as per and Division ID as per and Algorithm ID as per . 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. 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.

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 :

The code point for the TLV type is TBD3. The TLV length is 12 octets. Protocol-ID (8 bits): defined in section 5.2. Instance-ID (64 bits): defined in section 5.2. Reserved: This fields MUST be set to zero on transmission and MUST be ignored on receipt.

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 :

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 or the OSPF MT-ID as defined in Section 3.7 of . Reserved (16 bits): This field MUST be set to zero on transmission and MUST be ignored on receipt.

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 section 4.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 section 3.2.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.

Provider ID TLV The Provider ID TLV is optional and the format is as following shown:

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 .

Client ID TLV The Client ID TLV is optional and the format is as following shown:

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 .

Topology ID TLV The Topology ID TLV is optional and the format is as following shown:

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 .

NRP TLV The NRP TLV is optional and is defined to carry the NRP-ID to filter the NRP topology. The NRP TLV MAY be inserted so as to provide the NRP information for the computed path. The format of the TLV is defined in section 2.1.

Filtering Rules TLV This document defines a new Filtering Rules TLV for topology filter to carry a set of constrains on the topology by include-any, include-all and exclude. The Filtering Rules TLV is optional and the format is as following shown :

The code point for the TLV type is TBD8. The TLV length is variable. The fields of Exclude-any, Include-any and Include-all are identical to the fields of the LSPA object as per and the SESSION-ATTRIBUTE object as per . The sub-TLVs carry the attributes that can be used as rules to filter the topology and some sub-TLVs are defined in the following sections.

Link ID sub-TLV The Link ID is used to identify the link that is used during the path calculation. The Link ID sub-TLV is defined:

The code point for the TLV type is TBD9. The TLV length is 6 octets. Link-ID (32bits ): defined in IS-IS and OSPF .

Admin Group sub-TLV The Admin Group is used to include the links that is used during the path calculation.

The code point for the sub-TLV type is TBD10. The length is variable. Extended Administrative Group: Extended Administrative Group as defined in .

Source Protocol sub-TLV The format of the Source Protocol sub-TLV is:

The code point for the TLV type is TBD11. The TLV length is 10 octets. Protocol-ID (8 bits): defined in section 5.2. Instance-ID (64 bits): defined in section 5.2.

Procedures The TOPOLOGY-FILTER object can be carried within a PCReq message, or 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 constriants that could not be satisfied. 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 will compute the path with the constrains with the filtering rules and reply the result to the PCC with a PCRep message. The PCE could perform path computation based on the topology identified by the topology filter rules that can be applied on either the native topology or a user specified topology. The absence of the IGP Domain Identifier TLV and TE Topology Identifier TLV indicate that the PCE should compute within a native topology and only Filtering Rules TLV is applied as the filtering rules.

IANA Considerations

TOPOLOGY-FILTER Object IANA is requested to make allocations for Topology Filter Object from the registry, as follows: TOPOLOGY-FILTER Object-Class is TBD1. TOPOLOGY-FILTER Object-Type is TBD2. The TLVs for Topology Filter Object is as follows: TLVs for Topology Filter Object

Type	TLV	Reference
TBD3	Protocol ID TLV	[this document]
TBD4	Multi-topology ID TLV	[this document]
TBD5	Provider ID TLV	[this document]
TBD6	Client ID TLV	[this document]
TBD7	Topology ID TLV	[this document]
TBD8	Filtering Rules TLV	[this document]

IANA is requested to make allocations for sub-TLVs from the Filtering Rules TLV registry, as follows: Sub-TLVs

Type	sub-TLVs for Filtering Rules TLV	Reference
TBD9	Link ID sub-TLV	[this document]
TBD10	Admin Group sub-TLV	[this document]
TBD11	Source Protocol sub-TLV	[this document]

Acknowledgements The authors would like to thank Dhruv Dhody, Andrew Stone for their review, suggestions and comments to this document.

Operational Considerations A PCEP implementation MAY allow the capability of supporting the PCEP extensions introduced in this document. All manageability and operational requirements and considerations listed in and , 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 . The PCEP YANG module is defined in . In future, this YANG module should be extended or augmented to provide the additional information relating to topology filter.

Security Considerations This document defines a new Topology Filter Object, which do not introduce any new security considerations beyond those already listed in , , , and . The security considerations described in and apply to the topology filter described in this document as well.