TEAS Working Group X. Geng Internet-Draft Huawei Technologies Intended status: Informational L. M. Contreras, Ed. Expires: 12 December 2024 Telefonica R. Rokui Ciena J. Dong Huawei Technologies I. Bykov Ribbon Communications 10 June 2024 IETF Network Slice Application in 3GPP 5G End-to-End Network Slice draft-ietf-teas-5g-network-slice-application-03 Abstract Network Slicing is one of the core features of 5G defined in 3GPP, which provides different network service as independent logical networks. To provide 5G network slices services, an end-to-end network slice has to span three network segments: Radio Access Network (RAN), Mobile Core Network (CN) and Transport Network (TN). This document describes the application of the IETF network slice framework in providing 5G end-to-end network slices, including network slice mapping in the management, control and data planes. 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 12 December 2024. Copyright Notice Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. Geng, et al. Expires 12 December 2024 [Page 1] Internet-Draft IETF Network Slice Application in 3GPP 5 June 2024 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 3. 5G End-to-End Network Slice . . . . . . . . . . . . . . . . . 5 3.1. IETF Network Slices in Distributed RAN Deployment . . . . 6 3.2. IETF Network Slices in Centralized RAN Deployment . . . . 7 3.3. IETF Network Slices in Cloud RAN deployment (C-RAN) . . . 8 3.4. Relationship Between IETF Network Slices and 3GPP Network Slices . . . . . . . . . . . . . . . . . . . . . . . . . 9 4. 5G E2E Network Slice Mapping Procedure . . . . . . . . . . . 11 4.1. 5G E2E Network Slice Mapping Identifier . . . . . . . . . 11 4.2. 5G E2E Network Slice Mapping Procedure . . . . . . . . . 11 5. 5G E2E Network Slice Mapping in Management and Control Planes . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.1. Mapping EP_transport to IETF NS CE Endpoints . . . . . . 14 5.2. Mapping IETF NS CE to PE Endpoints . . . . . . . . . . . 15 6. Methods for Mapping Between 3GPP E2E Network Slice and IETF Network Slice . . . . . . . . . . . . . . . . . . . . . . 16 6.1. Mapping based on VLAN ID . . . . . . . . . . . . . . . . 19 6.2. Mapping based on MPLS Label or SR-MPLS SID . . . . . . . 20 6.3. Mapping based on SRv6 SID . . . . . . . . . . . . . . . . 21 6.4. Mapping based on Policy Based Routing (PBR) . . . . . . . 22 6.5. Mapping based on UDP Source Port . . . . . . . . . . . . 23 7. IETF Network Slice request through IETF Network Slice NBI . . 24 7.1. Example according to CE-mode (OPTION 1) . . . . . . . . . 29 7.2. Example according to PE-mode (OPTION 2) . . . . . . . . . 36 7.3. Example According to PE-mode with Meeting Point Extension of ACaaS (OPTION 3) . . . . . . . . . . . . . . . . . . . 41 8. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . 48 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49 10. Security Considerations . . . . . . . . . . . . . . . . . . . 49 11. Evolution Considerations . . . . . . . . . . . . . . . . . . 49 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 49 13. Annex 1: 3GPP Network Slice Mapping Parameters . . . . . . . 50 14. Annex 2: Data Plane Mapping Options . . . . . . . . . . . . . 56 14.1. Layer 3 and Layer 2 Encapsulations . . . . . . . . . . . 58 Geng, et al. Expires 12 December 2024 [Page 2] Internet-Draft IETF Network Slice Application in 3GPP 5 June 2024 14.1.1. Consideration of the Virtual Network Functions (VNF) . . . . . . . . . . . . . . . . . . . . . . . . 61 15. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 62 16.1. Normative References . . . . . . . . . . . . . . . . . . 62 16.2. Informative References . . . . . . . . . . . . . . . . . 63 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 67 1. Introduction Driven by the new applications, 3GPP introduced the concept of network slicing as a feature of its 5G specification. Such a concept is meant to provide a customized connectivity service with specific capabilities and characteristics. A network slice may include a set of network functions and resources(e.g. computation, storage and network resources). In the context of the IETF, the Network Slice Services are defined in [RFC9543] as a set of connections between a number of Service Demarcation Points (SDPs e.g., CE, PE, or NF), where these connections having specific Service Level Objectives (SLOs) and Service Level Expectations (SLEs) over a common underlay network, with the traffic of one customer being separated from another. The concept of IETF Network Slice Service is conceived as technology agnostic. Network Slice Services as defined in [RFC9543] are thus specified in terms of the set of SDPs connected to the slice, the type of connectivity among them, and a set of SLOs and SLEs for each connectivity construct. In [I-D.ietf-teas-ietf-network-slice-nbi-yang], the endpoints are identified by an identifier, with some metrics associated to the connections among them as well as certain policies (e.g., rate limits for incoming and outgoing traffic). The 5G network slice as defined by 3GPP in [TS-23.501] does not take the transport network slice into consideration. 3GPP introduces the concept of 5G end-to-end network slice service, which is built on top of three network segments: Radio Access Network (RAN), Transport Network (TN) and Core Network (CN). Transport network provides the required connectivity between RAN and CN or inside RAN/CN, with specific performance commitment. The 5G end-to-end network slice services may have distinct topology and performance requirements on the underlying transport network. The transport network should have thus capability to support multiple IETF network slices. The decision about the number of such IETF network slices is deployment specific. Geng, et al. Expires 12 December 2024 [Page 3] Internet-Draft IETF Network Slice Application in 3GPP 5 June 2024 This document focuses on the mapping between 5G network slices and the network slices in underlying Transport Networks. Specifically, the document describes how RFC9543 Network Slice Services can be derived in the context of a 3GPP Network Slice Service in management, control and data planes, including exploring how 3GPP Slice Service parameters are mapped to parameters that are exposed in IETF service data models. It is out of scope of this document to elaborate on the realization of IETF Network Slices as per [RFC9543]. The realizations of RFC9543 network slices are discussed in [I-D.ietf-teas-enhanced-vpn] [I-D.ietf-teas-nrp-scalability] [I-D.ietf-teas-ns-ip-mpls], and a realization model for network slicing in IP/MPLS networks for fuifilling 5G slicing connectivity services is discussed in [I-D.ietf-teas-5g-ns-ip-mpls]. 2. Terminology 2.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. This document uses the terms defined in [RFC9543]. The following abbreviations are used in this document: Geng, et al. Expires 12 December 2024 [Page 4] Internet-Draft IETF Network Slice Application in 3GPP 5 June 2024 NSC: IETF Network Slice Controller NSI: Network Slice Instance NSSI: Network Slice Subnet Instance S-NSSAI: Single Network Slice Selection Assistance Information RAN: Radio Access Network TN: Transport Network CN: Mobile Core Network DSCP: Differentiated Services Code Point CSMF: Communication Service Management Function NSMF: Network Slice Management Function NSSMF: Network Slice Subnet Management Function IOC: Information Object Class model, defined in 3GPP In addition to that, the following terms from 3GPP are also used: * EP_transport: 3GPP Information Object Class (IOC) defined in [TS-28.541] which, represents the logical transport interface of a RAN or CN and includes transport-related information with reference(s) to attachment circuit DM in IETF domain. * EP_RP: 3GPP IOC defined in [TS-28.622], provided for sub-classing only. This IOC represents an end point of a link used across a reference point between two network entities. Inherited by EP_NgU, EP_F1U, EP_S1U, EP_X2U, etc. 3. 5G End-to-End Network Slice The scope of a 5G End-to-End Network Slice service discussed in this document is shown in Figure 1. The transport networks (TN) provide the connectivity between and within RAN and CN. To support automated enablement of 5G E2E network slices, multiple controllers are likely to manage 5G E2E network slices across RAN, CN and TN. In addition, a 5G E2E network slice orchestrator is used to coordinate and control the overall creation and life cycle management of 5G E2E network slices across RAN, TN and CN. Geng, et al. Expires 12 December 2024 [Page 5] Internet-Draft IETF Network Slice Application in 3GPP 5 June 2024 <-------------------- 5G E2E Network Slice -------------------> |-----------------------------------------------------| | 5G E2E Network Slice Orchestrator | |-------|-------------------|-------------------|-----| | | | v v v |---------------| |------------| |--------------| | RAN Slice | | IETF | | CN Slice | | Controller | | NSC | | Controller | |-------|-------| |-----|------| |------|-------| | | | v v v ............................ .......................... : RAN : : CN : : : : : : |-----| |----| |-----| : |----| : |----| |----| |----| : : | RAN |--| TN |--| RAN |---| TN |---| CN |--| TN |--| CN | : : | NFs | |----| | NFs | : |----| : | NFs| |----| | NFs| : : |-----| |-----| : : |----| |----| : : : : : :..........................: :........................: Figure 1: Scope of 5G End to End Network Slice Depending on RAN deployment, a single 5G E2E network slice might have one or more IETF network slices. Depends on the operator's networks, one or more of the following RAN deployments might be used. With different RAN deployments, the scope of TN slice may be different. These RAN deployments are discussed in the following sections: * Distributed RAN * Centralized RAN * Cloud RAN (C-RAN) 3.1. IETF Network Slices in Distributed RAN Deployment Distributed RAN is the most common deployment of 3GPP RAN networks as shown in Figure 2. RAN is connected to CN using a transport network (TN1). In this deployment a single 5G E2E network slice might have one or more IETF network slices between RAN and CN networks. In addition, one or more IETF network slices might be present inside the CN network to provide the connectivity between CN network functions (e.g., AMF, CMF and UPF). Geng, et al. Expires 12 December 2024 [Page 6] Internet-Draft IETF Network Slice Application in 3GPP 5 June 2024 <-------------- 5G E2E Network Slice ------------> <---- RS---> <---------- CS ---------> <- INS1 -> <- INS2 -> (1 or more) (1 or more) ............. ......................... : RAN : : CN : : : ........ : ....... : : |-----| : : : : |----| : : |----| : : | NFs | : : TN1 : : | NFs| : TN2 : | NFs| : : |-----| : : : : |----| : : |----| : : : :......: : :.....: : :...........: :.......................: Legend INS: IETF Network Slice RS: RAN Slice CS: Core Slice Figure 2: IETF network slices in distributed RAN deployment 3.2. IETF Network Slices in Centralized RAN Deployment In general, the RAN network consists of network functions for processing the radio signal and transmitting/receiving the radio signal. As shown in Figure 3, in Centralized RAN deployment, two groups of network functions exit; NFs1 and NFs2 where NFs2 processes the carrier signal and is connected to the transport network and NFs1 transmit and receive the radio signal that is transmitted over the air from and to the end user equipment (UE). In Centralized RAN, network functions NFs1 and NFs2 are separated by a transport network TN3 called fronthaul network (FH). In this deployment a 5G E2E network slice contain of RAN and CN slices and one or more IETF network slices INS1, INS2 and INS3. INS1 and INS2 are identical to the IETF network slices shown in Figure 2. However, the IETF network slices INS3 needed across RAN network to provide the connectivity among NFs1 and NFs2. Geng, et al. Expires 12 December 2024 [Page 7] Internet-Draft IETF Network Slice Application in 3GPP 5 June 2024 <-------------------- 5G E2E Network Slice ------------------> <-------- RS ---------> <---------- CS ---------> <- INS3 -> <- INS1 -> <- INS2 -> (1 or more) (1 or more) (1 or more) ......................... ........................... : RAN : : CN : : ....... : ........ : ....... : : |----| : : |----| : : : : |-----| : : |-----| : : |NFs1| : TN3 : |NFs2| : : TN1 : : | NFs | : TN2 : | NFs | : : |----| :(FH) : |----| : : (BH) : : |-----| :(BH) : |-----| : : :.....: : :......: : :.....: : :.......................: :.........................: Legend INS: IETF Network Slice RS: RAN Slice CS: Core Slice FN: Fronthaul IETF network BH: Backhual IETF network Figure 3: IETF network slices in centralized RAN deployment 3.3. IETF Network Slices in Cloud RAN deployment (C-RAN) In a Cloud RAN deployment, the network function NF2 is further disaggregated into real-time and non-real-time components. As shown in Figure 4, these disaggregated components are called CU (Central Unit) and DU (Distributed Unit) where they are connected by a new network called Midhaul network (MH). In this deployment 3GPP network slice contains not only RAN and Core slices but IETF network slices INS1, INS2, INS3 and INS4. IETF network slices INS1, INS2 and INS3 are similar to those in Figure 3. An additional IETF network slice INS4 is used to connect the DUs to CUs through F1 interfaces. Geng, et al. Expires 12 December 2024 [Page 8] Internet-Draft IETF Network Slice Application in 3GPP 5 June 2024 <---------------------- 5G E2E Network Slice --------------------> <-------------- RS --------------> <------- CS ------> <- INS3 -> <- INS4 -> <- INS1 -> <- INS2 -> (1 or more) (1 or more) (1 or more) (1 or more) ...................................... ..................... : RAN : :CN : : ....... ...... : ...... : ..... : : |----| : : |---| : : |---| : : : : |---| : : |---| : : |NFs1| : TN3 : |DU | : TN4 : |CU | : : TN1: : |NFs| :TN2: |NFs| : : |----| :(FH) : |---| : (MH): |---| : :(BH): : |---| : : |---| : : :.....: :.....: : :....: : :...: : :....................................: :...................: Legend INS: IETF Network Slice RS: RAN Slice CS: Core Slice FN: Fronthaul IETF network MN: Midhaul IETF network BH: Backhual IETF network DU: Distributed Unit CU: Central Unit Figure 4: IETF network slices in cloud RAN deployment (C-RAN) For the sake of illustration, the following sections in this document all consider the TN slice between RAN and CN. Other IETF network slice cases are similar. 3.4. Relationship Between IETF Network Slices and 3GPP Network Slices Based on the Architecture of an IETF Network Slice and Interface of IETF Network Slice Management Architecture defined in [RFC9543], Figure 6 shows the relationship between 3GPP controllers and IETF Network Slice Controller. Geng, et al. Expires 12 December 2024 [Page 9] Internet-Draft IETF Network Slice Application in 3GPP 5 June 2024 +---------------------+ | CSMF | +----------|----------+ | +------------------------+ +---------------------+ | 5G E2E Network Slice | | NSMF | | Orchestrator | +---------------------+ +------------------------+ / | \ | / | \ IETF Network Slice Service Interface / | \ | +---------++---------++---------+ +------------------------+ | AN || TN || CN | | IETF Network Slice | | NSSMF || NSSMF || NSSMF | | Controller (NSC) | | || || | +------------------------+ +---------++---------++---------+ Network configuration interface | | | | | | | +------------------------+ | | | | Network Controllers | | | | +------------------------+ | | | | | | | | .?????. .???????. .???????. .?????????. ? 5G ? ? IETF ? ? 5G ? ? IETF ? ( RAN )( Network )( Core ) ( Network ) `. ,' `. ,' `. ,' `. ,' `???' `?????' `?????' `???????' Figure 5: Relationship between 3GPP domain controllers and IETF Network Slice Controller An example of 5G E2E Network Slice is showed in Figure 6. Each E2E network slice contains RAN slice, CN slice and one or more IETF network Slices. 3GPP identifies each E2E network slice using an integer called S-NSSAI. In Figure 6 there are three instances of E2E network slices which are identified by S-NSSAI 01111111, 02222222 and 03333333, respectively. Each instance of E2E network slice contains AN slice, CN Slice and one or more IETF network slices. For example, E2E network slice 01111111 has AN Slice instance 4, CN Slice instance 1 and IETF network slice 6. Note that 3GPP does not cover the IETF network slice. Details of IETF network slice could be found in [RFC9543]. Note that 3GPP uses the terms NSI and NSSI which are a set of network function and required resources (e.g. compute, storage and networking resources) which corresponds to network slice Instance, whereas S-NSSAI is an integer that identifies the E2E network slice. Geng, et al. Expires 12 December 2024 [Page 10] Internet-Draft IETF Network Slice Application in 3GPP 5 June 2024 +-----------+ +-----------+ +-----------+ | S-NSSAI | | S-NSSAI | | S-NSSAI | | 01111111 | | 02222222 | | 03333333 | +---|-------+ +---|---|---+ +----|------+ | +----------+ | | V V V V ********** ********** ********** Core * NSSI 1 * * NSSI 2 * * NSSI 3 * Network ********** ********** ********** \ \ / \ \ / +-----+ +-----+ +-----+ Transport | IETF| | IETF| | IETF| Network | NS 6| | NS 7| | NS 8| +-----+ +-----+ +-----+ \ \ / \ \ / Radio ********** ********** Access * NSSI 4 * * NSSI 5 * Network ********** ********** Figure 6: 5G End-to-End Network Slice and its components 4. 5G E2E Network Slice Mapping Procedure 4.1. 5G E2E Network Slice Mapping Identifier The following network slice related identifiers in management, control and data planes play an important role in the end-to- end network slice mapping: * Single Network Slice Selection Assistance Information (S-NSSAI): the end-to-end network slice identifier, which is defined in [TS-23.501]; S-NSSAI is used during 3GPP network slice signaling process. * Network Slice Service identifier : An identifier allocated by IETF Network Slice Controller (NSC) in the management plane. See [I-D.ietf-teas-ietf-network-slice-nbi-yang]. 4.2. 5G E2E Network Slice Mapping Procedure This section provides a general procedure of network slice mapping: Geng, et al. Expires 12 December 2024 [Page 11] Internet-Draft IETF Network Slice Application in 3GPP 5 June 2024 +-----------------+ | NSMF | +-----------------+ +----------| S-NSSAI |----------+ | |(e.g., 011111111)| | | +-----------------+ | | | | V V V +-------------+ +---------------------+ +-------------+ | RAN NSSMF | | IETF NSC | | CN NSSMF | +-------------+ +---------------------+ +-------------+ | RAN Slice | | IETF Network Slice | | CN Slice | | Identifier | | Identifier | | Identifier | | (e.g., 4) | | (e.g., 6) | | (e.g., 1) | Management +-------------+ +---------------------+ +-------------+ Plane | | | | ----------------- | | | | V V V V ----------------- +-----+ +-----+ +-----+ +------+ Data | RAN |---| PE |-----...-----| PE |----| CN | Plane +-----+ +-----+ +-----+ +------+ Figure 7: Relationship between IETF and 3GPP Network Slice Management 1. 3GPP NSMF receives the request from 3GPP CSMF for allocation of a network slice instance with certain characteristics. 2. Based on the service requirement, 3GPP NSMF acquires requirements for the end-to-end network slice instance, which is defined in Service Profile (section 6.3.3 of [TS-28.541]). 3. Based on Service Profile, 3GPP NSMF determines the network function and the required resources in AN, CN and TN networks. It also assigns the unique S-NSSAI ID. 4. 3GPP NSMF sends a request to AN NSSMF for creation of AN Slice, which is out of the scope of this document. 5. 3GPP NSMF sends a request to CN NSSMF for creation of CN Slice, which is out of the scope of this document. 6. 3GPP NSMF sends a request to an IETF NSC (acting as an NSSMF for transport network, from the perspective of the 3GPP Management System)) for creation of a RFC9543 Network Slice service. The request contains attributes such as endpoints (based on the information from EP_Transport), required SLA along with other IETF network slice attributes. Geng, et al. Expires 12 December 2024 [Page 12] Internet-Draft IETF Network Slice Application in 3GPP 5 June 2024 7. The IETF NSC realizes the IETF Network Slice which satisfies the requirements of the [RFC9543] Network Slice Service requested between the specified endpoints (RAN/CN edge nodes). The IETF NSC might assign an IETF Network Slice Service ID and send it to 3GPP NSMF. 8. The 3GPP NSMF could maintain the mapping relationship between S-NSSAI and IETF Network Slice Service ID. 5. 5G E2E Network Slice Mapping in Management and Control Planes The transport network management Plane maintains the interface between 3GPP NSMF and TN NSSMF. It is supposed to satisfy the following requirements: 1. Build up mapping relationship between NSI identifier and RFC9543 Network Slice Services; 2. Guarantee that IETF network slice could satisfy the SLA requirements with the transport network connection between AN and CN; 3. The requirements for 5G E2E network slice could be specified in IETF network slice northbound interface. In order to provide slice connectivity constructed by means of IETF network slices it is necessary to build up mapping relationship between two different endpoints, as depicted in Figure 8: * Mapping from EP_Transport of 3GPP network slice side (as defined by [TS-28.541]) to the CE endpoint from IETF network slice side (as defined in [RFC9543]). IETF Network Slice Controller (NSC) will receive the set of CE endpoints to be interconnected as input for network slice services defined in [RFC9543]. * Mapping from CE endpoints to PE endpoints. The endpoint at PE side should be elicited by the IETF NSC, in order to establish connectivity which could satisfy the customer request, according to the SLOs and SLEs received from the higher level system. Geng, et al. Expires 12 December 2024 [Page 13] Internet-Draft IETF Network Slice Application in 3GPP 5 June 2024 3GPP concern EP_RP_left EP_RP_right | | --|-------- ---|----- | / / | x / / x O EP_Transport_left EP_Transport_right O /A /A / | / | ----- | ---|------- | | | | .......|............................................|.......... | | | | | | -------|-- ---------- ---------- | ------- | / / / ____ / / | / V/ / / ( ) / / V/ O<---->O 0==( )==0 O<---->O / / / (____) / / / / / / / / / ----- ---------- ---------- ---------- CE_left PE_left PE_right CE_right IETF concern Figure 8: conceptual view on 3GPP and TN end-points The examples in Section 7 will show how the connection between network slice from endpoints at both 3GPP and IETF side can be established. 5.1. Mapping EP_transport to IETF NS CE Endpoints The 3GPP Management system provides the EP_Transport Information Object Class (IOC) to extend slice awareness to the transport network. This IOC carries parameters that describe the transport endpoints associated with the 3GPP-managed functions (detailed in the EP_Application IOC). These parameters include: * IP Address: The IP address of the transport endpoint. * Additional Identifiers: Optional identifiers that further define the logical interface, such as VLAN tag, MPLS label, Segment Routing (SR) SID, etc. Geng, et al. Expires 12 December 2024 [Page 14] Internet-Draft IETF Network Slice Application in 3GPP 5 June 2024 * QoS Profile (Optional): A set of parameters specifying the Quality of Service (QoS) requirements for the slice. The parameters from the EP_Transport IOC (representing the 3GPP domain) needs to be translated into the corresponding parameters for the CE within the IETF network slice. This translation process can be straightforward in certain scenarios. In such cases, the information from the EP_Transport IOC can be directly passed to the IETF Network Slice Subsystem (NSS) through the standardized Network Slice Services Interface defined in RFC9543. However, additional information might be required which have not been specified in 3GPP standards, e.g., subnet mask for the IP address). For example, when 3GPP-managed functions reside on dedicated monolithic network elements, the IP address in the EP_Transport IOC could directly map to the IP address of the corresponding interface. The mapping process becomes more complex when dealing with virtualized 3GPP-managed functions. These functions can be instantiated on general-purpose servers or within data centers. In these scenarios, additional information are needed to identify the corresponding CE endpoint for example with other parameters defined in EP_transport, including: * Combined Identification: The NS CE endpoint might be identified by a combination of the IP address and additional information like VLAN tag, MPLS label, or SR SID. This combination helps distinguish specific logical interfaces. * Next Hop Information: The next hop router information, as viewed by the 3GPP entity within the slice, could provide hints for determining the slice endpoint at the other side of the slice boundary. * QoS Profile: The QoS profile, if present, helps configure the PE endpoint to meet the Service Level Objectives (SLOs) for the connection between the CE slice endpoints. 5.2. Mapping IETF NS CE to PE Endpoints As outlined in [RFC9543], an IETF Network Slice can have various potential endpoint positions, as reflected in Figure 9. The information passed to the IETF Network Slice Controller (NSC) regarding endpoints is relative to the CE side, which is the perspective of the slice customer (i.e., the 3GPP Management System managing the 3GPP-managed functions). Based on this information, the IETF NSC needs to infer the corresponding endpoint on the Provider Edge (PE) side. This inference is crucial for establishing the Geng, et al. Expires 12 December 2024 [Page 15] Internet-Draft IETF Network Slice Application in 3GPP 5 June 2024 desired connectivity constructs with the specified Service Level Objectives (SLOs) in the request. Since the IETF slice request process is technology-agnostic, the identification of PE side endpoints should rely on generic information passed through the standardized Network Slice Services Interface [I-D.ietf-teas-ietf-network-slice-nbi-yang]. This generic information, combined with the knowledge of the network topology and available resources, will allow the IETF NSC to determine the appropriate PE endpoint for each CE endpoint, ensuring a successful network slice instantiation. |<---------------------- (1) ---------------------->| | | | |<-------------------- (2) -------------------->| | | | | | | | |<----------- (3) ----------->| | | | | | | | | | | | |<-------- (4) -------->| | | | | | | | | | | | V V AC V V V V AC V V +-----+ | +-----+ +-----+ | +-----+ | |--------| | | |--------| | | CE1 | | | PE1 |. . . . . . . . .| PE2 | | | CE2 | | |--------| | | |--------| | +-----+ | +-----+ +-----+ | +-----+ ^ ^ ^ ^ | | | | | | | | Customer Provider Provider Customer Edge 1 Edge 1 Edge 2 Edge 2 (1) SDPs within the CE (e.g. buffers or queues on the outgoing interfaces) (2) SDPs at the Attachment Circuit (3) SDPs at the customer-facing ports on the PEs (4) SDPs within the PE (e.g. destination IP addresses, port numbers) Figure 9: IETF Service Demarcation Points 6. Methods for Mapping Between 3GPP E2E Network Slice and IETF Network Slice Referring to Figure 2, Figure 3 and Figure 4, an end-to-end network slice might have one or more IETF network slices. Figure 10 is a general representation of any of transport networks in 5G end-to-end network slice where the IETF network slice INS_a provides the connectivity between network functions NF1 and NF2 to satisfy the specific SLO/ SLE. For example, Figure 10 could represent IETF Geng, et al. Expires 12 December 2024 [Page 16] Internet-Draft IETF Network Slice Application in 3GPP 5 June 2024 network slice INS1 of Figure 4 where connectivity needed between network functions CU and UPF or it could represent IETF network slice INS4 between network functions DU and CU. Suppose the network function NF1 sends the traffic to NF2. The data plane mapping is mainly addresses how the identification of 3GPP network slice is conveyed and represented on data path, and how the provider network PE nodes map the traffic from context of 5G end-to- end network slice to the [RFC9543] network slice services. It is crucial for PE nodes to be able to map the traffic to the appropriate IETF network slice so as to enforce the SLO/SLE policy. <------ IETF Network Slice Service INS_a ------> AC .-------. AC | ,' `. | | ,' `. | -------- V ------- ------- V -------- | | | | | | | | | NF1 |-------| PE1 | | PE2 |-------| NF2 | | |-------| | | | | | -------- ------- Provider ------- -------- `. Network ,' `. ,' ------- Figure 10: Typical IETF Network Slice in 3GPP Network between NF1 and NF2 To provide an overview of various mechanisms of mapping 5G E2E network slice to IETF network slices, we focus on IETF network slice INS1 in Figure 4 where IETF network slice INS1 provides the connectivity between network functions CU and UPF. Figure 11 shows this scenario. Although the various mapping techniques considered in this section is for IETF network slice INS1, they are all applicable to other IETF network slices of Figure 2, Figure 3 and Figure 4, i.e., INS2, INS3 and INS4. The IETF network slice INS1 provides the connectivity between service demarcation points SDP1 and SPD2. These SDPs are the N3 interfaces on CU and UPF, respectively. As shown in Figure 11(A) and Figure 11(B), the SDPs could be either loopback interfaces or a physical interfaces on CU and UPF network functions. For simplicity case (A) is considered in this section although the various mapping methods are identically applicable to both cases (A) and (B). Geng, et al. Expires 12 December 2024 [Page 17] Internet-Draft IETF Network Slice Application in 3GPP 5 June 2024 <-------------------- INS1 ------------------> SDP1 SDP2 (N3 I/F) (N3 I/F) | .-------. | | ,' `. | v ,' `. V -------- ------- ------- -------- | O | | | | | | O | | | | PE1 | | PE2 | | | | CU | | | | | | UPF | -------- ------- Provider ------- -------- `. Network ,' `. ,' ------- (A) <----------------- INS1 ---------------> SDP1 SDP2 (N3 I/F) (N3 I/F) | .-------. | | ,' `. | v ,' `. V -------- ------- ------- -------- | * | | | | * | | | | PE1 | | PE2 | | | | CU | | | | | | UPF | -------- ------- Provider ------- -------- `. Network ,' `. ,' ------- (B) Legend: <---> IETF Network Slice Service between SDP1 and SDP2 * SDP (N3 interface as CU IP interface) O SDP (N3 as CU loopback interface) Figure 11: Representation of a Typical IETF Network Slice between CU and UPF Geng, et al. Expires 12 December 2024 [Page 18] Internet-Draft IETF Network Slice Application in 3GPP 5 June 2024 Various techniques can be used to map the IETF network slice to 5G E2E network slice. The section covers the following techniques which can be used for mapping between 5G E2E network slice and [RFC9543] network slice services. Note that these techniques might also be used by IETF network slice controller (NSC) to influence the realization of the IETF network slice services as well. The latter case is out of scope of the current draft: * Mapping based on VLAN * Mapping based on MPLS label or SR-MPLS SID * Mapping based on SRv6 SID * Mapping based on Policy Based Routing (PBR) * Mapping based on UDP source port It should be noted that the first three mapping mechanisms are briefly mentioned in [TS-28.541]. 6.1. Mapping based on VLAN ID In some scenarios, it would be possible for provider edge (PE) nodes to infer the identification of the 5G E2E network slices from the VLAN ID carried in the data path traffic, and map the traffic to the corresponding IETF network slice. As shown in Figure 12, the IETF Network slice INS1 between network functions CU and UPF can be mapped using the VLAN ID. In this scenario, the VLANs assigned by network functions CU and UPF are used for the handoff to the provider network. Refer to section 4.1 of [I-D.ietf-teas-5g-ns-ip-mpls] for details of this solution and how it is realized by provider network. Geng, et al. Expires 12 December 2024 [Page 19] Internet-Draft IETF Network Slice Application in 3GPP 5 June 2024 <-------------------- INS1 -------------------> VLAN Handoff IP/MPLS Services | | | | N3 I/F | .---|---. N3 I/F | | ,' | `. | V V ,' V `. V -------- ------- ------- -------- | O..........+======================+...........O | | | | PE1 | | PE2 | | | | CU | | | | | | UPF | -------- ------- Provider ------- -------- `. Network ,' `. ,' ------- (A) Legend: O SDP (N3 interface) + Access points to provider network ... VLAN hand-off === IP/MPLS transport service in provider network (i.e., realization of INS1) Figure 12: VLAN based IETF Network Slice Mapping 6.2. Mapping based on MPLS Label or SR-MPLS SID This section describes another solution for mapping the 5G E2E network slice traffic to IETF network slices based on MPLS/SR-MPLS labels/SIDs. The labels/SIDs carried in the packets sent from CU to UPF can be used by the provider edge (PE) nodes to infer the identification of the 5G E2E network slices and map the packet to the corresponding IETF network slice. Figure 13 shows an example where the 5G E2E network slice is mapped to IETF network slice INS1 using the MPLS label or SR-MPLS SID. In this case, the MPLS label or SR- MPLS SID is used for the handoff to the provider network. Refer to section 4.3 of [I-D.ietf-teas-5g-ns-ip-mpls] for details of this solution and how it is realized by provider network. Geng, et al. Expires 12 December 2024 [Page 20] Internet-Draft IETF Network Slice Application in 3GPP 5 June 2024 <-------------------- INS1 -------------------> tunnel (represented by MPLS label or SR-MPLS SID) | | N3 I/F | .-------. N3 I/F | | ,' `. | V V ,' `. V -------- ------- ------- -------- | *=============================================* | | | | PE1 | | PE2 | | | | CU | | | | | | UPF | -------- ------- Provider ------- -------- `. Network ,' `. ,' ------- (A) Legend: * SDP1 and SPD2 (N3 Address) === tunnel between SDP1 and SDP2 (MPLS or SR-MPLS) Figure 13: MPLS label or SR-MPLS SID based IETF Network Slice Mapping 6.3. Mapping based on SRv6 SID This section describes a solution for mapping the 5G E2E network slice traffic to IETF network slices based on SRv6 SIDs. This solution is similar to the mapping based on MPLS label or SR-MPLS SID but using SRv6 tunnels. As shown in Figure 14, the SRv6 SIDs is added by CU or UPF to the data path traffic between SDP1 and SPD2. The SRv6 SIDs can be used by the provider edge (PE) nodes to infer the identification of the 5G E2E network slices and map the traffic to the corresponding IETF network slice. In this solution, the identification of the 5G E2E network slice may be embedded into IPv6 SIDs, where the 32-bit 3GPP network slice identification is mapped into the 128-bit IPv6 SID, thus the SRv6 SID is used for the handoff to the provider network. Refer to section 4.2 of [I-D.ietf-teas-5g-ns-ip-mpls] for details of this solution and how it is realized by the provider network. Geng, et al. Expires 12 December 2024 [Page 21] Internet-Draft IETF Network Slice Application in 3GPP 5 June 2024 <-------------------- INS1 -------------------> SRv6 tunnel (represented by SRv6 SID) | | N3 I/F | .-------. N3 I/F | | ,' `. | V V ,' `. V -------- ------- ------- -------- | *=============================================* | | | | PE1 | | PE2 | | | | CU | | | | | | UPF | -------- ------- Provider ------- -------- `. Network ,' `. ,' ------- (A) Legend: * SDP1 and SPD2 (N3 address) === SRv6 tunnel between SDP1 and SDP2 Figure 14: SRv6 SID based IETF Network Slice Mapping 6.4. Mapping based on Policy Based Routing (PBR) This section provides a solution for mapping the 3GPP E2E network slice traffic to IETF network slices. As shown in Figure 15, in some deployments of the 5G network slices, it would be possible for provider edge (PE) nodes to infer the identification of the 3GPP E2E network slice from the content of the IP data packet sent between CU and UPF. In these cases, the PE nodes can identify the 5G E2E network slice using any combination of the following attributes and then map them to RFC9543 network slice services: * Source N3 IP address * Destination N3 IP address * Ingress interface * DSCP * Other information in the packet (at IP/MPLS layer or upper layers such as UDP/TCP) Geng, et al. Expires 12 December 2024 [Page 22] Internet-Draft IETF Network Slice Application in 3GPP 5 June 2024 Once the PE nodes receives the IP packets, it may apply infer the context of the 5G E2E network slice and then apply a policy-based routing (PBR) to the packet to map the traffic of specific 5G E2E network slice to the corresponding IETF network slices in the provider network. The details of this solution is beyond scope of this draft. <-------------------- INS1 -------------------> PBR INS1 PBR enforcement realization enforcement | | | | | | N3 I/F | .---|---. | N3 I/F | | ,' | `. | | V V ,' V `. V V -------- ------- ------- -------- | O..........+======================+..........O | | | | PE1 | | PE2 | | | | CU | | | | | | UPF | -------- ------- Provider ------- -------- `. Network ,' `. ,' ------- Legend: O SDP ((N3 interface) + Access points of IP/MPLS Services when PBR is enforced === IP/MPLS realization of the IETF network slice Figure 15: Policy Based Routing (PBR) based IETF Network Slice Mapping 6.5. Mapping based on UDP Source Port This section provides another solution for mapping the 5G E2E network slice traffic to IETF network slices. In some deployments of the 5G E2E network slices, it might be possible for PE nodes to infer the identification of the 3GPP E2E network slice based on the information of the GTP tunnels. As shown in Figure 16, the source UDP port of the data packet may be used to infer the identification of 5G E2E network slices. In this case, a mapping table between the identification of 5G network slice and the source UDP port needs to be maintained by network functions CU, UPF and the PE nodes. The details of this solution is described in [I-D.ietf-dmm-tn-aware-mobility]. Geng, et al. Expires 12 December 2024 [Page 23] Internet-Draft IETF Network Slice Application in 3GPP 5 June 2024 <-------------------- INS1 -------------------> GTP tunnels | | N3 I/F | .-------. N3 I/F | | ,' `. | V V ,' `. V -------- ------- ------- -------- | *=============================================* | | *=============================================* | | | | PE1 | | PE2 | | | | CU | | | | | | UPF | -------- ------- Provider ------- -------- `. Network ,' `. ,' ------- Legend: * SDP (N3 address) === GTP tunnels in context of IETF network slice INS1 Figure 16: UDP source port solution for IETF Network Slice Mapping 7. IETF Network Slice request through IETF Network Slice NBI As discussed in [RFC9543], to fulfill IETF network slices and to perform monitoring on them, an entity called IETF Network Slice Controller (NSC) is required to take abstract requests for IETF network slices and realize them using suitable underlying technologies. An IETF Network Slice Controller is the key building block for control and management of the IETF network slice. It provides the creation/modification/deletion, monitoring and optimization of transport Slices in a multi-domain, a multi- technology and multi-vendor environment. Figure 17 shows the NSC and its NBI interface for 5G, defined as IETF Network Slice Service Interface in [RFC9543]. Draft [I-D.ietf-teas-ietf-network-slice-nbi-yang] a addresses the service yang model of such NSC NBI interface for all network slicing use- cases. Geng, et al. Expires 12 December 2024 [Page 24] Internet-Draft IETF Network Slice Application in 3GPP 5 June 2024 +------------------------------------------+ | 5G Customer (Tenant) | +------------------------------------------+ A | V +------------------------------------------+ | 5G E2E Network Slice Orchestrator | +------------------------------------------+ A | IETF Network Slice Service Interface V +------------------------------------------+ | IETF Network Slice Controller (NSC) | +------------------------------------------+ A | Network Configuration Interface V +------------------------------------------+ | Network Controller(s) | +------------------------------------------+ Figure 17: Interfaces of the IETF Network Slice Controller As discussed in [RFC9543], the main task of the IETF Network Slice Controller is to map abstract IETF network slice requirements from NBI to concrete technologies on SBI and establish the required connectivity, and ensure that required resources are allocated to IETF network slice. There are a number of different technologies that can be used on SBI including physical connections, MPLS, TSN, Flex-E, PON etc. If the underlay technology is IP/MPLS/Optics, any IETF models can be used during the realization of the IETF network slice. There are no specific mapping requirements for 5G. The only difference is that in case of 5G, the NBI interface contains additional 5G specific attributes such as customer name, mobile service type, 5G E2E network slice ID (i.e. S-NSSAI) and so on (See Section 6). These 5G specific attributes can be employed by IETF Network Slice Controller during the realization of 5G IETF network slices on how to map NBI to SBI. They can also be used for assurance of 5G IETF network slices. Figure 18 shows the mapping between NBI to SBI for 5G IETF network slices. Geng, et al. Expires 12 December 2024 [Page 25] Internet-Draft IETF Network Slice Application in 3GPP 5 June 2024 | (1) NBI: Request to create/modify/delete | 5G IETF Network Slice V +----------------------+ | IETF Network Slice | (2) Mapping between technology | Controller (NSC) | agnostics NBI to technology +----------------------+ specific SBI ^ ^ ^ | | | |---| | |---| (3) SBI: Realize 5G IETF Network Slice | | | by using various IETF models for V V V services, tunnels and paths +----------------------+ | Network |-+ | Controller(s) | |-+ +----------------------+ | | +----------------------+ | +----------------------+ Figure 18: Relationship between transport slice interface and IETF Service/Tunnels/Path data models The following figure illustrates the relationship between 3GPP or ORAN subsystems connected through IETF TN domain. After the analysis of 3GPP Generic Network Resource Models (NRM) of [TS-28.540] Rel 17, [TS-28.541] Rel 17 and [TS-28.622] Rel 16 the following objects have been identified as entities on which the decision of mapping to IETF TN slices can be made. These available delineators of network slices, represented by the arrows in the figure, are accessible in IETF domain and possible to be treated as triggers for decision of mapping 3GPP slice to IETF TN slice. Option (1) - the object class of 3GPP/ORAN subsystem is EP_Transport, [TS-28.541] clause 6.3.18, representing a list of attributes including IETF-related parameters, directly exposed to transport network domain: * ipAddress -- an IP address assigned on the 3GPP/ORAN subsystem side of the link to TN. * logicInterfaceType and logicInterfaceId -- in current release it is an ID of the VLAN and encapsulation type is 802.1Q These parameters can program the slice separation and be mapped to an IETF slice. Geng, et al. Expires 12 December 2024 [Page 26] Internet-Draft IETF Network Slice Application in 3GPP 5 June 2024 By instantiating EP_Transport per slice on 3GPP/ORAN subsystem the slicing may be implemented and mapped on slices in IETF TN domain. In this case EP_Transport parameters may be mapped to draft-ietf- teas-ietf-network-slice-nbi-yang data model objects. This option is described in the following example in current document. Option (2) - the object class is EP_RP ([TS-28.622] clause 4.3.11), EP_F1U ([TS-28.541] clause 4.3.13), EP_NgU ([TS-28.541] clause 4.3.11), EP_N3 ( [TS-28.541] clause 5.3.20), representing the 3GPP link and association between 3GPP/ORAN subsystems. These attributes are not exposed directly to IETF TN domain and can be treated as loopbacks behind the link, defined in EP_Transport object class. Instantiation and manipulation of EP_RPs per slice may be mapped on slices in IETF TN domain, while link defined by parameters of EP_Transport may remain the same. This delineation by loopbacks is adding secondary axis of flexibility to network slicing and needs to be mapped to [I-D.ietf-teas-ietf-network-slice-nbi-yang] data model with different logic that delineation in option (1). +------------------------+ +------------------------+ ||3GPP or ORAN subsystem |Provider Provider |3GPP or ORAN subsystem | |(e.g. (O)-DU) |Edge 1 Edge 2 |(e.g. (O)-CU-UP) | |+----------------------+| +--+ +--+ |+----------------------+| ||Bearer || | | | | ||Bearer || || +------+ +-------+|| | | ===== | | ||+-------+ +------+ || || ?EP_RP ? ?EP_Tran?|| | |PE| |PE| | |||EP_Tran| |EP_RP | || || ?EP_F1U|-| sport X++--+-| ===== |-+--|X sport |-|EP_F1U| || || +---A--+ +---A---+|| | | | | | | |+----A---+ +-A----+ || |+--------+--------+----+| | +--+ +--+ | |+----+-------+-------- +| +---------+--------+-----+ | | +-----+-------+----------+ | | | | | | (2) (1) AC AC (1) (2) Customer Edge 1 Customer Edge 2 Figure 19: Slice mapping options analysis based on 3GPP NRM These basic options represent possible implementation options of objects and parameters Operator may use to instantiate slices and correlate them with network slices in IETF TN domain to ensure SLA and SLO per slice. Since 3GPP Generic Network Resource Models are not limiting use of these object classes and not mandating roles and mapping procedures, any combination of (1), (2) and (3) may be implemented in real slicing scenario. Geng, et al. Expires 12 December 2024 [Page 27] Internet-Draft IETF Network Slice Application in 3GPP 5 June 2024 (1) The use of slicing based on EP_Transport instantiation may be favorable due to direct exposure of connectivity parameters to IETF TN domain. However, there are currently gaps in the NRM that may affect this option: * The NRM Rel. 17 lacks definitions and object class structures for DC or DC-fabric implementations of RAN or CN instances. * The attribute in EP_Transport qosProfile has no relation to clauses 5.3.84 QoSData and 5.3.79 FiveQiDscpMapping and cannot be extracted or mapped to SLO/SLE constructs as the information is not available in the IETF domain. * The destination of the traffic may potentially be extracted from EP_RP ([TS-28.622] clause 4.3.11), but this information is not accessible in the IETF domain, so it cannot be extracted or mapped to communication type and connectivity constructs. * Redundancy of EP_Transports is an open topic for failover and protection mechanisms (2) The option of using a common EP_Transport and multiple EP_RP with unique IP addresses may be suitable for DC and DC-Fabric implementations where EP_Transport establishes connectivity to the IETF TN domain and EP_RPs serve as virtual instance loopbacks. However, the lack of direct exposure of IP addresses and slice demand parameters in the IETF domain may make this slicing option challenging to implement. Currently, the following gaps have been identified: * EP_Transport object class does not define a mechanism for active communication of EP_RP loopbacks to the IETF ingress PE device (e.g., no PE-CE protocols) * Redundancy for EP_Transports is still an open topic for failover and protection mechanisms, with the added complexity of EP_RP loopback switchover * Pre-installed policies in the IETF TN domain for pre-defined EP_RP loopbacks may result in network overprovisioning (e.g., PBR, policies, service-match-criteria) * The absence of a common toolset for monitoring the existence and activity of EP_RP loopbacks may hinder root cause analysis and troubleshooting. Following subsections present several examples for illustrating the mapping of 3GPP objects to IETF NBI YANG model. Geng, et al. Expires 12 December 2024 [Page 28] Internet-Draft IETF Network Slice Application in 3GPP 5 June 2024 Editorial note: further examples will be added in future versions of this document. 7.1. Example according to CE-mode (OPTION 1) This example considers the request of a slice for realizing the F1-U [3GPP [TS-38.470] interface between a DU and a CU-UP elements (i.e., INS4 in previous Figure 4). Note that the example is equally valid for the realization of any other case. The example follows the CE-mode as described in Figure 20. Geng, et al. Expires 12 December 2024 [Page 29] Internet-Draft IETF Network Slice Application in 3GPP 5 June 2024 +-----+ Association between X and Y +-----+ | | according to 3GPP (i.e., NgU/N3 interface) | | | gNB |<----------------------------------------------->| UPF | | | | | +-----+ +-----+ +-----+ Association between DU and CU-UP +-----+ | | according to O-RAN (i.e., F1-U interface) | | | DU |<----------------------------------------------->|CU-UP| | | | | +-----+ +-----+ \__________ __________/ \/ SDP1 SDP2 (with CE1 parameters) (with CE2 parameters) o<----------------- IETF Network Slice ---------------->o + + +|<------------------------- S1 ---------------------->|+ +| |+ +| |<------- T1 ----->| |+ +| v v |+ +v +----+ +----+ v+ +--+--+ | | PE1|==================| PE2| | +-+---+ | + | | | | | | | | + | | o X----------X | | X----------X o | | | | | | | | | | | +-----+ | | |==================| | | +-----+ AC +----+ +----+ AC Customer Provider Provider Customer Edge 1 Edge 1 Edge 2 Edge 2 Legend: O: Representation of the IETF network slice endpoints (SDP) loopback interface in this example +: Mapping of SDP to CE X: Physical interfaces used for realization of IETF network slice S1: L0/L1/L2/L3 services used for realization of IETF network slice T1: Tunnels used for realization of IETF network slice Figure 20: CE-mode slice realization example between DU and CU-UP OPTION The 3GPP Management System is expected to handle different IOCs for both DU and CU-UP. For each of those 3GPP network entities, one of the IOCs is the EP_RP, which describes each of the end-points in the association between 3GPP core entities, and the other IOC is the EP_Transport, which provides information attributes about the point Geng, et al. Expires 12 December 2024 [Page 30] Internet-Draft IETF Network Slice Application in 3GPP 5 June 2024 of attachment of each 3GPP core entity to the transport network. Both objects are cross-referenced, so it is possible to get the information of one of them from the other. Figure 21 shows the information provided at the DU side corresponding to the intended association with the CU-UP at the other end. +---------------------------------+ | EP_F1U CU-UP1 |<---+ +---------------------------------+ | | Parameter | Value | | +---------------------------------+ | | localAddress | 192.0.2.2 | | +---------------------------------+ | | remoteipaddress| 198.51.100.2 | | +---------------------------------+ | | epTransportRef |EP_Transport 100| | +---------------------------------+ | A | | | | | V | +-----------------------------------+ | | EP_Transport 100 | | +-----------------------------------+ | | Parameter | Value | | +-----------------------------------+ | | ipAddress | 192.0.2.1 | | +-----------------------------------+ | |logicInterfaceType| vlan | | +-----------------------------------+ | | logicInterfaceId | 100 | | +-----------------------------------+ | | NextHopInfo | 192.0.2.254 | | +-----------------------------------+ | | qosProfile | 5QI100 | | +-----------------------------------+ | | epApplicationRef | EP_F1U CU-UP1 |<--+ +-----------------------------------+ Figure 21: 3GPP IOCs at DU side for the DU1 CU-UP1 connection Similarly, at CU-UP side the following objects are provided for setting up the network slice service towards DU, as represented in Figure 22. Geng, et al. Expires 12 December 2024 [Page 31] Internet-Draft IETF Network Slice Application in 3GPP 5 June 2024 +---------------------------------+ | EP_F1U DU1 |<---+ +---------------------------------+ | | Parameter | Value | | +---------------------------------+ | | localAddress | 198.51.100.2 | | +---------------------------------+ | | remoteipaddress| 192.0.2.2 | | +---------------------------------+ | | epTransportRef |EP_Transport 100| | +---------------------------------+ | A | | | | | V | +-----------------------------------+ | | EP_Transport 100 | | +-----------------------------------+ | | Parameter | Value | | +-----------------------------------+ | | ipAddress | 198.51.100.1 | | +-----------------------------------+ | |logicInterfaceType| vlan | | +-----------------------------------+ | | logicInterfaceId | 100 | | +-----------------------------------+ | | NextHopInfo | 198.51.100.254 | | +-----------------------------------+ | | qosProfile | 5QI100 | | +-----------------------------------+ | | epApplicationRef | EP_F1U DU1 |<--+ +-----------------------------------+ Figure 22: 3GPP IOCs at CU-UP side for the DU1 CU-UP1 connection This is the basic information from where deriving the set of parameters feeding the NS NBI model. According to this example, the following mapping could be performed. * SDPs: the SDPs in this example correspond to the IP addresses of the 3GPP core entities, thus 192.0.2.2 at the DU1 side and 198.51.100.2 at the CU-UP1 side, both contained in the EP_RP object. * SLO / SLE policy: the SLO policy can be derived from the QoS profile indicated in the EP_Transport object. SLE information are not directly expressed in 3GPP IOCs, then, if needed, SLE Geng, et al. Expires 12 December 2024 [Page 32] Internet-Draft IETF Network Slice Application in 3GPP 5 June 2024 information should be complemented by other means (e.g., the 3GPP Slice Profile could provide indication of high reliability which could be translated to SLE values in the NBI YANG model internally to the NSC). * Peer SAP: the Next Hop info parameter in EP_Transport object can provide information about the SAP at the PE side, based on the IP address provided. * AC: the conjugation of the IP address in the EP_Transport object, plus the information of the logical interface type and its identifier also in EP_Transport, can assist on determining the specific AC used for the network slice. The resulting mapping is summarized in Figure 23. SDP1 SDP2 (192.0.2.2) (198.51.100.2) o<----------------- IETF Network Slice ---------------->o + + +|<------------------------- S1 ---------------------->|+ +| |+ +| EP_Transport EP_Transport |+ +| (192.0.2.1) |<------ T1 ---->| (198.51.100.1) |+ +| / v v \ |+ +v / +-----+ +-----+ \ v+ +--+--+ / | PE1 |================| PE2 | \ +-+---+ | + |/ | | | | | | \| + | | o X----------X | | X----------X o | | | | |\ | | /| | | | | | | | \ | | / | | | | | | | Peer SAP| | Peer SAP | | | | | |(192.0.2.254)|================|(198.51.100.254)| | | | | | | | | | | | +-----+ | +-----+ +-----+ | +-----+ Customer | Provider Provider | Customer Edge 1 | Edge 1 Edge 2 | Edge 2 | | AC (vlan 100) AC (vlan 100) Figure 23: CE-mode slice realization example between DU and CU-UP with values Further parameters can be filled in the NS NBI YANG model from the information provided. For instance, since there is one single pair of EP_Transport objects, one on each end of the intended slice service, the connectivity construct can be requested as p2p. Since the ranges of IP address of both DU1 and CU-UP1 could pertain to Geng, et al. Expires 12 December 2024 [Page 33] Internet-Draft IETF Network Slice Application in 3GPP 5 June 2024 different block of prefixes, the NSC can take the decision of realizing the network slice as a routed service. Here is important to remark that the IOCs from 3GPP do not provide any information regarding the mask applied to each prefix, so this can produce inconsistencies in the interpretation of the information received. Clearly this is a gap necessary to be solved. In addition to that, the logical interface type and its identifier can be used as match criteria for mapping traffic between DU1 and CU- UP1 on the intended slice service. As such, the NBI YANG model can result in something like: { "data": { "ietf-network-slice-service:network-slice-services": { "slo-sle-templates": { "slo-sle-template": [ { "id": "5QI100", /* QoS profile as in EP_Transport*/ "template-description": "5QI100 description" }, ] }, "slice-service": [ { "service-id": "5GSliceMapping", "service-description": "example 5G Slice mapping", "slo-sle-template": "5QI100", "status": { }, "sdps": { "sdp": [ { "sdp-id": "01", "node-id": "DU1", "sdp-ip": "192.0.2.2", "service-match-criteria": { "match-criterion": [ { "index": 1, "match-type": "vlan-match", "target-connection-group-id": "DU-CU" } ] }, "attachment-circuits": { "attachment-circuit": [ Geng, et al. Expires 12 December 2024 [Page 34] Internet-Draft IETF Network Slice Application in 3GPP 5 June 2024 { "ac-id": "100", "ac-ip-address": "192.0.2.1", "ac-ip-prefix-length": ?, "peer-sap-id": "192.0.2.254" } ] }, "status": { } }, { "sdp-id": "02", "node-id": "CU-UP1", "sdp-ip": "198.51.100.2", "service-match-criteria": { "match-criterion": [ { "index": 1, "match-type": "vlan-match", "target-connection-group-id": "DU-CU", "target-connectivity-construct-id": 1 } ] }, "attachment-circuits": { "attachment-circuit": [ { "ac-id": "100", "ac-ip-address": "198.51.100.1", "ac-ip-prefix-length": ?, "peer-sap-id": "198.51.100.254" }, ] }, "status": { } }, ] }, "connection-groups": { "connection-group": [ { "connection-group-id": "DU-CU", "connectivity-type": "ietf-vpn-common:any-to-any", "connectivity-construct": [ { "cc-id": 1, Geng, et al. Expires 12 December 2024 [Page 35] Internet-Draft IETF Network Slice Application in 3GPP 5 June 2024 "a2a-sdp": [ { "sdp-id": "01" }, { "sdp-id": "02" }, ] } ] } ] } } ] } } } 7.2. Example according to PE-mode (OPTION 2) This example considers the request of a slice for realizing the F1-U [TS-38.470] interface between a DU and a CU-UP elements (i.e., INS4 in previous Figure 4). Note that the example is equally valid for the realization of any other case. The example follows the PE-mode as described in Figure 24. Geng, et al. Expires 12 December 2024 [Page 36] Internet-Draft IETF Network Slice Application in 3GPP 5 June 2024 +-----+ Association between X and Y +-----+ | | according to 3GPP (i.e., NgU/N3 interface) | | | gNB |<----------------------------------------------->| UPF | | | | | +-----+ +-----+ +-----+ Association between DU and CU-UP +-----+ | | according to O-RAN (i.e., F1-U interface) | | | DU |<----------------------------------------------->|CU-UP| | | | | +-----+ +-----+ \__________ __________/ \/ SDP1 SDP2 (With PE1 parameters) (with PE2 parameters) o<--------- IETF Network Slice 1 ------->o + | | + + |<----------- S1 ----------->| + + | | + + | |<------ T1 ------>| | + + v v v v + + +----+ +----+ + +-----+ | | PE1|==================| PE2| +-----+ | | | | | | | | | | | |----------X | | X----------| | | | | | | | | | | | +-----+ | | |==================| | | +-----+ AC +----+ +----+ AC Customer Provider Provider Customer Edge 1 Edge 1 Edge 2 Edge 2 Legend: O: Representation of the IETF network slice endpoints (SDP) +: Mapping of SDP to customer-facing ports on the PE X: Physical interfaces used for realization of IETF network slice service S1: L0/L1/L2/L3 services used for realization of IETF network slice service T1: Tunnels used for realization of IETF network slice service Figure 24: PE-mode slice realization OPTION 2 The resulting mapping is summarized in Figure 25. Geng, et al. Expires 12 December 2024 [Page 37] Internet-Draft IETF Network Slice Application in 3GPP 5 June 2024 SDP1 SDP2 (With PE1 parameters) (with PE2 parameters) (192.0.2.254) (198.51.100.254) o<--------- IETF Network Slice 1 ------->o + | | + + |<----------- S1 ----------->| + + | | + + | |<------ T1 ------>| | + + v v v v + + +----+ +----+ + +-----+ | | PE1|==================| PE2| +-----+ | |----------X | | | | | | | | | | | | X----------| | | | | | | | | | | | +-----+ | | |==================| | | +-----+ | +----+ +----+ | Customer | Provider Provider | Customer Edge 1 | Edge 1 Edge 2 | Edge 2 | | AC (vlan 100) AC (vlan 100) Figure 25: PE-mode slice realization OPTION 2 From NBI YANG: The IETF network slice controller (NSC) uses 'node-id' (PE device ID), 'attachment circuit' ( ACs ) to map SDPs to the customer-facing ports on the PEs Gap: no info received in regards PE device ID. However we can retrieve the PE port IP address from NextHopInfo parameter, as sdp-ip { "data": { "ietf-network-slice-service:network-slice-services": { "slo-sle-templates": { "slo-sle-template": [ { "id": "5QI100", /* QoS profile as in EP_Transport*/ "template-description": "5QI100 description" }, ] }, "slice-service": [ { "service-id": "5GSliceMapping-PE-mode", "service-description": "example 5G Slice mapping following PE mode", "slo-sle-template": "5QI100", /* QoS profile as in EP_Transport*/ Geng, et al. Expires 12 December 2024 [Page 38] Internet-Draft IETF Network Slice Application in 3GPP 5 June 2024 "status": { }, "sdps": { "sdp": [ { "sdp-id": "01", "node-id": "PE1", "sdp-ip": "192.0.2.254", /* NextHopInfo IP address in EP_Transport */ "service-match-criteria": { "match-criterion": [ { "index": 1, "match-type": "vlan-match", /*logicInterfaceType*/ "target-connection-group-id": "DU-CU" } ] }, "attachment-circuits": { "attachment-circuit": [ { "ac-id": "100", /*logicInterfaceId*/ "ac-ip-address": "192.0.2.254", /* Next HopInfo IP address in EP_Transport, redundant, can be removed */ "ac-ip-prefix-length": ?, /* not available */ "peer-sap-id": "192.0.2.254" } ] }, "status": { } }, { "sdp-id": "02", "node-id": "PE2", "sdp-ip": "198.51.100.254", /* NextHopInfo IP address in EP_Transport */ "service-match-criteria": { "match-criterion": [ { "index": 1, "match-type": "vlan-match", /*logicInterfaceType*/ "target-connection-group-id": "DU-CU", "target-connectivity-construct-id": 1 } ] }, "attachment-circuits": { Geng, et al. Expires 12 December 2024 [Page 39] Internet-Draft IETF Network Slice Application in 3GPP 5 June 2024 "attachment-circuit": [ { "ac-id": "100", /*logicInterfaceId*/ "ac-ip-address": "198.51.100.254", /* NextHopInfo IP address in EP_Transport, redundant, can be removed */ "ac-ip-prefix-length": ?, /* not available */ "peer-sap-id": "198.51.100.254" }, ] }, "status": { } }, ] }, "connection-groups": { "connection-group": [ { "connection-group-id": "DU-CU", "connectivity-type": "ietf-vpn-common:any-to-any", ** Note: there is a hint from NRM on {{TS-28.541}} Clause 4.3.11, 4.3.13, 5.3.20 relationsip between 3GPP elements on the logical link connection with attributes localAddress and remoteAddress. This information may be correlated with the connectivity and analyzed to make a decision on the connectivity type.** "connectivity-construct": [ { "cc-id": 1, "a2a-sdp": [ { "sdp-id": "01" }, { "sdp-id": "02" }, ] } ] } ] } } ] } } } Geng, et al. Expires 12 December 2024 [Page 40] Internet-Draft IETF Network Slice Application in 3GPP 5 June 2024 7.3. Example According to PE-mode with Meeting Point Extension of ACaaS (OPTION 3) This example is based on the Option 2 when SDP is located on the PE and utilizing the same approach for the data model of the Network Slice Service, but "attachment-circuits" section of the model is referring to the identifiers that are created using the data models specified in [I-D.draft-ietf-opsawg-teas-attachment-circuit] This example following the overall conception in [ZSM-003] of confederated data model approach and SDO Data Model cross-referencing in order to get quicker Service and Slice provisioning in multiple domains under various SDO areas of focus, fueling closed-loop automation direction in the Management lifecycle of Slices and Services. 3GPP NRM Rel 18 LogicalInterfaceInfo (Section 6.3.35 of [TS-28.541]) represents 3GPP IOC with TN-related parameters of the 3GPP subsystem interpreted in this example (Option 3) as CE network configuration of current model and may be referenced as a 'peer-sap-id' remote endpoint of the attachment circuit with parameters as 'nf- termination-ip' and 'nf-termination-vlan' (see more on SAPs at [RFC9408]; and parameters related to the physical connection and associated with Bearer Service "ietf-ac-svc:attachment-circuits:ietf- bearer-svc". 3GPP NRM ConnectionPointInfo (Section 6.3 of [TS-28.541]) represents 3GPP IOC with link to the external IETF data model [I-D.draft-ietf-opsawg-teas-attachment-circuit] in order to link the corresponding 3GPP subsystem Transport Network-related slice Meeting Point (Clause 6.3.18 of [TS-28.541], EP_Transport) to the IETF Network Slice attachment circuit. As the [I-D.ietf-teas-ietf-network-slices] has flexibility of Network-Specific abstraction, a need for more attention to connectivity parameters was identified during collaboration activity in O-RAN Alliance Working Group 9 between the 3GPP SA5 representatives and IETF contributors. [I-D.draft-ietf-opsawg-teas-attachment-circuit] is used jointly to the Network Slice Service YANG model to capture and reflect IETF PE connectivity to 3GPP subsystem parameters such as: Geng, et al. Expires 12 December 2024 [Page 41] Internet-Draft IETF Network Slice Application in 3GPP 5 June 2024 * Physical parameters of the bearer, captured in the "ietf-bearer- svc" YANG Module of [I-D.draft-ietf-opsawg-teas-attachment-circuit], contains the physical connectivity parameters that the link is utilizing, site location, (3GPP) device information, the IETF PE is connected to, and administrative operational parameters as status and activation time constraints. * Location information, correlated with NRM [TS-28.623] in corresponding 3GPP element id in Clause A 2.2.2 IOC ManagedElement.locationName attribute. * Logical connectivity parameters: e.g., VLAN, IPv4, and IPv6. * Routing protocols While 3GPP NRM Rel 17 (Section 6.3.18 of [TS-28.541]) EP_Transport Attribute "nextHopInfoList" from Clause 6.3.18.2 is associated with "ietf-network-slice-service:network-slice-services:slice- service:sdp:sdp-ip" value, in 3GPP NRM Rel 18 [TS-28.541] Clause 6.3.18 EP_Transport Attribute list no longer contains IP address of TN element, but a link to IETF meeting point with connectionPointId value of "ietf-ac-svc:attachment-circuits:ac:name". Provisioning procedures of the 3GPP Elements are captured in [TS-28.531] where relationship between NRM leaf and IETF AC "ietf-ac- svc:attachment-circuits:ac:name" is depicted. Note: Possible values of the attribute, specifying the type of the connection point identifier "connectionPointIdType" are VLAN, MPLS, Segment, IPv4, IPv6, and Attachment Circuit (AC). In current example Option 3 "Attachment Circuit (AC)" is used. Figure 26 captures Transport-related parameters. Geng, et al. Expires 12 December 2024 [Page 42] Internet-Draft IETF Network Slice Application in 3GPP 5 June 2024 SDP1 SDP2 (With PE1 parameters) (with PE2 parameters) (192.0.2.254) (198.51.100.254) o<--------- IETF Network Slice 1 ------->o + | | + + |<----------- S1 ----------->| + + | | + + | |<------ T1 ------>| | + + v v v v + (192.0.2.1) + +----+ +----+ + (198.51.100.1) +-----+ | | PE1|==================| PE2| +------+ | |----------X | | | | | | | DU1 | | | | | X----------|CU-UP1| | | | | | | | | | | +-----+ | | |==================| | | +------+ | +----+ +----+ | Customer | Provider Provider | Customer Edge 1 | Edge 1 Edge 2 | Edge 2 | | AC-ID (vlan 100) AC-ID (vlan 100) Figure 26 The following attributes mapping is assumed in this example: ---DU1--- 3GPP NRM {{TS-28.541}} Clause 6.3.18 EP_Transport ipAddress: '192.0.2.1/24' localLogicalInterfaceInfo: "DU1_LogicalInterfaceInfo" qosProfile: '5QI100' connectionPointRefList: "DU1_Meeting_point" 3GPP NRM Rel 18 {{TS-28.541}} Clause 6.3.35 LogicalInterfaceInfo: "DU1_LogicalInterfaceInfo" logicalInterfaceType: 'VLAN' logicalInterfaceId: '100' systemName: 'DU1' portName: 'XE' routingProtocol: 'Static' ** Note: LogicalInterfaceInfo.routingProtocol has Allowed values: RIP, IGMP, OSPF, EGP, EIGRP, BGP, IS-IS.** ** Identified gap: No Static or Direct_connect value is available.** 3GPP NRM {{TS-28.541}} Clause 6.3.41 ConnectionPointInfo: "DU1_Meeting_point" connectionPointId: 'ac01-DU1' connectionPointIdType: 'Attachment_Circuit' ** Note: connectionPointIdType has Allowed values: VLAN, MPLS, Segment, IPV4, IPV6, Attachment Circuit (AC) with multiplicity: 1 3GPP NRM {{TS-28.623}} Clause A 2.2.2 IOC ManagedElement Geng, et al. Expires 12 December 2024 [Page 43] Internet-Draft IETF Network Slice Application in 3GPP 5 June 2024 id: 'DU1' locationName: 'Site1.AAA1.ZIP1' ** Note: The physical location (e.g., an address) of an 3GPP entity. It may contain no information to support the case where the derivative of ManagedElement needs to represent a distributed multi-location NE."** ---CU-UP1--- 3GPP NRM {{TS-28.541}} Clause 6.3.18 EP_Transport ipAddress: '198.51.100.1/24' localLogicalInterfaceInfo: "CU-UP1_LogicalInterfaceInfo" qosProfile: '5QI100' connectionPointRefList: "CU-UP1_Meeting_point" 3GPP NRM Rel 18 {{TS-28.541}} Clause 6.3.35 LogicalInterfaceInfo: "CU-UP1_LogicalInterfaceInfo" logicalInterfaceType: 'VLAN' logicalInterfaceId: '100' systemName: 'CU-UP1' portName: 'XE' routingProtocol: 'Static' 3GPP NRM {{TS-28.541}} Clause 6.3.41 ConnectionPointInfo: "CU-UP1_Meeting_point" connectionPointId: 'ac01-CU-UP1' connectionPointIdType: 'Attachment_Circuit' 3GPP NRM {{TS-28.623}} Clause A 2.2.2 IOC ManagedElement id: 'CU-UP1' locationName: 'Site1.AAA2.ZIP2' ---- { "data": { "ietf-network-slice-service:network-slice-services": { "slo-sle-templates": { "slo-sle-template": [ { "id": "5QI100", /* QoS profile as in EP_Transport*/ "template-description": "5QI100 description" }, ] }, "slice-service": [ { "service-id": "5GSliceMapping-PE-mode", "service-description": "example 5G Slice mapping following PE mode", "slo-sle-template": "5QI100", /* QoS profile as in EP_Transport*/ "status": "active" "sdps": { "sdp": [ { Geng, et al. Expires 12 December 2024 [Page 44] Internet-Draft IETF Network Slice Application in 3GPP 5 June 2024 "sdp-id": "01", "node-id": "PE1", "ac-svc-name:ac-ref": [ "ac01-DU1" ** 3GPP NRM {{TS-28.541}} DU1.ConnectionPointInfo."DU1_Meeting_point".connectionPointId ** ] "status": "active" { "sdp-id": "02", "node-id": "PE2", "ac-svc-name:ac-ref": [ "ac01-CU-UP1" **3GPP NRM {{TS-28.541}} CU-UP1.ConnectionPointInfo. "CU-UP1_Meeting_point".connectionPointId** ] "status": "active" }, ] }, }, "connection-groups": { "connection-group": [ { "connection-group-id": "DU-CU", "connectivity-type": "ietf-vpn-common:any-to-any", "connectivity-construct": [ { "cc-id": 1, "a2a-sdp": [ { "sdp-id": "01" }, { "sdp-id": "02" }, ] } ] } ] } } ] } } "ietf-ac-svc:attachment-circuits": { "ac": [ { Geng, et al. Expires 12 December 2024 [Page 45] Internet-Draft IETF Network Slice Application in 3GPP 5 June 2024 "name": "ac01-DU1", ** 3GPP NRM {{TS-28.541}} Clause 6.3.41 ConnectionPointInfo.connectionPointId ** "description": "meeting point DU1-PE1", "l2-connection": { "encapsulation": { "type": "ietf-vpn-common:dot1q", ** 3GPP NRM Rel 18 {{TS-28.541}} Clause 6.3.35 LogicalInterfaceInfo.logicalInterfaceType ** logicalInterfaceType: 'VLAN' "dot1q": { "cvlan-id": 100 ** 3GPP NRM Rel 18 {{TS-28.541}} Clause 6.3.35 LogicalInterfaceInfo.logicalInterfaceId ** } }, "bearer-reference": "line-156" }, "ip-connection": { "ipv4": { "local-address": "192.0.2.254", "prefix-length": 24, "address": [ { "address-id": "1", "customer-address": "192.0.2.1" **3GPP NRM {{TS-28.541}} Clause 6.3.18 DU1.EP_Transport.ipAddress** } ] }, "routing-protocols": { "routing-protocol": [ { "id": "1", "type": "ietf-vpn-common:direct-routing" ** 3GPP NRM Rel 18 {{TS-28.541}} Clause 6.3.35 LogicalInterfaceInfo.routingProtocol ** } ] } "name": "ac01-CU-UP1", ** 3GPP NRM {{TS-28.541}} Clause 6.3.41 ConnectionPointInfo.connectionPointId ** "description": "meeting point CU-UP1-PE2", "l2-connection": { "encapsulation": { "type": "ietf-vpn-common:dot1q", ** 3GPP NRM Rel 18 {{TS-28.541}} Clause 6.3.35 LogicalInterfaceInfo.logicalInterfaceType ** "dot1q": { "cvlan-id": 100 ** 3GPP NRM Rel 18 {{TS-28.541}} Clause 6.3.35 LogicalInterfaceInfo.logicalInterfaceId ** } }, Geng, et al. Expires 12 December 2024 [Page 46] Internet-Draft IETF Network Slice Application in 3GPP 5 June 2024 "bearer-reference": "line-345" }, "ip-connection": { "ipv4": { "local-address": "198.51.100.254", "prefix-length": 24, "address": [ { "address-id": "1", "customer-address": "198.51.100.1" **3GPP NRM {{TS-28.541}} Clause 6.3.18 CU-UP1.EP_Transport.ipAddress** } ] }, "routing-protocols": { "routing-protocol": [ { "id": "1", "type": "ietf-vpn-common:direct-routing" ** 3GPP NRM Rel 18 {{TS-28.541}} Clause 6.3.35 LogicalInterfaceInfo.routingProtocol ** } ] } } "ietf-ac-svc:ietf-bearer-svc":{ "bearers": [ { "id": "line-156" //Note that bearer-reference is returned in the response "description": "link DU1-PE1" "customer-point": { "identified-by": "ietf-bearer-svc:site-and-device-id", "device": { "device-id": "DU1" ** Either 3GPP NRM Rel 18 {{TS-28.541}} Clause 6.3.35 LogicalInterfaceInfo: "DU1_LogicalInterfaceInfo". systemName or 3GPP NRM {{TS-28.623}} Clause A 2.2.2 IOC ManagedElement.DU1.id ** "site": { "site-id": "Site1.AAA1.ZIP1" ** 3GPP NRM {{TS-28.623}} Clause A 2.2.2 IOC ManagedElement.DU1.locationName** } } } "id": "line-345" "description": "link CU-UP1-PE2" "customer-point": { "identified-by": "ietf-bearer-svc:site-and-device-id", "device": { "device-id": "CU-UP1" Geng, et al. Expires 12 December 2024 [Page 47] Internet-Draft IETF Network Slice Application in 3GPP 5 June 2024 ** Either 3GPP NRM Rel 18 {{TS-28.541}} Clause 6.3.35 LogicalInterfaceInfo: "CU-UP1_LogicalInterfaceInfo". systemName or 3GPP NRM {{TS-28.623}} Clause A 2.2.2 IOC ManagedElement.CU-UP1.id ** "site": { "site-id": "Site1.AAA2.ZIP2" ** 3GPP NRM {{TS-28.623}} Clause A 2.2.2 IOC ManagedElement.CU-UP1.locationName** } } } } } ] } } 8. Gap Analysis The way in which 3GPP is characterizing the slice endpoint (i.e., EP_Transport) is based on Layer 3 information (e.g., the IP Address). However the information provided seems not to be sufficient for instructing the IETF Network Slice Controller for the realization of the IETF NEtwork Slice. For instance, some basic information such as the mask associated to the IP address of the EP_Transport is not specified, as well as other kind of parameters like the connection MTU or the connectivity type (unicast, multicast, etc). More sophisticated information could be required as well, like the level of isolation or protection necessary for the intended slice. In the case in which the 3GPP managed function runs on a purpose- specific network element, the IP address specified in the EP_Transport IOC serves as reference to identify the CE endpoint, assuming the endpoint of the CE has been configured with that IP address. With that information (together with the logical interface ID) should be sufficient for the IETF NSC to identify the counterpart endpoint at the PE side, and configuring it accordingly (e.g., with a compatible IP address) for setting up the slice end-to-end. Similarly, the next hop information in EP_Transport can help validate the end-to-end slice between PE endpoints. In the case in which the 3GPP managed function is instantiated as a virtualized network function, the direct association between the IP address of EP_Transport and the actual endpoint mapped at the CE is not so clear. It could be the case, for instance when the virtualized network function is instantiated at the internal of a data center, that the CE facing the PE is far from the point where the function is deployed, being that connectivity extended through the internals of the data center (or by some internal configuration of a virtual switch in a server). In these situations additional information is needed for accomplishing the end-to-end connection. Geng, et al. Expires 12 December 2024 [Page 48] Internet-Draft IETF Network Slice Application in 3GPP 5 June 2024 At the same time, [TS-28.541] IOC contains useful parameters to be used in IETF Network Slice creation mechanism and enriching IETF Network Slice model. The following parameters may be suggested as a candidates to the correlation of the IETF Network Slice parameters and IETF Network Slice model enrichments: * For the latency, dLThptPerSliceSubnet, uLThptPerSliceSubnet, reliability and delayTolerance attributes, the following NRM apply (with reference to the section in that specification): - CNSliceSubnetProfile (section 6.3.22 in [TS-28.541]) - RANSliceSubnetProfile (section 6.3.23 in [TS-28.541]) - TopSliceSubnetProfile (section 6.3.24 in [TS-28.541]) * For the qosProfile attribute, the NRM which applies is EP_Transport (detailed in section 6.3.18 in [TS-28.541]) 9. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. 10. Security Considerations To be completed. 11. Evolution Considerations 3GPP NRM evolution of the data model approach is considered for Rel. 18. 12. Acknowledgments The work of Luis M. Contreras has been partially funded by the European Commission under Horizon 2020 project Int5Gent (grant agreement 957403. Thanks to Philip Eardley (philip.eardley@bt.com) for his contribution to this document. Geng, et al. Expires 12 December 2024 [Page 49] Internet-Draft IETF Network Slice Application in 3GPP 5 June 2024 13. Annex 1: 3GPP Network Slice Mapping Parameters The network slice concept was introduced in 3GPP specifications from the first 5G release, corresponding to Release 15. As captured in [TS-23.501], a network slice represents a logical network providing specific network capabilities and network characteristics. To make slicing a reality, every technical domain is split into one or more logical network partitions, each referred to as a network slice subnet. The definition of multiple slice subnets on a single domain allows each segment to provide differentiated behaviors, in terms of functionality and/or performance, tailored to some specific needs. The stitching of slice subnets across the RAN, CN and TN results in the definition of 5G network slices in 3GPP. From a management viewpoint, the concept of network slice subnet represents an independently manageable yet composable portion of a network slice. The rules for the definition of network slice subnet and their composition into network slices are detailed in the 5G Network Resource Model (NRM) [TS-28.541], specifically in the Network Slice NRM fragment. This fragment captures the information model of 5G network slicing, which specifies the relationships between different slicing related managed entities, which is represented as Information Object Class (IOC). The IOC that have been defined including: NetworkSlice IOC, NetworkSliceSubnet IOC, ManagedFunction IOC and EP_Transport IOC. Information Object Class EP_Transport [TS-28.541] Clause 6.3.18 represents logical interface parameters of 3GPP subsystems, providing specific network capabilities and network characteristics. Relationships of Transport slicing-related 3GPP IOCs and IETF domain represented on the Figure X for NgU/N3 slices with traffic between 3GPP CU-UP (or ORAN) CU-UP and 3GPP UPF, while the Figure Y similarly represents F1-U slices with traffic between 3GPP (or ORAN) DU and 3GPP (or ORAN) CU-UP. Geng, et al. Expires 12 December 2024 [Page 50] Internet-Draft IETF Network Slice Application in 3GPP 5 June 2024 +----------------------------------+ | Slices in 3GPP domain | | Model defined in IOC TS-28.541 | | NgU/N3 slices | +----+--------------------------+--+ +-----------------|+ | | 3GPP CU-UP / || +-|---------------+ | ORAN O-CU-UP #1 || .-----. | |3GPP (i)UPF #1 | | +---------------V| ,' TN `. +-V--------------+| | | EP_NgU link to | | domain | | EP_N3 link to || | | UPF #1 | ; : | CU-UP #1 || | |+---------------| ; .-------. : +---------------+|| | ||EP_Transport 10+------(Slice 10 )------|EP_Transport 10||| | |+---------------| | `-------' | +---------------+|| | | | | | | || | |+---------------| : .-------. ; +----------------|| | ||EP_Transport 20+------(Slice 20 )------|EP_Transport 20 || | |+---------------|A : `-------' ; A+----------------|| | +----------------|| | | |+----------------+| | . . . || | | || . . . | | +----------------|| `. ,' |+----------------+| | | EP_NgU link to || `---' || EP_NgU link to || | | UPF #N || || CU-UP #N || | +----------------|| |+----------------+| +------------------+| |+-----------------+ | | +------+---------------------+--------+ | logical transport interfaces | | e.g. GTP-U, IPSec endpoint | +-------------------------------------+ Figure 27: Slicing example realization between 3GPP subsystems and TN on the NgU/N3 interface Geng, et al. Expires 12 December 2024 [Page 51] Internet-Draft IETF Network Slice Application in 3GPP 5 June 2024 +----------------------------------+ | Slices in 3GPP domain | | Model defined in IOC TS-28.541 | | F1-U slices | +-+-------------------------+------+ +--------------|+ +|-----------------+ | 3GPP DU / || || 3GPP CU-UP / | | ORAN O-DU #1 || ||ORAN O-CU-UP #1 | | || .-----. || | |+-------------V| ,' TN `. +V---------------+ | || EP_F1-U link | | domain | |EP_F1-U link to | | || to CU-UP #1 | ; : | DU #1 | | |+--------------| ; .-----. : +--------------+ | | ||EP_Transport 1+-------(Slice 1)-------|EP_Transport 1| | | |+--------------| | `-----' | +--------------+ | | || | | | | | | |+--------------| : .-----. ; +--------------+ | | ||EP_Transport 2+-------(Slice 2)-------|EP_Transport 2| | | |+--------------|A : `-----' ; A+--------------+ | | |+--------------|| | | |+----------------+ | | . . . || | | || . . . | |+--------------|| `. ,' |+----------------+ | || EP_F1-U link || `---' ||EP_F1-U link to | | || to CU-UP #N || || DU #N | | |+--------------|| |+----------------+ | +---------------+| |+------------------+ | | | | +------+---------------------+--------+ | logical transport interfaces | | e.g. GTP-U, IPSec endpoint | +-------------------------------------+ Figure 28: Slicing example realization between 3GPP subsystems and TN on the F1-U interface For the transport (i.e., connectivity) related part of a network slice, the key focus is on the EP_Transport IOC. Instances of this IOC serves to instantiate 3GPP interfaces (e.g., N3) which are needed to support Network Slicing and to define Network Slice transport resources within the 5G NRM. In a nutshell, the EP_Transport IOC permits to define additional logical interfaces for each slice instance of the 3GPP user plane. Geng, et al. Expires 12 December 2024 [Page 52] Internet-Draft IETF Network Slice Application in 3GPP 5 June 2024 According to [TS-28.541], the EP_Transport construct on 3GPP side has the following attributes: ipAddress, logicaInterfaceInfo, nextHopInfo, qosProfile and epApplicationRef In which, nextHopInfo could be used for choosing PE node in transport network and LogicalInterfaceInfo could be used for Transport Network Slice mapping. nextHopInfo (optional): identifies the ingress transport node. Each node can be identified by any combination of IP address of next-hop router of transport network, system name, port name and IP management addresses of transport nodes. logicInterfaceInfo (mandatory): a set of parameters, which includes logicInterfaceType and logicInterfaceId. It specifies the type and identifier of a logical interface. It could be a VLAN ID, MPLS Tag or Segment ID. This is assigned uniquely per slice. From the Transport Network domain side, these parameters assist on the definition of the CE transport interface configuration and shall be taken as an input to the transport service model to create coherent Network Slice transport service. Figure 29 illustrates how the EP_Transport parameters can relate to the IETF ones for determining the endpoint connectivity. +-----------------------+ .-----. +-----------------+ | 3GPP CU-UP / | ,' TN `. | 3GPP (i)UPF #1 | | ORAN O-CU-UP #1 | | domain | | | |+----------------------| +-----------+ : +----------------+| ||EP_NgU link to UPF #1 | | PE 1 | : | EP_N3 link to || || | | | : | CU-UP #1 || ||+---------------------| | .-------. | | +---------------+|| ||| EP_Transport for +--+(Slice 10 )+----+---| EP_Transport ||| ||| S-NSSAI FWA | |A`-------' | ; +---------------+|| |||logicInterfaceType = | +|----------+ ; +----------------+| ||| Vlan ID | |: ; +-----------------+ ||| logicInterfaceId = | | | | ||| Vlan 200 | | | | |||ipAddress = 192.0.2.1| | `. ,' ||+--------------A------| | `---' |+---------------|------| +-+-------------------+ +----------------|------+ | nextHopInfoList | | |NextHopInfo = IP/mask| +--------------+------+ | of PE 1 | | epApplicationRef = | | system name = PE 1 | |EP_NgU link to UPF#1 | | port name = Gi1/1 | +---------------------+ +---------------------+ Geng, et al. Expires 12 December 2024 [Page 53] Internet-Draft IETF Network Slice Application in 3GPP 5 June 2024 Figure 29: Example of 3GPP EP_Transport IOC TS-28.541 parameters with correlation to IETF Furthermore, that same parameters should be leveraged for constituting the connectivity construct allowing endpoint interconnection. That is, there is no additional information that could be leveraged at service level that the one provided by EP_Transport, which essentially reflects an endpoint view. Figure 15 represents this relationship between 3GPP and IETF parameters. 3GPP subsystem - CE Transport Network node - PE +----------------------+ +----------------------+ |InformationObjectClass| | IETF Slice Model | | <-----------------> | | EP_Transport | | LxSM + extensions | +----------------------+ +----------------------+ Representation of connectivity: EP_NgU/N3, link between (O)-CU-UP and UPF F1-U, link between (O)-DU and (O)-CU-UP Figure 30: Relationships of the 3GPP parameters with the IETF parameters Leveraging on the EP_Transport information, the IETF NSC should be instructed through its NBI on performing the slice connection. Figure 31 graphically represents the slice connection (e.g., for Ng- U/N3) as expected by 3GPP by using connectivity constructs (of a IETF Network Slice service) to be configured by the IETF Network Slice Controller. Geng, et al. Expires 12 December 2024 [Page 54] Internet-Draft IETF Network Slice Application in 3GPP 5 June 2024 Slices in 3GPP domain Slices in 3GPP domain Model defined in IOC TS-28.541 Model defined in IOC TS-28.541 +------------------+ +------------------+ |3GPP CU-UP / ORAN | | 3GPP UPF #1 | | O-CU-UP #1 | Slices in IETF domain | | | | | | |+-----------------| +----+ +----+ +-----------------+| || EP_NgU link to | |PE 1| |PE 2| | EP_N3 link to || || UPF #1 | | | .-. | | | CU-UP #1 || ||+----------------| | | | | | | +----------------+|| ||| EP_Transport | | | | | | | |EP_Transport for||| |||for S-NSSAI 100 o--------------PDU 1-------------o S-NSSAI 100 ||| ||| Vlan 100 | | | | | | | | Vlan 100 ||| ||| IP 192.0.2.1 |<--->| | ; : | |<-->|IP 198.51.100.1 ||| ||+----------------| | |; :| | +----------------+|| ||+----------------| | || || | +----------------+|| ||| EP_Transport | | || || | |EP_Transport for||| |||for S-NSSAI 200 o--------------PDU 2-------------o S-NSSAI 200 ||| ||| Vlan 200 | | || || | | Vlan 200 ||| ||| IP 192.0.2.2 |<--->| || TN || |<-->|IP 198.51.100.2 ||| ||+----------------| | || || | +----------------+|| || | | || |+----+ +-----------------+| |+-----------------| | || | +------------------+ |+-----------------| | |: ;+----+ +------------------+ || EP_NgU link to | | | : ; |PE 3| | 3GPP UPF #2 | || UPF #2 | | | | | | | +-----------------+| ||Serving S-NSSAI o--------------PDU 3-------------o EP_N3 link to || || 100 |<--->| | : ; | |<-->| CU-UP #1 || |+-----------------| | | : ; | | | Serving S-NSSAI || +------------------+ +----+ `. ,' +----+ | 100 || ' +-----------------+| +------------------+ Figure 31: Example of CU-UP Slice in the 3GPP domain using an IETF Network Slice service From the perspective of IETF Network Slice realization, some of these options could be realized in a straightforward manner while other could require of advanced features (e.g., PBR, SRv6, FlexE, etc). IETF Network Slice service may be a set of techniques and underlaying technologies, so multiple models may be used to define slice. According to the [TS-28.541] attributes in the EP_Transport, the IETF Network Slice may be defined by the following combination of the parameters: Geng, et al. Expires 12 December 2024 [Page 55] Internet-Draft IETF Network Slice Application in 3GPP 5 June 2024 +------------------------------------------------------------------+ | EP_Transport attribute name | | | +---------------+----------------+----------------+----------------+ | ipAddress |logicInterfaceId| nextHopInfo | qosProfile | +---------------+----------------+----------------+----------------+ | Different | Same for all | | per slice | slices | +---------------+---------------------------------+----------------+ | Same for all | Different | Same for all | | slices | per slice | slices | +---------------+----------------+----------------+----------------+ | Different | Same for all | Different | Same for all | | per slice | slices | per slice | slices | +---------------+----------------+----------------+----------------+ | Same for all | Different | Same for all | | slices | per slice | slices | +--------------------------------+----------------+----------------+ | Different | | per slice | +---------------+--------------------------------------------------+ | Same for all | Different | | slices | per slice | +---------------+--------------------------------------------------+ Figure 32: Variations of Slice implementation options From the perspective of IETF Network Slice realization, some of these options could be realized in a straightforward manner while other could require of advanced features (e.g., PBR, SRv6, FlexE, etc). IETF Network Slice service may be a set of techniques and underlaying technologies, so multiple models may be used to define slice. 14. Annex 2: Data Plane Mapping Options The following picture shows the end-to-end network slice in data plane: +--+ +-----+ +----------------+ |UE|- - - -|(R)AN|---------------------------| UPF | +--+ +-----+ +----------------+ |<----AN NS---->|<----------TN NS---------->|<----CN NS----->| Figure 33: End-to-end network slice in data plane The mapping between 3GPP slice and transport slice in user plane could happens in: Geng, et al. Expires 12 December 2024 [Page 56] Internet-Draft IETF Network Slice Application in 3GPP 5 June 2024 (R)AN: User data goes from (radio) access network to transport network Editor's Note: As figure 4.7.1. in [TS-28.530] describes, TN NS will not only exist between AN and CN but may also within AN NS and CN NS. However, here we just show the TN between AN and CN as an example to avoid unnecessary complexity. The following picture shows the user plane protocol stack in end-to- end 5G system. +-----------+ | | | |Application+--------------------|------------------|---------------| +-----------+ | | +-----------+ | | PDU Layer +--------------------|------------------|-| PDU Layer | | +-----------+ +-------------+ | +-------------+ | +-----------+ | | | | ___Relay___ |--|--| ___Relay___ |-|-| | | | | | \/ GTP-U|--|--|GTP-U\/ GTP-U|-|-| GTP-U | | | 5G-AN | |5G-AN +------+ | +------+------+ | +-----------+ | | Protocol | |Protoc|UDP/IP|--|--|UDP/IP|UDP/IP|-|-| UDP/IP | | | Layers | |Layers+------+ | +------+------+ | +-----------+ | | | | | L2 |--|--| L2 | L2 |-|-| L2 | | | | | +------+ | +------+------+ | +-----------+ | | | | | L1 |--|--| L1 | L1 |-|-| L1 | | +-----------+ +-------------+ | +-------------+ | +-----------+ | UE 5G-AN | UPF | UPF | N3 N9 N6 Figure 34: User plane protocol stack in end-to-end 5G system The following figure shows the typical encapsulation in N3 interface. +------------------------+ | Application Protocols | +------------------------+ | IP (User) | +------------------------+ | GTP | +------------------------+ | UDP | +------------------------+ | IP | +------------------------+ | Ethernet | +------------------------+ Figure 35: Typical encapsulation in N3 interface Geng, et al. Expires 12 December 2024 [Page 57] Internet-Draft IETF Network Slice Application in 3GPP 5 June 2024 14.1. Layer 3 and Layer 2 Encapsulations If the encapsulation above IP layer is not visible to Transport Network, it is not able to be used for network slice interworking with transport network. In this case, IP header and Ethernet header could be considered to provide information of network slice interworking from AN or CN to TN. +------------------------+----------- | Application Protocols | ^ +------------------------+ | | IP (User) | Invisible +------------------------+ for | GTP | TN +------------------------+ | | UDP | V +------------------------+------------ | IP | +------------------------+ | Ethernet | +------------------------+ Figure 36: IP header for network slice interworking The following field in IP header and Ethernet header could be considered: IP Header: * DSCP: It is traditionally used for the mapping of QoS identifier between AN/CN and TN network. Although some values (e.g. The unassigned code points) may be borrowed for the network slice interworking, it may cause confusion between QoS mapping and network slicing mapping.; * Destination Address: It is possible to allocate different IP addresses for entities in different network slice, then the destination IP address could be used as the network slice interworking identifier. However, it brings additional requirement to IP address planning. In addition, in some cases some AN or CN network slices may use duplicated IP addresses. * Option fields/headers: It requires that both AN and CN nodes can support the encapsulation and decapsulation of the options. Ethernet header Geng, et al. Expires 12 December 2024 [Page 58] Internet-Draft IETF Network Slice Application in 3GPP 5 June 2024 * VLAN ID: It is widely used for the interconnection between AN/CN nodes and the edge nodes of transport network for the access to different VPNs. One possible problem is that the number of VLAN ID can be supported by AN nodes is typically limited, which effects the number of IETF network slices a AN node can attach to. Another problem is the total amount of VLAN ID (4K) may not provide a comparable space as the network slice identifiers of mobile networks. Two or more options described above may also be used together as the IETF Network Slice Interworking ID, while it would make the mapping relationship more complex to maintain. In some other case, when AN or CN could support more layer 3 encapsulations, more options are available as follows: If the AN or CN could support MPLS, the protocol stack could be as follows: +------------------------+----------- | Application Protocols | ^ +------------------------+ | | IP (User) | Invisible +------------------------+ for | GTP | TN +------------------------+ | | UDP | V +------------------------+------------ | MPLS | +------------------------+ | IP | +------------------------+ | Ethernet | +------------------------+ Figure 37: MPLS label for network slice interworking A specified MPLS label could be used to as a IETF Network Slice Interworking ID. If the AN or CN could support SRv6, the protocol stack is as follows: Geng, et al. Expires 12 December 2024 [Page 59] Internet-Draft IETF Network Slice Application in 3GPP 5 June 2024 +------------------------+----------- | Application Protocols | ^ +------------------------+ | | IP (User) | Invisible +------------------------+ for | GTP | TN +------------------------+ | | UDP | V +------------------------+------------ | SRH | +------------------------+ | IPv6 | +------------------------+ | Ethernet | +------------------------+ Figure 38: SRH for network slice interworking The following field could be considered to identify a network slice: SRH: * SRv6 functions: AN/CN is supposed to support the new function extension of SRv6. * Optional TLV: AN/CN is supposed to support the extension of optional TLV of SRH. ### Above Layer 3 Encapsulations If the encapsulation above IP layer is visible to Transport Network, it is able to be used to identify a network slice. In this case, UPD and GTP-U could be considered to provide information of network slice interworking between AN or CN and TN. +------------------------+---------- | Application Protocols | | +------------------------+ Invisible | IP (User) | for +------------------------+ TN | GTP | | +------------------------+------------ | UDP | +------------------------+ | IP | +------------------------+ | Ethernet | +------------------------+ Figure 39: UDP Header for network slice interworking The following field in UDP header could be considered: Geng, et al. Expires 12 December 2024 [Page 60] Internet-Draft IETF Network Slice Application in 3GPP 5 June 2024 UDP Header: * UDP Source port: The UDP source port is sometimes used for load balancing. Using it for network slice mapping would require to disable the load-balancing behavior. A similar approach to this is followed in [I-D.ietf-dmm-tn-aware-mobility] 14.1.1. Consideration of the Virtual Network Functions (VNF) In some 5G network slice deployments, it might be beneficial to deploy RAN and Core network functions such as DU, CU and UPF as virtual network functions (VNF) inside a data center (DC). As an example, consider Figure 40 where the CU and UPF have been deployed as VNF. The definition of the IETF network slice service INS1 stays identical to its PNF counterpart (physical network function) which are discussed in sections 7.2.1 to 7.2.5, i.e., INS1 is an IETF network slice service which provides the connectivity between SDP1 and SDP2 to satisfy certain SLO/SLE. However, the mapping of INS1 might be different from previous use cases. Figure 40 shows one possible solution for mapping of INS1 where the 5G E2E network slice is first mapped inside the data center and then mapped to provider network PE nodes. One potential mapping in the data center is to use VxLAN ID to infer the identification of 5G E2E network slice inside the data center, and any of the options described in 7.2.1 to 7.2.5 in the provider network PE1 and PE2. Geng, et al. Expires 12 December 2024 [Page 61] Internet-Draft IETF Network Slice Application in 3GPP 5 June 2024 <-------------------- INS1 -------------------> Mapping of INS1 Mapping of INS1 in data center in provider network | | SDP1 | | SDP2 | | .---|---. | V V ,' | `. V |------------| ,' V `. |------------| | -------- | ------- ------- | -------- | | | O...........+======================+..........O | | | | | | | PE1 | | PE2 | | | | | | | CU | | | | | | | | UPF | | | -------- | ------- Provider ------- | ------- | | | `. Network ,' | | |------------| `. ,' |------------| DC1 ------- DC2 Legend: DC Data Center O SDP (N3 address) === Mapping of INS1 on Provider Network PE nodes ... Mapping of INS1 in data centers Figure 40: VNF Consideration for IETF Network Slice Mapping 15. Summary From all the options overviewed, it should be noted that current 3GPP Release 16 only supports through EP_Transport IOC the following slice handoff identifier: vlan tag. MPLS or SID labels. Thus, the consideration of more options as the ones here reported is a gap on 3GPP specifications. 16. References 16.1. Normative References [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, . Geng, et al. Expires 12 December 2024 [Page 62] Internet-Draft IETF Network Slice Application in 3GPP 5 June 2024 [I-D.ietf-teas-ietf-network-slice-nbi-yang] Wu, B., Dhody, D., Rokui, R., Saad, T., and J. Mullooly, "A YANG Data Model for the RFC 9543 Network Slice Service", Work in Progress, Internet-Draft, draft-ietf- teas-ietf-network-slice-nbi-yang-13, 9 May 2024, . [I-D.ietf-teas-enhanced-vpn] Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A Framework for Network Resource Partition (NRP) based Enhanced Virtual Private Networks", Work in Progress, Internet-Draft, draft-ietf-teas-enhanced-vpn-19, 24 May 2024, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [I-D.draft-ietf-opsawg-teas-attachment-circuit] Boucadair, M., Roberts, R., de Dios, O. G., Barguil, S., and B. Wu, "YANG Data Models for Bearers and 'Attachment Circuits'-as-a-Service (ACaaS)", Work in Progress, Internet-Draft, draft-ietf-opsawg-teas-attachment-circuit- 13, 29 May 2024, . [RFC9408] Boucadair, M., Ed., Gonzalez de Dios, O., Barguil, S., Wu, Q., and V. Lopez, "A YANG Network Data Model for Service Attachment Points (SAPs)", RFC 9408, DOI 10.17487/RFC9408, June 2023, . [I-D.ietf-teas-ietf-network-slices] Farrel, A., Drake, J., Rokui, R., Homma, S., Makhijani, K., Contreras, L. M., and J. Tantsura, "A Framework for Network Slices in Networks Built from IETF Technologies", Work in Progress, Internet-Draft, draft-ietf-teas-ietf- network-slices-25, 14 September 2023, . 16.2. Informative References Geng, et al. Expires 12 December 2024 [Page 63] Internet-Draft IETF Network Slice Application in 3GPP 5 June 2024 [I-D.ietf-dmm-tn-aware-mobility] Chunduri, U., Kaippallimalil, J., Bhaskaran, S., Tantsura, J., and P. Muley, "Mobility aware Transport Network Slicing for 5G", Work in Progress, Internet-Draft, draft- ietf-dmm-tn-aware-mobility-09, 29 February 2024, . [I-D.ietf-teas-5g-ns-ip-mpls] Szarkowicz, K. G., Roberts, R., Lucek, J., Boucadair, M., and L. M. Contreras, "A Realization of Network Slices for 5G Networks Using Current IP/MPLS Technologies", Work in Progress, Internet-Draft, draft-ietf-teas-5g-ns-ip-mpls- 08, 1 June 2024, . [TS-23.501] "3GPP TS 23.501: System architecture for the 5G System (5GS)", 25 March 2022, . [TS-28.541] "3GPP TS-28.541 Management and orchestration; 5G Network Resource Model (NRM); Stage 2 and stage 3", 7 June 2019, . [TS-28.530] "3GPP TS 28.530 Management and orchestration; Concepts, use cases and requirements", 25 March 2022, . [TS-28.531] "3GPP TS 28.531 Management and orchestration; Provisioning", 25 March 2022, . [TS-28.540] "Management and orchestration; 5G Network Resource Model (NRM); Stage 1", 31 December 2017, . Geng, et al. Expires 12 December 2024 [Page 64] Internet-Draft IETF Network Slice Application in 3GPP 5 June 2024 [TS-28.622] "Telecommunication management; Generic Network Resource Model (NRM) Integration Reference Point (IRP); Information Service (IS)", 22 January 2015, . [TS-38.470] "NG-RAN; F1 general aspects and principles", 25 March 2022, . [TS-28.623] "Generic Network Resource Model (NRM); Integration Reference Point (IRP); Solution Set (SS) definitions", 29 June 2023, . [GST] "GSMA Generic Network Slice Template", 27 January 2023, . [ZSM-003] "ETSI ZSM003 Zero-touch network and Service Management (ZSM); End-to-end management and orchestration of network slicing", June 2021, . [I-D.ietf-teas-nrp-scalability] Dong, J., Li, Z., Gong, L., Yang, G., and G. S. Mishra, "Scalability Considerations for Network Resource Partition", Work in Progress, Internet-Draft, draft-ietf- teas-nrp-scalability-04, 4 March 2024, . [I-D.ietf-teas-ns-ip-mpls] Saad, T., Beeram, V. P., Dong, J., Wen, B., Ceccarelli, D., Halpern, J. M., Peng, S., Chen, R., Liu, X., Contreras, L. M., Rokui, R., and L. Jalil, "Realizing Network Slices in IP/MPLS Networks", Work in Progress, Internet-Draft, draft-ietf-teas-ns-ip-mpls-04, 28 May 2024, . Geng, et al. Expires 12 December 2024 [Page 65] Internet-Draft IETF Network Slice Application in 3GPP 5 June 2024 Contributors Jose Ordonez-Lucena Telefonica Ronda de la Comunicacion, s/n Sur-3 building, 3rd floor Madrid, 28050 Spain Email: joseantonio.ordonezlucena@telefonica.com Ran Pang China Unicom Email: pangran@chinaunicom.cn Liuyan Han China Mobile Email: hanliuyan@chinamobile.com Jaehwan Jin LG U+ Email: daenamu1@lguplus.co.kr Jeff Tantsura Microsoft Email: jefftant.ietf@gmail.com Shunsuke Homma NTT NTT 3-9-11, Midori-cho Musashino-shi,, Japan Email: shunsuke.homma.ietf@gmail.com Xavier de Foy InterDigital Inc. Canada Email: Xavier.Defoy@InterDigital.com Kiran Makhijani Futurewei Networks United States of America Email: kiranm@futurewei.com Geng, et al. Expires 12 December 2024 [Page 66] Internet-Draft IETF Network Slice Application in 3GPP 5 June 2024 Hannu Flinck Nokia Finland Email: hannu.flinck@nokia-bell-labs.com Rainer Schatzmayr Deutsche Telekom Germany Email: rainer.schatzmayr@telekom.de Ali Tizghadam TELUS Communications Inc Canada Email: ali.tizghadam@telus.com Christopher Janz Huawei Canada Canada Email: christopher.janz@huawei.com Henry Yu Huawei Canada Canada Email: henry.yu1@huawei.com Authors' Addresses Xuesong Geng Huawei Technologies China Email: gengxuesong@huawei.com Luis M. Contreras (editor) Telefonica Spain Email: luismiguel.contrerasmurillo@telefonica.com Reza Rokui Ciena Canada Email: rrokui@ciena.com Geng, et al. Expires 12 December 2024 [Page 67] Internet-Draft IETF Network Slice Application in 3GPP 5 June 2024 Jie Dong Huawei Technologies China Email: jie.dong@huawei.com Ivan Bykov Ribbon Communications United States of America Email: Ivan.Bykov@rbbn.com Geng, et al. Expires 12 December 2024 [Page 68]