]> Huawei Technologies

Huawei Campus, No. 156 Beiqing Rd. Beijing 100095 China jie.dong@huawei.com

Huawei Technologies

Huawei Campus, No. 156 Beiqing Rd. Beijing 100095 China zhangli344@huawei.com

ZTE Corporation

No. 6 Huashi Park Rd Wuhan Hubei 430223 China xiong.quan@zte.com.cn

ZTE Corporation

No. 50 Software Avenue Nanjing Jiangsu 210012 China peng.shaofu@zte.com.cn

China Mobile

Beijing China hanliuyan@chinamobile.com

China Mobile

Beijing China wangminxue@chinamobile.com

Juniper Networks

vbeeram@juniper.net

Cisco Systems

tsaad.net@gmail.com

Individual

Beijing China fang_sheng@163.com

Routing PCE Working Group Internet-Draft 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.

Introduction 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 , 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. specifies a set of extensions to PCEP to enable stateful control of TE LSPs within and across PCEP sessions in compliance with . 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 . 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 , 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 . 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. 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 , or a data plane NRP Selector ID as defined in . The logical topology associated with an NRP could be specified using mechanisms such as Multi-Topology , or Flex-Algo , etc. To meet specific service requirement, traffic flows of an RFC 9543 network slice service need be steered to 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 mechanisms to indicate the NRP-specific constraints and information needed in path computation, path status report and path initialization.

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.

PCEP Extensions

NRP 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:

NRP ID TLV Format

Where:

• NRP ID: A 32-bit identifier in the control plane which uniquely identifies an NRP in an NRP domain . Value 0 is reserved, which MUST NOT be used by the sender.
• 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.
• 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.

If a PCEP speaker receives an NRP TLV with NRP ID = 0 in a message, it SHOULD ignore that TLV and its sub-TLVs, and proceed to process the remainder of the message normally.

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:

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.

The PCEP extensions for NRP MUST NOT be used and MUST be ignored upon receipt if either PCEP speaker has not included the NRP-CAPABILITY TLV in its OPEN message.

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.

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.

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 a PCUpd message to indicate the NRP in which the TE path needs to be updated. If the NRP ID carried in the PCUpd message differs from the NRP ID of the existing TE path, it indicates an intent to update the associated NRP of that TE path. Upon receiving such a PCUpd message, the PCC SHOULD update the LSP's NRP accordingly and proceed with the path update. 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. If a PCE intends to remove the NRP associated with an LSP, it SHOULD send a new PCUpd message that carries the same LSP but omits the NRP TLV,thereby indicating that the NRP for that LSP has been deleted.

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

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.

Security Considerations This document defines a new NRP TLV that do not add any new security concerns beyond those discussed in 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) or Transport Layer Security (TLS) . The procedure based on TLS is considered a security enhancement and thus is much better suited for the sensitive information.

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:

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

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

