



PCE Working Group                                                J. Dong
Internet-Draft                                                   S. Fang
Intended status: Standards Track                     Huawei Technologies
Expires: 10 May 2026                                            Q. Xiong
                                                                 S. Peng
                                                         ZTE Corporation
                                                                  L. Han
                                                                 M. Wang
                                                            China Mobile
                                                               V. Beeram
                                                        Juniper Networks
                                                                 T. Saad
                                                           Cisco Systems
                                                         6 November 2025


 Path Computation Element Communication Protocol (PCEP) Extensions for
                    Network Resource Partition (NRP)
                       draft-ietf-pce-pcep-nrp-00

Abstract

   This document specifies the extensions to Path Computation Element
   Communication Protocol (PCEP) to carry Network Resource Partition
   (NRP) related information in the PCEP messages.  The extensions in
   this document can be used to indicate the NRP-specific constraints
   and information needed in path computation, path status report and
   path initialization.

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 10 May 2026.






Dong, et al.               Expires 10 May 2026                  [Page 1]

Internet-Draft           PCEP Extensions for NRP           November 2025


Copyright Notice

   Copyright (c) 2025 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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   4
   2.  PCEP Extensions . . . . . . . . . . . . . . . . . . . . . . .   4
     2.1.  New TLV in LSPA Object  . . . . . . . . . . . . . . . . .   4
     2.2.  Capability Advertisement  . . . . . . . . . . . . . . . .   5
   3.  Operations  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.1.  NRP-aware Path Computation  . . . . . . . . . . . . . . .   6
     3.2.  NRP-specific Path Update and Report . . . . . . . . . . .   6
     3.3.  NRP-specific Path Initiation  . . . . . . . . . . . . . .   6
   4.  Scalability Considerations  . . . . . . . . . . . . . . . . .   7
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   7.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . .   8
   8.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   8
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     9.2.  Informative References  . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

1.  Introduction

   [RFC5440] describes the Path Computation Element (PCE) Communication
   Protocol (PCEP).  PCEP enables the communication between a Path
   Computation Client (PCC) and a PCE, or between PCE and PCE, for the
   purpose of computation of Multi-protocol Label Switching (MPLS) as
   well as Generalized MPLS (GMPLS) Traffic Engineering Label Switched
   Path (TE LSP) characteristics.  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.





Dong, et al.               Expires 10 May 2026                  [Page 2]

Internet-Draft           PCEP Extensions for NRP           November 2025


   [RFC8231] specifies a set of extensions to PCEP to enable stateful
   control of TE LSPs within and across PCEP sessions in compliance with
   [RFC4657].  It includes mechanisms to effect LSP State
   Synchronization between PCCs and PCEs, delegation of control over
   LSPs to PCEs, and PCE control of timing and sequence of path
   computations within and across PCEP sessions.  The model of operation
   where LSPs are initiated from the PCE is described in [RFC8281].
   [RFC8664] specifies PCEP extensions to allow a stateful PCE to
   compute and initiate TE paths, as well as a PCC to request a path
   subject to certain constraints and optimization criteria in SR
   networks.

   With the introduction and evolvement of 5G and other network
   scenarios, existing or emerging applications or customers may require
   connectivity services with additional characteristics.  As described
   in [RFC9543], an RFC 9543 Network Slice enables connectivity service
   between a set of Service Demarcation Points (SDPs) with specific
   Service Level Objectives (SLOs) and Service Level Expectations (SLEs)
   over a common underlay network.  For the realization of RFC 9543
   network slice service, the concept Network Resource Partition (NRP)
   is introduced in [RFC9543].  A Network Resource Partition (NRP) is a
   subset of the buffer/queuing/ scheduling resources and associated
   policies on each of a connected set of links in the underlay network.

   [RFC9732] describes a framework and the candidate technologies for
   providing enhanced VPN services based on NRPs.  An NRP could be used
   as the underlay to meet the requirement of one or a group of enhanced
   VPN services.

   In MPLS or SR based network, the set of network resources allocated
   to an NRP can be identified using resource-aware SR SIDs as defined
   in [I-D.ietf-spring-resource-aware-segments]
   [I-D.ietf-spring-sr-for-enhanced-vpn], or the data plane NRP ID as
   defined in [I-D.ietf-6man-enhanced-vpn-vtn-id].  The logical topology
   associated with an NRP could be specified using mechanisms such as
   Multi-Topology [RFC4915], [RFC5120] or Flex-Algo [RFC9350], etc.

   To meet specific service requirement, traffic flows of an RFC 9543
   network slice service need be steered onto TE paths of the
   corresponding NRP.  A PCC may request the PCE for computing a TE path
   within an NRP, so that the path computation would take the resource
   attributes and the associated topology of the NRP into consideration.
   Correspondingly, a PCE may reply or initiate a TE path with NRP-
   specific control plane and data plane information to a PCC.

   This document specifies the extensions to PCEP to carry NRP related
   information in the PCEP messages.  The extensions can be used in the
   basic PCE computation, the stateful PCE and the PCE-initiated LSP



