Internet-Draft PCECC for NRP November 2026
Dong, et al. Expires 6 May 2027 [Page]
Workgroup:
PCE Working Group
Internet-Draft:
draft-dong-pce-cc-nrp-00
Published:
Intended Status:
Standards Track
Expires:
Authors:
J. Dong
Huawei Technologies
P. Yu
Huawei Technologies
L. Zhang
Huawei Technologies

PCEP Extensions for PCE Central Controller (PCECC) based Network Resource Partition (NRP) Instantiation

Abstract

The PCE is a core component of Software-Defined Networking (SDN) systems. A PCE-based Central Controller (PCECC) can simplify the processing of a distributed control plane by blending it with elements of SDN without necessarily completely replacing it.

Network Resource Partitions (NRPs) can be used to provide the required connectivity and commited resources for network slice services. An 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.

This document specifies the extensions to Path Computation Element Communication Protocol (PCEP) to enable PCECC based Network Resource Partition (NRP) Instantiation.

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 6 May 2027.

▲

Table of Contents

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

[RFC8283] introduces the architecture for PCE as a central controller (PCECC) as an extension of the architecture described in [RFC4655] and assumes the continued use of PCEP as the protocol used between PCE and PCC. [RFC8283] further examines the motivations and applicability for PCEP as a Southbound Interface (SBI), and introduces the implications for the protocol. [RFC9689] describes the use cases for the PCECC architecture.

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

The NRPs and the set of network resources allocated to them can be instantiated by a central controller. PCECC can be used for the instantiation of NRP in the underlay network. This document specifies the extensions to Path Computation Element Communication Protocol (PCEP) to enable PCECC based Network Resource Partition (NRP) Instantiation.

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 for NRP Instantiation

2.1. PCECC Capability Advertisement

During the PCEP initialization phase, PCEP speakers (PCE or PCC) advertise their support of and willingness to use PCEP extensions for the PCECC. A PCEP speaker includes the PCECC-CAPABILITY sub-TLV in the PATH-SETUP-TYPE-CAPABILITY TLV as per [RFC9050]. To indicate whether a PCE or PCC supports PCECC based resource reservation, a new bit (the R bit) in the PCECC-CAPABILITY sub-TLV is defined.

  • R bit (Resource reservation): If set to '1' by a PCEP speaker, the R flag indicates that the PCEP speaker supports and is willing to handle the PCECC-based resource reservation. The bit MUST be set to '1' by both a PCC and a PCE for PCECC resource reservation and report on a PCEP session.

2.2. FEC Object

The FEC Object as defined in [I-D.ietf-pce-pcep-extension-pce-controller-sr] is used to specify the FEC information of the PCECC instruction. [I-D.ietf-pce-pcep-extension-pce-controller-sr] defines multiple FEC Object-Types for the instantiation of SR SIDs. In the context of NRP instantiation, the following FEC Object-Type can be used to identify the link on which the NRP resource is instantiated.

+-----------+-------------------------------------+------------------+
|    FEC    |              Description            |   Reference      |
|Object-Type|                                     |                  |
+-----------+-------------------------------------+------------------+
|    3      |IPv4 Adjacency                       |I-D.ietf-pce-pcep-|
|    4      |IPv6 Global Adjacency                | extension-pce-   |
|    5      |Unnumbered Adjacency with IPv4 NodeID| controller-sr    |
|    6      |IPv6 Linklocal Adjacency             |                  |
+-----------+-------------------------------------+------------------+
Figure 1: FEC Object-Types for NRP Instantiation

2.3. CCI Object

The Central Controller Instructions (CCI) object is used by the PCE to specify the instructions to the PCC. A new CCI Object-Type for Resource Reservation is defined, which MAY be carried within a PCInitiate or PCRpt message for NRP instantiation and report respectively. The new CCI Object-type is TBA. The format of this CCI Object-Type 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            CC-ID                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            Flags              |           Reserved            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                          Optional TLVs                        ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 2: CCI Object Type for Resource Reservation

Where:

  • CC-ID: A unique identifier for the CCI in PCEP as described in [RFC9050].

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

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

  • Optional TLVs: Used to carry resource reservation related instruction and information.

2.3.1. NRP Instantiation TLV

A new TLV is defined to instruct to instantiate NRP on a specified link. The format of the NRP Instantiation 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 = TBD            |       Length (variable)       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   NRP Type    |   Flags     |E|           Reserved            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             NRP ID                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                        Optional sub-TLVs                      ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: NRP Instantiation TLV

