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

Juniper Networks

vbeeram@juniper.net

Juniper Networks

tsaad@juniper.net

Routing PCE This document proposes a set of extensions for PCEP to support the identifier of Network Resource Partition (NRP-ID) as the constraint of network slicing during path computation.

Introduction describes the Path Computation Element 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. The constraint parameters are provided such as metric, bandwidth, delay, affinity, etc. However these parameters can't meet the network slicing requirements. According to 5G context, network slicing is the collection of a set of technologies to support network service differentiation and meeting the diversified requirements from vertical industries. As defined in , an IETF network slice is a logical network topology connecting a number of endpoints using a set of shared or dedicated network resources that are used to satisfy specific Service Level Objectives (SLOs). As defined in , a Network Resource Partition (NRP) is a collection of resources (bufferage, queuing, scheduling, etc.) in the underlay network to support the IETF Network Slice service (or any other service that needs logical network structures with required characteristics to be created). And as per , NRP Identifier (NRP-ID) indicates an identifier that is globally unique within an NRP domain and that can be used in the control or management plane to identify the resources associated with the NRP. The NRP-ID could be used to identify the slice and network resource and viewed as constraints of network slicing when PCE is deployed. PCE MUST take the identifier of slicing into consideration during path computation. This document proposes a set of extensions for PCEP to support the NRP-ID as the constraint of network slicing during path computation.

Conventions used in this document

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.

PCEP Extensions for Network Resource Partition As defined in , the LSPA object is used to specify the LSP attributes to be taken into account by the PCE during path computation such as constraints. This document proposes new TLV for the LSPA object to carry TE constraints for network slicing.

NRP-ID TLV The NRP-ID TLV is optional and is defined to carry the slice specific constraint. PCEP message needs to carry NRP-ID to limit the network resources for path calculation within a NRP domain. The format of the NRP-ID TLV is shown as Figure 1:

Figure 1: NRP-ID TLV

The code point for the TLV type is TBD1. The TLV length is 4 octets. NRP-ID (32 bits): indicates a NRP Identifier as defined in .

Protocol Operation As defined in , NRP state aware TE (NRP-TE) should implement the TE path selection that takes into account the available network resources associated with a specific NRP. The NRP-ID TLV should be carried in PCEP messages when computing NRP state aware TE paths. The PCE may maintain network resources per path and the NRP state within the resource pool identified by NRP-ID. In a PCReq message, a PCC MAY request the PCC to compute the NRP-TE path and insert a NRP-ID TLV to indicate the resources within a NRP domain. The PCE will perform path computation based on the intra-domain or inter- domain sub-topology identified by the specific NRP-ID, that can be used to find the corresponding customized topology or referenced topology, and corresponding resources. The PCE may reply the PCC with NRP-ID TLV carried in PCRep message and the headend may insert the NRP-ID into an encapsulated data packet. In case of unsuccessful path computation when the NRP-ID constraint could not be satisfied, the the PCRep message may contain a NO-PATH object. In a PCInit/PCUpd message, the PCE MAY compute the optimal NRP-TE path and carry the NRP-ID TLV so as to provide the network slicing information. If a PCC is unable to recognize a NRP-ID value passed in an LSP PCInit/PCUpd request, the PCC must keep the LSP in DOWN state, and include an LSP Error Code value of "Unsupported NRP" [Value to be assigned by IANA] in LSP State Report message.

Security Considerations TBA

Acknowledgements TBA

IANA Considerations IANA is requested to make allocations from the registry, as follows:

Type	TLV	Reference
TBD1	NRP-ID TLV	[this document]

Normative References 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. 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] 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. 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. 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. Nokia NTT Futurewei Telefonica Juniper Networks This document provides a definition of the term "IETF Network Slice" for use within the IETF and specifically as a reference for other IETF documents that describe or use aspects of network slices. The document also describes the characteristics of an IETF network slice, related terms and their meanings, and explains how IETF network slices can be used in combination with end-to-end network slices or independent of them. Juniper Networks Juniper Networks Huawei Technologies Comcast Ericsson Ericsson ZTE Corporation ZTE Corporation Volta Networks Telefonica Ciena Verizon 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 relying on compliant domains and nodes to provide forwarding treatment (scheduling, drop policy, resource usage) on to packets that carry identifiers that indicate the slicing service that is to be applied to the packets. Old Dog Consulting Juniper Networks Ciena NTT Futurewei Telefonica Microsoft Inc. This document describes network slicing in the context of networks built from IETF technologies. It defines the term "IETF 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 how abstract requests can be mapped 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.