Dong, et al.               Expires 10 May 2026                  [Page 3]

Internet-Draft           PCEP Extensions for NRP           November 2025


   mechanisms to indicate the NRP-specific constraints and information
   needed in path computation, path status report and path
   initialization.

1.1.  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.

2.  PCEP Extensions

2.1.  New TLV in LSPA Object

   A new NRP TLV for use in the LSPA Object is defined to indicate the
   NRP ID and the related information which needs to be considered in
   path computation or instantiation.  The format of the NRP TLV is as
   follows:

     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=TBD1          |        Length=Variable        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                             NRP ID                            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |             Flags             |           Reserved            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    //                    Optional sub-TLV(s)                       //
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                          Figure 1: NRP TLV Format

   Where:

   *  NRP ID: A network-wide unique 32-bit identifier which is used to
      identify an NRP.

   *  Flags: 16-bit flags.  Currently all the flags are reserved for
      future use.  They SHOULD be set to zero on transmission and MUST
      be ignored on receipt.






Dong, et al.               Expires 10 May 2026                  [Page 4]

Internet-Draft           PCEP Extensions for NRP           November 2025


   *  Reserved: 16-bit reserved field for future use.  All the bits
      SHOULD be set to zero on transmission and MUST be ignored on
      receipt.

   *  Optional sub-TLVs: Additional information which can be used in
      NRP-specific constraints.  Currently no sub-TLV is defined in this
      document.

2.2.  Capability Advertisement

   A PCEP speaker indicates whether it supports NRP-specific path
   computation using a new PCEP capability called "NRP-CAPABILITY".
   When the PCEP session is created, it sends an Open message with an
   OPEN Object containing the NRP-CAPABILITY TLV.  The format of this
   TLV is as follows:

     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=TBD2        |            Length=4           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                             Flags                           |D|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        Figure 2: NRP CAPABILITY TLV

   The type (16 bits) of the TLV is TBA.  The length field is 16 bits
   long and has a fixed value of 4.

   The value comprises a single field -- Flags (32 bits):

   *  D (Data Plane NRP ID CAPABILITY - 1 bit): if set to 1 by a PCC,
      the D flag indicates that the PCC supports the encapsulation of
      data plane NRP ID in data packet; if set to 1 by a PCE, it
      indicates that the PCE supports to provide path computation result
      with the data plane NRP ID used for the path.

   *  Unassigned bits in the Flags field MUST be set to zero on
      transmission and ignored on receipt.

3.  Operations

   The NRP TLV defined in this document can be used for NRP-aware TE
   path computation, NRP-specific path status report and NRP-specific
   path instantiation, thus it is applicable to both the basic PCE
   mechanisms and the stateful PCE mechanisms.





Dong, et al.               Expires 10 May 2026                  [Page 5]

Internet-Draft           PCEP Extensions for NRP           November 2025


3.1.  NRP-aware Path Computation

   NRP-aware TE path computation SHOULD be performed based on the
   constraints and network resources associated with a specific NRP.
   Information about the NRP-specific network resource and topology
   attributes may be obtained by the PCE either from the network
   planning system, or using a distributed control plane such as IGP or
   BGP-LS with necessary extensions.  The detailed mechanism is out of
   the scope of this document.

   In a PCReq message, the NRP TLV SHOULD be carried in the LSPA Object
   to indicate that the path computation needs to be executed using the
   network resource and topological attributes of the NRP.  The PCE
   SHOULD use the network resource and topology attributes associated
   with the specified NRP as the parameters in path computation.  In a
   PCRep message, the NRP TLV MAY be carried in the LSPA Object in case
   of failure to indicate the path computation in the specified NRP was
   not successful.