Where:

  • NRP Type: Type of the NRP instantiation. The following type is defined in this document.

    • Type 1: Queue based partition. In this case, the NRP is instantiated using a dedicated queue.

  • Flags: 8-bit flags field. The most significant bit is defined as the E (Exclusive) bit. When the E bit is set, it indicates that dedicated resource is allocated to the NRP. The rest of the bits MUST be set to zero on transmission and MUST be ignored on receipt.

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

  • NRP ID: A 32-bit NRP identifier globally unique within an NRP domain, as defined in [I-D.ietf-teas-ns-ip-mpls].

  • Optional sub-TLVs: Used to carry resource information of the NRP.

One or multiple NRP Instantiation TLVs MAY be carried in the CCI Object with CCI-Type NRP Instantitaion. The NRP ID in each NRP Instantiation TLV MUST NOT be the same.

2.3.2. Bandwidth Reservation Sub-TLV

When NRP Type is set to 1 (Queue based partition), A new Bandwidth Reservation sub-TLV is used to describe the bandwidth reserved for the NRP on the link specified by the corresponding FEC Object.

 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 = TBD            |       Length (variable)       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            Flags              |         Reserved              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               Committed Information Rate (CIR)                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 Peak Information Rate (PIR)                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Bandwidth Reservation sub-TLV

Where:

  • Flags: 8-bit flags. Currently the most significant bit is defined as the E (Exclusive) bit. When the E bit is set, it indicates that dedicated resource is allocated. The rest bits of this field MUST be set to zero on transmission and MUST be ignored on receipt.

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

  • Committed Information Rate (CIR): Commited bandwidth in 4-byte floating-point number, the unit is bits per second.

  • Peak Information Rate (PIR): Peak bandwidth allocated from the link in 4-byte floating-point number, the unit is bits per second.

The Bandwidth Reservation sub-TLV MUST appear only once in the NRP Instantiation TLV.

3. Operations

The general operation of PCECC is specified in [RFC9050]. This section describes the PCECC Operation for NRP Instantiation.

An NRP is instantiated by allocating a subset of network resources on the network links of PCCs which participate in the NRP. This is achieved by PCE instructing the PCCs to allocate the required network resources on the specified links which are part of the NRP.

When both the PCE and PCC advertise the PCECC capability with N bit set, the PCE sends a PCInitiate message to the PCC, with the PST set to '2' for the PCECC. The CCI Object-Type MUST be set to NRP instantiation. The FEC Object [I-D.ietf-pce-pcep-extension-pce-controller-sr] is used to identify the link on which the NRP and the set of resources need to be instantiated. The LSP Object MUST be present, in which the PLSP-ID MUST be set to the reserved value zero, as the NRP instantiation is not specific to any LSP. In the CCI Object, the NRP ID and the amount of resources (e.g., bandwidth) to be allocated to the NRP are specified.

On receipt of a PCInitiate message for the PCECC NRP instantiation, the PCC instantiates the NRP and reserves network resources on the specified link for the NRP, then it responds with a PCRpt message with the PLSP-ID in the LSP Object set to zero, the CC-ID in the CCI Object identifies the Central Controller Instruction in the PCInitiate message.

            +---+                                               +---+
            |PCE|                                               |PCC|
            +-+-+                                               +-+-+
              |                                                   |
  PCECC NRP   |--PCInitiate,PST=2,PLSP-ID=0,FEC=A,CC-ID=X,<NRP> ->|
Instantiation |<-------- PCRpt,PLSP-ID=0, CC-ID=X ----------------|
              |                                                   |
Figure 5

4. PCEP Messages

In the context of PCECC based NRP instantiation, the PCInitiate message [RFC8281] and PCRpt message [RFC8231] needs to be extended.

4.1. The PCInitiate Message

The format of the PCInitiate message for NRP Instantiation is as follows:

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

Where:

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

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

     <PCE-initiated-lsp-central-control> ::= <SRP>
                                             <LSP>
                                             <FEC><CCI>

4.2. The PCRpt Message

The format of the PCRpt message for NRP Instantiation result report is as follows:

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

Where:

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

      <state-report> ::= (<lsp-state-report>|
                          <central-control-report>)

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

      <central-control-report> ::= [<SRP>]
                                   <LSP>
                                   <FEC><CCI>