References Normative References This document specifies the Path Computation Element (PCE) Communication Protocol (PCEP) for communications between a Path Computation Client (PCC) and a PCE, or between two PCEs. Such interactions include path computation requests and path computation replies as well as notifications of specific states related to the use of a PCE in the context of Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering. PCEP is designed to be flexible and extensible so as to easily allow for the addition of further messages and objects, should further requirements be expressed in the future. [STANDARDS-TRACK] The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Client (PCC) requests. Although PCEP explicitly makes no assumptions regarding the information available to the PCE, it also makes no provisions for PCE control of timing and sequence of path computations within and across PCEP sessions. This document describes a set of extensions to PCEP to enable stateful control of MPLS-TE and GMPLS Label Switched Paths (LSPs) via PCEP. The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Client (PCC) requests. The extensions for stateful PCE provide active control of Multiprotocol Label Switching (MPLS) Traffic Engineering Label Switched Paths (TE LSPs) via PCEP, for a model where the PCC delegates control over one or more locally configured LSPs to the PCE. This document describes the creation and deletion of PCE-initiated LSPs under the stateful PCE model. Segment Routing (SR) enables any head-end node to select any path without relying on a hop-by-hop signaling technique (e.g., LDP or RSVP-TE). It depends only on "segments" that are advertised by link-state Interior Gateway Protocols (IGPs). An SR path can be derived from a variety of mechanisms, including an IGP Shortest Path Tree (SPT), an explicit configuration, or a Path Computation Element (PCE). This document specifies extensions to the Path Computation Element Communication Protocol (PCEP) that allow a stateful PCE to compute and initiate Traffic-Engineering (TE) paths, as well as a Path Computation Client (PCC) to request a path subject to certain constraints and optimization criteria in SR networks. This document updates RFC 8408. IGP protocols historically compute the best paths over the network based on the IGP metric assigned to the links. Many network deployments use RSVP-TE or Segment Routing - Traffic Engineering (SR-TE) to steer traffic over a path that is computed using different metrics or constraints than the shortest IGP path. This document specifies a solution that allows IGPs themselves to compute constraint-based paths over the network. This document also specifies a way of using Segment Routing (SR) Prefix-SIDs and SRv6 locators to steer packets along the constraint-based paths. This document describes network slicing in the context of networks built from IETF technologies. It defines the term "IETF Network Slice" to describe this type of network slice and establishes the general principles of network slicing in the IETF context. The document discusses the general framework for requesting and operating IETF Network Slices, the characteristics of an IETF Network Slice, the necessary system components and interfaces, and the mapping of abstract requests to more specific technologies. The document also discusses related considerations with monitoring and security. This document also provides definitions of related terms to enable consistent usage in other IETF documents that describe or use aspects of IETF Network Slices. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References Constraint-based path computation is a fundamental building block for traffic engineering systems such as Multiprotocol Label Switching (MPLS) and Generalized Multiprotocol Label Switching (GMPLS) networks. Path computation in large, multi-domain, multi-region, or multi-layer networks is complex and may require special computational components and cooperation between the different network domains. This document specifies the architecture for a Path Computation Element (PCE)-based model to address this problem space. This document does not attempt to provide a detailed description of all the architectural components, but rather it describes a set of building blocks for the PCE architecture from which solutions may be constructed. This memo provides information for the Internet community. The PCE model is described in the "PCE Architecture" document and facilitates path computation requests from Path Computation Clients (PCCs) to Path Computation Elements (PCEs). This document specifies generic requirements for a communication protocol between PCCs and PCEs, and also between PCEs where cooperation between PCEs is desirable. Subsequent documents will specify application-specific requirements for the PCE communication protocol. This memo provides information for the Internet community. This document describes an extension to Open Shortest Path First (OSPF) in order to define independent IP topologies called Multi- Topologies (MTs). The Multi-Topologies extension can be used for computing different paths for unicast traffic, multicast traffic, different classes of service based on flexible criteria, or an in- band network management topology. An optional extension to exclude selected links from the default topology is also described. [STANDARDS-TRACK] This document describes an optional mechanism within Intermediate System to Intermediate Systems (IS-ISs) used today by many ISPs for IGP routing within their clouds. This document describes how to run, within a single IS-IS domain, a set of independent IP topologies that we call Multi-Topologies (MTs). This MT extension can be used for a variety of purposes, such as an in-band management network "on top" of the original IGP topology, maintaining separate IGP routing domains for isolated multicast or IPv6 islands within the backbone, or forcing a subset of an address space to follow a different topology. [STANDARDS-TRACK] This document specifies the TCP Authentication Option (TCP-AO), which obsoletes the TCP MD5 Signature option of RFC 2385 (TCP MD5). TCP-AO specifies the use of stronger Message Authentication Codes (MACs), protects against replays even for long-lived TCP connections, and provides more details on the association of security with TCP connections than TCP MD5. TCP-AO is compatible with either a static Master Key Tuple (MKT) configuration or an external, out-of-band MKT management mechanism; in either case, TCP-AO also protects connections when using the same MKT across repeated instances of a connection, using traffic keys derived from the MKT, and coordinates MKT changes between endpoints. The result is intended to support current infrastructure uses of TCP MD5, such as to protect long-lived connections (as used, e.g., in BGP and LDP), and to support a larger set of MACs with minimal other system and operational changes. TCP-AO uses a different option identifier than TCP MD5, even though TCP-AO and TCP MD5 are never permitted to be used simultaneously. TCP-AO supports IPv6, and is fully compatible with the proposed requirements for the replacement of TCP MD5. [STANDARDS-TRACK] The Path Computation Element Communication Protocol (PCEP) defines the mechanisms for the communication between a Path Computation Client (PCC) and a Path Computation Element (PCE), or among PCEs. This document describes PCEPS -- the usage of Transport Layer Security (TLS) to provide a secure transport for PCEP. The additional security mechanisms are provided by the transport protocol supporting PCEP; therefore, they do not affect the flexibility and extensibility of PCEP. This document updates RFC 5440 in regards to the PCEP initialization phase procedures. This document describes a framework for Enhanced Virtual Private Networks (VPNs) based on Network Resource Partitions (NRPs) in order to support the needs of applications with specific traffic performance requirements (e.g., low latency, bounded jitter). NRP-based enhanced VPNs leverage the VPN and Traffic Engineering (TE) technologies and add characteristics that specific services require beyond those provided by conventional VPNs. Typically, an NRP-based enhanced VPN will be used to underpin network slicing, but it could also be of use in its own right providing enhanced connectivity services between customer sites. This document also provides an overview of relevant technologies in different network layers and identifies some areas for potential new work. Huawei Technologies KDDI Corporation China Telecom China Mobile China Mobile This document describes a mechanism to allocate network resources to one or a set of Segment Routing Identifiers (SIDs). Such SIDs are referred to as resource-aware SIDs. The resource-aware SIDs retain their original forwarding semantics, with the additional semantics to identify the set of network resources available for the packet processing and forwarding action. This mechanism is applicable to both segment routing with MPLS data plane (SR-MPLS) and segment routing with IPv6 data plane (SRv6). Huawei Technologies KDDI Corporation China Telecom China Mobile China Mobile Enhanced VPNs aim to deliver VPN services with enhanced characteristics, such as guaranteed resources, latency, jitter, etc., so as to support customers requirements on connectivity services with these enhanced characteristics. Enhanced VPN requires integration between the overlay VPN connectivity and the characteristics provided by the underlay network. A Network Resource Partition (NRP) is a subset of the network resources and associated policies on each of a connected set of links in the underlay network. An NRP could be used as the underlay to support one or a group of enhanced VPN services. Segment Routing (SR) leverages the source routing paradigm. A node steers a packet through an ordered list of instructions, called "segments". A segment is referred to by its Segment Identifier (SID). SIDs can represent topological or service based instructions. SIDs can further be associated with a set of network resources used for executing the instruction. Such SIDs are called resource-aware SIDs. A group of resource-aware SIDs may be used to build SR based NRPs, which provide the network topology and resource attributes required by one or a group of enhanced VPN services. This document describes an approach to build SR based NRPs using resource-aware SIDs. The SR based NRP can be used to deliver enhanced VPN services in SR networks. Huawei Technologies Huawei Technologies China Telecom China Telecom Verizon Inc. Virtual Private Networks (VPNs) provide different customers with logically separated connectivity over a common network infrastructure. With the introduction of 5G and also in some existing network scenarios, some customers may require network connectivity services with features that are more advanced compared to conventional VPN services. Such kind of network service is called enhanced VPNs. Enhanced VPNs can be used, for example, to deliver network slice services. A Network Resource Partition (NRP) is a subset of the network resources and associated policies on each of a connected set of links in the underlay network. An NRP may be used as the underlay to support one or a group of enhanced VPN services. For packet forwarding within a specific NRP, some fields in the data packet (these fields are called the NRP Selector) are used to identify the NRP to which the packet belongs. By identifying a packet with an NRP, NRP-specific processing can be performed on each node along the forwarding path in the NRP. This document specifies a new IPv6 Hop-by-Hop option to carry Network Resource related information in data packets. The new option is called the Network Resource (NR) Option. It can be used to carry an identifier of the NRP Selector, but it is designed to also be able to carry general information about network resource semantics and functions. Huawei Technologies Huawei Technologies China Mobile Verizon Inc. A network slice offers connectivity services to a network slice customer with specific Service Level Objectives (SLOs) and Service Level Expectations (SLEs) over a common underlay network. RFC 9543 describes a framework for network slices in networks built using IETF technologies. As part of that framework, the Network Resource Partition (NRP) is introduced as a subset of buffer/queuing/ scheduling resources that are allocated from the underlay network to carry a specific set of network slice service traffic and meet the requested SLOs and SLEs. As the demand for network slices increases, scalability becomes an important factor. Although the scalability of network slices can be improved by mapping a group of network slices to a single NRP, that design may not be suitable or possible for all deployments, thus there are concerns about the scalability of NRPs themselves. This document discusses some considerations for NRP scalability in the control and data planes. It also investigates a set of optimization mechanisms. Cisco Systems Inc. HPE Huawei Technologies HPE ZTE Corporation Realizing network slices may require the Service Provider to have the ability to partition a physical network into multiple logical networks of varying sizes, structures, and functions so that each slice can be dedicated to specific services or customers. Multiple network slices can be realized on the same network while ensuring slice elasticity in terms of network resource allocation. This document describes a scalable solution to realize network slicing in IP/MPLS networks by supporting multiple services on top of a single physical network by requiring compliant domains and nodes to provide forwarding treatment (scheduling, drop policy, resource usage) based on slice identifiers.

Contributors

dhruv.ietf@gmail.com

huzhibo@huawei.com