3.2.  NRP-specific Path Update and Report

   The NRP TLV defined in this document can be used for NRP-specific
   path update and report in the stateful PCE mechanisms.

   A PCE MAY include the NRP TLV in PCUpd Message to indicate the NRP in
   which the TE path needs to be updated.  The NRP ID SHOULD be the same
   as the NRP ID of the existing TE path.  If a PCC receives an PCUpd
   message in which the NRP ID does not match with the NRP ID of the
   path, the PCC MUST keep the LSP state unchanged, and include an LSP
   Error Code value of "NRP Mismatch" (TBD3) in LSP State Report
   message.  On successful update of a TE path, the NRP TLV SHOULD be
   included in the PCRpt message to indicate the NRP in which the TE
   path is reported.

3.3.  NRP-specific Path Initiation

   The NRP TLV defined in this document can be used for NRP-specific
   path initiation in the PCE-Initiated LSP mechanisms.













Dong, et al.               Expires 10 May 2026                  [Page 6]

Internet-Draft           PCEP Extensions for NRP           November 2025


   In a PCInitiate message, the NRP TLV MAY be included to indicate the
   NRP in which the path needs to be initiated.  Depending on the
   setting of the D flag in the NRP Capability, the PCC will use either
   the resources-aware SIDs associated with the NRP or the data plane
   NRP ID in constructing the NRP specific TE path.  If the PCC
   determines that the LSP parameters proposed in the PCInitiate message
   are unacceptable, it MUST send a PCErr message with Error-type=24
   (PCE instantiation error) and Error-value=1 (Unacceptable
   instantiation parameters).  On successful completion of the LSP
   instantiation, the NRP TLV SHOULD be included in the PCRpt message to
   indicate the NRP in which the TE path was instantiated.

4.  Scalability Considerations

   The mechanism described in this document adds NRP-specific
   information to PCEP.  NRP-specific constraints may be considered in
   path computation of PCE, and in path instantiation, path update and
   report, a TE path may be associated with an NRP ID.  As the number of
   NRP increases, the number of PCEP messages exchanged between PCC and
   PCE would also increase.  However, since the PCEP messages are
   exchanged only between the PCCs and PCE, the impacts to the control
   plane of PCC and PCE are considered acceptable.

5.  Security Considerations

   This document defines a new NRP TLV that do not add any new security
   concerns beyond those discussed in [RFC5440] in itself.  Some
   deployments may find the NRP information to be extra sensitive and
   could be used to influence path computation and setup with adverse
   effect.  Additionally, snooping of PCEP messages with such data or
   using PCEP messages for network reconnaissance may give an attacker
   sensitive information about the operations of the network.  Thus,
   such deployment should employ suitable PCEP security mechanisms like
   TCP Authentication Option (TCP-AO) [RFC5925] or Transport Layer
   Security (TLS) [RFC8253].  The procedure based on TLS is considered a
   security enhancement and thus is much better suited for the sensitive
   information.

6.  IANA Considerations

   This document makes following requests to IANA for action.

   IANA is requested to make the following allocations in the "PCEP TLV
   Type Indicators" subregistry of the "Path Computation Element
   Protocol (PCEP) Numbers" registry:






Dong, et al.               Expires 10 May 2026                  [Page 7]

Internet-Draft           PCEP Extensions for NRP           November 2025


               Value      Description        Reference
               -----    ----------------     -------------
                TBD1         NRP             This document
                TBD2     NRP CAPABILITY      This document

   IANA is requested to allocate a new error code in the "LSP-ERROR-CODE
   TLV Error Code Field" sub-registry of the "Path Computation Element
   Protocol (PCEP) Numbers" registry:

               Value      Description        Reference
               -----    ----------------     -------------
                TBD3     NRP Mismatch        This document

7.  Contributors

   Dhruv Dhody
   Email: dhruv.ietf@gmail.com

   Zhibo Hu
   Email: huzhibo@huawei.com

8.  Acknowledgments

   The authors would like to thank Zhenbin Li for his review and
   valuable comments.

9.  References