5. Security Considerations

This document defines a new CCI Object-Type that does not add any new security concerns beyond those discussed in [RFC5440] in itself. For network deployment in which NRP information is considered sensitive, the operator can 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

6.1. PCECC-CAPABILITY Sub-TLV

IANA is requested to allocate a new bit for "Resource Reservation" in the "PCECC-CAPABILITY sub-TLV Flag Field" sub-registry of the "Path Computation Element Protocol (PCEP) Numbers" registry.

   +======+======================+===============+
   | Bit  | Description          | Reference     |
   +======+======================+===============+
   | TBD1 | Resource Reservation | This document |
   +------+----------------------+---------------+

6.2. PCEP Objects

IANA is requested to assign a new Object-Type for "Resource reservation" under the CCI Object in the "PCEP Objects" sub-registry of the "Path Computation Element Protocol (PCEP) Numbers" registry.

  +====================+======+=======================+===========+
  | Object-Class Value | Name |     Object-Type       | Reference |
  +====================+======+=======================+===========+
  | 44                 | CCI  | TBD2:                 | This      |
  |                    |      | Resource Reservation  | document  |
  +--------------------+------+-----------------------+-----------+

6.3. PCEP TLV Type Indicators

IANA is requested to assign a new code point for "NRP Instantiation TLV" in the "PCEP TLV Type Indicators" sub-registry of the "Path Computation Element Protocol (PCEP) Numbers" registry.

IANA is requested to assign a new code point for "Bandwidth Reservation" in the "PCEP TLV Type Indicators" sub-registry of the "Path Computation Element Protocol (PCEP) Numbers" registry.

   +=============+=======================+===============+
   | Value       | Description           | Reference     |
   +=============+=======================+===============+
   | TBD3        | NRP Instantiation     | This document |
   +-------------+-----------------------+---------------+
   | TBD4        | Bandwidth Reservation | This document |
   +--------=----+-----------------------+---------------+

7. Contributors

TBD.

8. Acknowledgments

The authors would like to thank XXX 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, , <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, , <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, , <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, , <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, , <https://www.rfc-editor.org/info/rfc8281>.
[RFC8283]
Farrel, A., Ed., Zhao, Q., Ed., Li, Z., and C. Zhou, "An Architecture for Use of PCE and the PCE Communication Protocol (PCEP) in a Network with Central Control", RFC 8283, DOI 10.17487/RFC8283, , <https://www.rfc-editor.org/info/rfc8283>.
[RFC9050]
Li, Z., Peng, S., Negi, M., Zhao, Q., and C. Zhou, "Path Computation Element Communication Protocol (PCEP) Procedures and Extensions for Using the PCE as a Central Controller (PCECC) of LSPs", RFC 9050, DOI 10.17487/RFC9050, , <https://www.rfc-editor.org/info/rfc9050>.
[RFC9350]
Psenak, P., Ed., Hegde, S., Filsfils, C., Talaulikar, K., and A. Gulko, "IGP Flexible Algorithm", RFC 9350, DOI 10.17487/RFC9350, , <https://www.rfc-editor.org/info/rfc9350>.
[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-10, , <https://datatracker.ietf.org/doc/html/draft-ietf-teas-ns-ip-mpls-10>.
[I-D.ietf-pce-pcep-extension-pce-controller-sr]
Li, Z., Peng, S., Negi, M. S., and C. Zhou, "PCE Communication Protocol (PCEP) Extensions for Using PCE as a Central Controller (PCECC) for Segment Routing (SR) MPLS Segment Identifier (SID) Allocation and Distribution", Work in Progress, Internet-Draft, draft-ietf-pce-pcep-extension-pce-controller-sr-14, , <https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-extension-pce-controller-sr-14>.

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, , <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, , <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, , <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, , <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, , <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, , <https://www.rfc-editor.org/info/rfc8253>.
[RFC9689]
Li, Z., Dhody, D., Zhao, Q., Ke, Z., and B. Khasanov, "Use Cases for a PCE as a Central Controller (PCECC)", RFC 9689, DOI 10.17487/RFC9689, , <https://www.rfc-editor.org/info/rfc9689>.
[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, , <https://www.rfc-editor.org/info/rfc9543>.

Authors' Addresses

Jie Dong
Huawei Technologies
China
Pingping Yu
Huawei Technologies
China
Li Zhang
Huawei Technologies
China