9.1.  Normative References

   [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>.

   [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>.

   [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>.








Dong, et al.               Expires 10 May 2026                  [Page 8]

Internet-Draft           PCEP Extensions for NRP           November 2025


   [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>.

   [RFC8281]  Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path
              Computation Element Communication Protocol (PCEP)
              Extensions for PCE-Initiated LSP Setup in a Stateful PCE
              Model", RFC 8281, DOI 10.17487/RFC8281, December 2017,
              <https://www.rfc-editor.org/info/rfc8281>.

   [RFC8664]  Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W.,
              and J. Hardwick, "Path Computation Element Communication
              Protocol (PCEP) Extensions for Segment Routing", RFC 8664,
              DOI 10.17487/RFC8664, December 2019,
              <https://www.rfc-editor.org/info/rfc8664>.

   [RFC9350]  Psenak, P., Ed., Hegde, S., Filsfils, C., Talaulikar, K.,
              and A. Gulko, "IGP Flexible Algorithm", RFC 9350,
              DOI 10.17487/RFC9350, February 2023,
              <https://www.rfc-editor.org/info/rfc9350>.

   [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.  Informative References

   [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>.

   [RFC4657]  Ash, J., Ed. and J.L. Le Roux, Ed., "Path Computation
              Element (PCE) Communication Protocol Generic
              Requirements", RFC 4657, DOI 10.17487/RFC4657, September
              2006, <https://www.rfc-editor.org/info/rfc4657>.

   [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>.






Dong, et al.               Expires 10 May 2026                  [Page 9]

Internet-Draft           PCEP Extensions for NRP           November 2025


   [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>.

   [RFC5925]  Touch, J., Mankin, A., and R. Bonica, "The TCP
              Authentication Option", RFC 5925, DOI 10.17487/RFC5925,
              June 2010, <https://www.rfc-editor.org/info/rfc5925>.

   [RFC8253]  Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody,
              "PCEPS: Usage of TLS to Provide a Secure Transport for the
              Path Computation Element Communication Protocol (PCEP)",
              RFC 8253, DOI 10.17487/RFC8253, October 2017,
              <https://www.rfc-editor.org/info/rfc8253>.

   [RFC9732]  Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A
              Framework for NRP-Based Enhanced Virtual Private
              Networks", RFC 9732, DOI 10.17487/RFC9732, March 2025,
              <https://www.rfc-editor.org/info/rfc9732>.

   [I-D.ietf-spring-resource-aware-segments]
              Dong, J., Miyasaka, T., Zhu, Y., Qin, F., and Z. Li,
              "Introducing Resource Awareness to SR Segments", Work in
              Progress, Internet-Draft, draft-ietf-spring-resource-
              aware-segments-15, 3 September 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-spring-
              resource-aware-segments-15>.

   [I-D.ietf-spring-sr-for-enhanced-vpn]
              Dong, J., Miyasaka, T., Zhu, Y., Qin, F., and Z. Li,
              "Segment Routing based Network Resource Partition (NRP)
              for Enhanced VPN", Work in Progress, Internet-Draft,
              draft-ietf-spring-sr-for-enhanced-vpn-09, 10 June 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-spring-
              sr-for-enhanced-vpn-09>.

   [I-D.ietf-6man-enhanced-vpn-vtn-id]
              Dong, J., Li, Z., Xie, C., Ma, C., and G. S. Mishra,
              "Carrying Network Resource (NR) related Information in
              IPv6 Extension Header", Work in Progress, Internet-Draft,
              draft-ietf-6man-enhanced-vpn-vtn-id-13, 20 October 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-6man-
              enhanced-vpn-vtn-id-13>.

   [I-D.ietf-teas-nrp-scalability]
              Dong, J., Li, Z., Gong, L., Yang, G., and G. S. Mishra,
              "Scalability Considerations for Network Resource



Dong, et al.               Expires 10 May 2026                 [Page 10]

Internet-Draft           PCEP Extensions for NRP           November 2025


              Partition", Work in Progress, Internet-Draft, draft-ietf-
              teas-nrp-scalability-08, 20 October 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-teas-
              nrp-scalability-08>.

Authors' Addresses

   Jie Dong
   Huawei Technologies
   Huawei Campus, No. 156 Beiqing Rd.
   Beijing
   100095
   China
   Email: jie.dong@huawei.com


   Sheng Fang
   Huawei Technologies
   Huawei Campus, No. 156 Beiqing Rd.
   Beijing
   100095
   China
   Email: fangsheng@huawei.com


   Quan Xiong
   ZTE Corporation
   No. 6 Huashi Park Rd
   Wuhan
   Hubei, 430223
   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


   Liuyan Han
   China Mobile
   Beijing
   China
   Email: hanliuyan@chinamobile.com



Dong, et al.               Expires 10 May 2026                 [Page 11]

Internet-Draft           PCEP Extensions for NRP           November 2025


   Minxue Wang
   China Mobile
   Beijing
   China
   Email: wangminxue@chinamobile.com


   Vishnu Pavan Beeram
   Juniper Networks
   Email: vbeeram@juniper.net


   Tarek Saad
   Cisco Systems
   Email: tsaad.net@gmail.com




































Dong, et al.               Expires 10 May 2026                 [Page 12]
