TEAS Working Group X. Geng Internet-Draft Huawei Technologies Intended status: Informational L. M. Contreras Expires: 11 January 2024 Telefonica R. Rokui Ciena J. Dong Huawei Technologies I. Bykov Ribbon Communications 10 July 2023 IETF Network Slice Application in 3GPP 5G End-to-End Network Slice draft-ietf-teas-5g-network-slice-application-01 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 slices have 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 management plane, control plane and data plane. 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 11 January 2024. Geng, et al. Expires 11 January 2024 [Page 1] Internet-Draft IETF Network Slice Application in 3GPP 5 July 2023 Copyright Notice Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . 12 5. 5G E2E Network Slice Mapping in Management and Control Planes . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.1. Mapping EP_transport to IETF NS CE Endpoints . . . . . . 15 5.2. Mapping IETF NS CE to PE Endpoints . . . . . . . . . . . 16 5.3. 5G E2E Network Slice Mapping in Control Plane . . . . . . 17 6. 5G E2E Network Slice Mapping in Data Plane . . . . . . . . . 17 6.1. Data Plane Mapping Considerations . . . . . . . . . . . . 18 6.2. Methods for Mapping Between 3GPP E2E Network Slice and IETF Network Slice . . . . . . . . . . . . . . . . . . . . . . 20 6.2.1. Mapping based on VLAN ID . . . . . . . . . . . . . . 22 6.2.2. Mapping based on MPLS Label or SR-MPLS SID . . . . . 23 6.2.3. Mapping based on SRv6 SID . . . . . . . . . . . . . . 24 6.2.4. Mapping based on Policy Based Routing (PBR) . . . . . 25 6.2.5. Mapping based on UDP Source Port . . . . . . . . . . 26 7. IETF Network Slice request through IETF Network Slice NBI . . 27 7.1. Example according to CE-mode (OPTION 1) . . . . . . . . . 32 7.2. Example according to PE-mode (OPTION 2) . . . . . . . . . 39 7.3. Example According to PE-mode with Meeting Point Extension of ACaaS (OPTION 3) . . . . . . . . . . . . . . . . . . . 44 8. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . 51 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 52 10. Security Considerations . . . . . . . . . . . . . . . . . . . 52 11. Evolution Considerations . . . . . . . . . . . . . . . . . . 52 Geng, et al. Expires 11 January 2024 [Page 2] Internet-Draft IETF Network Slice Application in 3GPP 5 July 2023 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 52 13. Annex 1: 3GPP Network Slice Mapping Parameters . . . . . . . 52 14. Annex 2: Data Plane Mapping Options . . . . . . . . . . . . . 59 14.1. Layer 3 and Layer 2 Encapsulations . . . . . . . . . . . 61 14.1.1. Consideration of the Virtual Network Functions (VNF) . . . . . . . . . . . . . . . . . . . . . . . . 64 15. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 65 16.1. Normative References . . . . . . . . . . . . . . . . . . 65 16.2. Informative References . . . . . . . . . . . . . . . . . 66 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 71 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). The IETF Network Slice service is defined in [I-D.ietf-teas-ietf-network-slices] as a set of connections between a number of SDPs (e.g., CE, 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. The IETF network slice service is specified in terms of the set of service delivery endpoints 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). Geng, et al. Expires 11 January 2024 [Page 3] Internet-Draft IETF Network Slice Application in 3GPP 5 July 2023 The 5G network slice as defined in [TS-23.501] does not take the transport network slice into consideration. 3GPPintroduces 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. This document addresses the request of IETF Network Slice Services for 3GPP 5G Network Slices. The details about the realization of IETF Network Slices are out of the scope of this document and addressed in other documents such as [I-D.ietf-teas-enhanced-vpn] [I-D.ietf-teas-ns-ip-mpls] [I-D.ietf-teas-nrp-scalability] and [I-D.ietf-teas-5g-ns-ip-mpls]. 2. Terminology 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 [I-D.ietf-teas-ietf-network-slices]. The following abbreviations are used in this document: Geng, et al. Expires 11 January 2024 [Page 4] Internet-Draft IETF Network Slice Application in 3GPP 5 July 2023 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 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 11 January 2024 [Page 5] Internet-Draft IETF Network Slice Application in 3GPP 5 July 2023 <-------------------- 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. 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 EAN 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 11 January 2024 [Page 6] Internet-Draft IETF Network Slice Application in 3GPP 5 July 2023 <-------------- 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 transmit/receive the radio signal. As shown in Figure 3, in Centralized RAN deployment, two groups of network functions exit; NFs1 and NFs2 where NFs2 rocesses the radio signal and is connected to the transport network and NFs1 transmit and receive the carrier signal that is transmitted over the air 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 11 January 2024 [Page 7] Internet-Draft IETF Network Slice Application in 3GPP 5 July 2023 <-------------------- 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 11 January 2024 [Page 8] Internet-Draft IETF Network Slice Application in 3GPP 5 July 2023 <---------------------- 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) 3.4. Relationship Between IETF Network Slices and 3GPP Network Slices For the sake of illustration, the descriptions below all take the TN slice between RAN and CN as an example, and the other cases are similar. Figure 5 shows the correspondence between network entities in 5G slices and IETF slices respectively Geng, et al. Expires 11 January 2024 [Page 9] Internet-Draft IETF Network Slice Application in 3GPP 5 July 2023 +---------------------+ | 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 02333333, 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. See [[I-D.ietf-teas-ietf-network-slices] for details of IETF network slice. 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 11 January 2024 [Page 10] Internet-Draft IETF Network Slice Application in 3GPP 5 July 2023 +-----------+ +-----------+ +-----------+ | 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 The following network slice related identifiers in management plane, control plane and data(user) plane play an important role in 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 signalling process. * IETF Network Slice Identifier: An identifier allocated by IETF Network Slice Controller (NSC) in management plane. In data plane, IETF Network Slice Identifier may be instantiated with existing data plane identifiers and doesn't necessarily require new encapsulation. * IETF Network Slice Interworking Identifier: Data-plane network slice identifier which is used for mapping the end-to-end network slice traffic to specific IETF network slice. The IETF Network Slice Interworking Identifier is a new concept introduced by this draft, which may be instantiated with existing data plane identifiers and doesn't necessarily require new encapsulation. Geng, et al. Expires 11 January 2024 [Page 11] Internet-Draft IETF Network Slice Application in 3GPP 5 July 2023 *Note: the term "IETF Network Slice Interworking Identifier" is proposed but requires further discussion. The term "handoff" is used sometimes along the document with similar purpose. Alignment is needed. Todo by documents editors. 4. 5G E2E Network Slice Mapping Procedure This section provides a general procedure of network slice mapping: +-----------------+ | 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: Relation 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 ID S-NSSAI. 4. 3GPP NSMF sends a request to AN NSSMF for creation of AN Slice, which is out of the scope of this document. Geng, et al. Expires 11 January 2024 [Page 12] Internet-Draft IETF Network Slice Application in 3GPP 5 July 2023 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 NSC (acting as an NSSMF for transport network, from the perspective of the 3GPP Management System)) for creation of IETF Network Slice. The request contains attributes such as endpoints (based on the information from EP_Transport IOC), required SLA along with other IETF network slice attributes. It also contains mapping informatin for IETF Network Slice Interworking Identifier. 7. IETF NSC realizes the IETF Network Slice which satisfies the requirements of the IETF Network Slice Service requested between the specified endpoints (RAN/CN edge nodes). It may assign an IETF slice ID and send it to 3GPP NSMF. 8. The 3GPP NSMF maintains the mapping relationship between S-NSSAI and IETF Network Slice Service ID; 9. When the 3GPP User Equipment (UE) appears, as part of 5G signalling, it may request to be connected to a specific 3GPP Network Slice identified by S-NASSI. Then a GTP tunnel (which is UDP/IP- based) will be created. 10. UE starts sending traffic to AN and the edge of AN encapsulates the packet into a GTP tunnel, adding a Slice Interworking Identifier according to the selected S-NSSAI and send it to the transport network. 11. The transport network edge nodes parse the Slice Interworking identifier in the received packet and maps the packet to the corresponding IETF network slice. It may encapsulate the packet with slice specific identifiers for enforcing the SLA of IETF Network Slice service in the in transport network. 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, which 1) in order to guarantees that IETF network slice could satisfy the requirements of connection between AN and CN, requirement parameters are necessary for ietf network slice northbound interface ; 2) builds up the mapping relationship between NSI identifier and IETF network slice service ID. Service Profile defined in [TS-28.541] represents the requirement of end-to-end network slice instance in 5G network. Parameters defined in Service Profile include Latency, resource sharing level, Geng, et al. Expires 11 January 2024 [Page 13] Internet-Draft IETF Network Slice Application in 3GPP 5 July 2023 availability and so on. How to decompose the end-to-end requirement to the transport network requirement is one of the key issues in Network slice requirement mapping. GSMA (Global System for Mobile Communications Association) defines the [GST] to indicate the network slice requirement from the view of service provider. [I-D.ietf-teas-ietf-network-slice-use-cases] analyzes the parameters of GST and categorize the parameters into three classes, including the attributes with direct impact on the IETF network slice definition. It is a good start for selecting the transport network relevant parameters in order to define Network Slice Profile for Transport Network. Network slice requirement parameters are also necessary for the definition of transport network northbound interface. NSMF delivers SLA/QoS related parameters and mapping related parameters to IETF NSC through the IETF Network Slice Service Interface. 3GPP TN NSSMF will request the IETF Network Slice service adding in the IETF Network Slice service request some slice identifier to the IETF NSC. The mapping relationship between NSI identifier and IETF Network Slice service identifier could be maintained in both 3GPP NSMF and IETF NSC. Then, at the time of provisioning a 3GPP slice, it is required to provide slice connectivity constructs by means of IETF network slices. Then it is necessary to bind two different endpoints, as depicted in Figure 8: * Mapping of EP_Transport (as defined by [TS-28.541]) to the endpoint at the CE side o f the IETF network slice. This is necessary because the IETF Network Slice Controller (NSC) will receive as input for the IETF network slice service the set of endpoints at CE side to be interconnected * Mapping of the endpoints at both CE and PE side. The endpoint at PE side should be elicited by some means by the IETF NSC, in order to establish and set up the connectivity construct intended for the customer slice request, according to the SLOs and SLEs received from the higher level system. ToDo: to add the EP_RP representation in the figure. ToDo: To consider tp move this figure (& related content) before the examples. ToDo: connect this part of teh document with the examples, adding some sentences pointing out to the examples. Geng, et al. Expires 11 January 2024 [Page 14] Internet-Draft IETF Network Slice Application in 3GPP 5 July 2023 3GPP concern ----------- --------- / / / / 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 connectivity meeting points 5.1. Mapping EP_transport to IETF NS CE Endpoints The 3GPP Management system provides the EP_Transport IOC to extend the slice awareness to the transport network. The EP_Transport IOC contains parameters as IP address, additional identifiers (i.e., vlan tag, MPLS label, etc), and associated QoS profile. This IOC is related to the endpoints of the 3GPP managed functions (detailed in the EP_Application IOC). The information captured in the EP_Transport IOC (as part of the 3GPP concern) should be translated into the CE related parameters (as part of the IETF concern). There will be cases where such translation is straightforward, as for instance, when the 3GPP managed functions run on monolithic, purpose- specific network elements, in the way that the IP address attribute from the EP_Transport IOC directly corresponds to the IP address of an interface of such network element. In this case, the information on EP_Transport IOC can be directly passed to the IETF NSC through the IETF Network Slice Service Interface, even though some additional information could be yet required, not being defined yet on 3GPP specifications (e.g., the Geng, et al. Expires 11 January 2024 [Page 15] Internet-Draft IETF Network Slice Application in 3GPP 5 July 2023 mask applicable to the IP address field on EP_Transport). Note that information gaps are further detailed in a summary section at the end of this document. However, there could be other cases where such a relationship is not straightforward. This could be the case of virtualized 3GPP managed functions that could be instantiated on a general-purpose bare-metal server or in a data center. In these other cases it is necessary to define additional means for eliciting the endpoint at the CE side corresponding to the endpoint of the 3GPP-related function. With solely EP_Transport characterization in 3GPP (i.e., according to 3GPP Release 16 specifications), we could expect the NS CE endpoint being identified by a combination of IP address and some additional information such as vlan tag, MPLS label or SR SID that could discriminate against a certain logical interface. The next hop router information is related to the next hop view from the perspective of the 3GPP entity part of the slice, then providing hints for determining the slice endpoint at the other side of the slice boundary. Finally, the QoS profile, if present, helps to determine configurations needed at the PE side to respect the SLOs in the connection between CEs slice endpoints. 5.2. Mapping IETF NS CE to PE Endpoints As described in [I-D.ietf-teas-ietf-network-slices], there are different potential endpoint positions for an IETF NS. |<---------------------- (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 Geng, et al. Expires 11 January 2024 [Page 16] Internet-Draft IETF Network Slice Application in 3GPP 5 July 2023 Figure 9: IETF Network Slice endpoints The information that is passed to the IETF NSC in terms of endpoints is the information relative to the CE side, which is the one known by the slice customer (i.e., the 3GPP Management system, that corresponds to the 3GPP managed functions). From that information, the IETF NSC needs to infer the corresponding endpoint at the PE side, in order to setup the desired connectivity constructs with the SLOs indicated in the request. Being the IETF slice request a technology-agnostic procedure, the identification of the slice endpoints at the PE side should leverage on generic information passed through the IETF Network Slice Service Interface to the IETF NSC. 5.3. 5G E2E Network Slice Mapping in Control Plane There is no explicit interaction between transport network and AN/CN in the 3GPP control plane signalling, but the S-NSSAI defined in [TS-23.501] is treated as the end-to-end network slice identifier in the control plane of AN and CN, which is used in UE registration and PDU session setup. In this draft, it is assumed that there is a correspondence between S-NSSAI and the IETF Network Slice service identifier in the management plane. However, edge nodes between transport network and CN/AN may have IETF control plane protocal interactions, for exmaple routing protocols. ToDo: there is no direct relationship between 3GPP control plane signalling and IETF control plane. Add sentence on this respect to provide some description here (Xuesong). Note: to ensure consistency with NBI YANG model (i.e., service tag) 6. 5G E2E Network Slice Mapping in Data Plane If multiple 5G E2E network slices data flows are carried from one physical interface between AN/CN and TN, there should be a mechanizm for provider edge (PE) nodes to distinguish between these flows in order to apply and to enforce the different SLO/SLE policy to each flow. In other words, a solution needed in order to define an IETF Network Slice Interworking in the data plane. If different network slices are transported through different physical interfaces, 5G E2E network slices could be distinguished by the interface directly. However if all flows from different 5G network slice flows are transported through same interface, the PE nodes needs to be able to distingush each flows. Geng, et al. Expires 11 January 2024 [Page 17] Internet-Draft IETF Network Slice Application in 3GPP 5 July 2023 6.1. Data Plane Mapping Considerations The following picture shows the end-to-end network slice in data plane（taking the IETF network slice between RAN and UPF as an example: The mapping relationship between AN or CN network slice and an IETF Network Slice will be based on a IETF Network Slice Interworking identifier based on the information provided by the EP_Transport IOC. When the packet of an uplink flow goes from AN to TN, the packet is delivered according to the information provided by the EP_Transport IOC (e.g., the information provided in the logicalInterface field); then the encapsulation is read by the edge node of transport network, which maps the packet to the corresponding IETF network slice. <-----AN NS----> <----------TN NS-----------> <---- CN NS-----> +--+ +-----+ +----------------+ |UE|- - - -|(R)AN|---------------------------| UPF | +--+ +-----+ +----------------+ Figure 10: The mapping between 3GPP slice and transport slice The mapping between 3GPP slice and transport slice in user plane could happens in: (R)AN: User data goes from (radio) access network to transport network UPF: User data goes from core network functions to transport network The following picture shows the user plane protocol stack in end-to- end 5G system. ToDo: to add Figure title. Geng, et al. Expires 11 January 2024 [Page 18] Internet-Draft IETF Network Slice Application in 3GPP 5 July 2023 +-----------+ | | | |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 RAN | UPF | UPF | N3 N9 N6 Figure 11: Packet encapsulation in UE/RAN/UPF The following figure shows the typical encapsulation in N3 interface. +------------------------+ | Application Protocols | +------------------------+ | IP (User) | +------------------------+ | GTP | +------------------------+ | UDP | +------------------------+ | IP | +------------------------+ | Ethernet | +------------------------+ Figure 12: Typical packet encapsulation in N3 interface ToDo: to add Figure title. There are several options in the encapsulation that could be used in data plane of network slice mapping. Geng, et al. Expires 11 January 2024 [Page 19] Internet-Draft IETF Network Slice Application in 3GPP 5 July 2023 6.2. Methods for Mapping Between 3GPP E2E Network Slice and IETF Network Slice Referring to Figure 2, Figure 3 and Figure 4, a 5G end-to-end network slice might have one or more IETF network slices. Figure 13 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 14 could represent IETF 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 IETF network slice services.nIt 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 13: Typical IETF Network Slice in 3GPP Network 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 8 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. Geng, et al. Expires 11 January 2024 [Page 20] Internet-Draft IETF Network Slice Application in 3GPP 5 July 2023 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 8(A) and Figure 8(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). <-------------------- 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) Geng, et al. Expires 11 January 2024 [Page 21] Internet-Draft IETF Network Slice Application in 3GPP 5 July 2023 Figure 14: Representation of a Typical IETF Network Slice in 3GPP Network 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 IETF 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.2.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 9, 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 [draft-srld-teas-5g-slicing] for details of this solution and how it is realized by provider network. Geng, et al. Expires 11 January 2024 [Page 22] Internet-Draft IETF Network Slice Application in 3GPP 5 July 2023 <-------------------- 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 15: VLAN hand-off based for IETF Network Slice Realization 6.2.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 10 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 [draft-srld-teas-5g-slicing] for details of this solution and how it is realized by provider network. Geng, et al. Expires 11 January 2024 [Page 23] Internet-Draft IETF Network Slice Application in 3GPP 5 July 2023 <-------------------- 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 16: MPLS label or SR-MPLS SID based IETF Network Slice Mapping 6.2.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 11, 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 [draft-srld-teas-5g-slicing] for details of this solution and how it is realized by provider network. Geng, et al. Expires 11 January 2024 [Page 24] Internet-Draft IETF Network Slice Application in 3GPP 5 July 2023 <-------------------- 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 17: SRV6 hand-off based for IETF Network Slice Mapping 6.2.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 12, 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 IETF 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 11 January 2024 [Page 25] Internet-Draft IETF Network Slice Application in 3GPP 5 July 2023 Once the PE nodes receives the IP packets, it may apply infer the conetext of the 5G E2E netweork 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 realizatiohn of the IETF network slice Figure 18: Policy Based Routing (PBR) based IETF Network Slice Mapping 6.2.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 19, 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 [draft-ietf-dmm-tn-aware-mobility]. Geng, et al. Expires 11 January 2024 [Page 26] Internet-Draft IETF Network Slice Application in 3GPP 5 July 2023 <-------------------- 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 19: UDP source port soluiton for IETF Network Slice Mapping 7. IETF Network Slice request through IETF Network Slice NBI As discussed in [I-D.ietf-teas-ietf-network-slices], to fulfil 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 20 shows the NSC and its NBI interface for 5G. Draft [I-D.ietf-teas-ietf-network-slice-nbi-yang] a addresses the service yang model of the NSC NBI interface for all network slicing use- cases. Geng, et al. Expires 11 January 2024 [Page 27] Internet-Draft IETF Network Slice Application in 3GPP 5 July 2023 +------------------------------------------+ | 5G Customer (Tenant) | +------------------------------------------+ A | V +------------------------------------------+ | 5G E2E Network Slice Orchestrator | +------------------------------------------+ A | NSC NBI V +------------------------------------------+ | IETF Network Slice Controller (NSC) | +------------------------------------------+ A | NSC SBI V +------------------------------------------+ | Network Controller(s) | +------------------------------------------+ Figure 20: IETF Network Slice Controller NBI for 5G As discussed in [I-D.ietf-teas-ietf-network-slices], 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 undelay technology is IP/MPLS/Optics, any IETF models can be used during the realization of 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 9 shows the mapping between NBI to SBI for 5G IETF network slices. Geng, et al. Expires 11 January 2024 [Page 28] Internet-Draft IETF Network Slice Application in 3GPP 5 July 2023 | (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 9: 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 11 January 2024 [Page 29] Internet-Draft IETF Network Slice Application in 3GPP 5 July 2023 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 section 7.1 of 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 draft-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 10: 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. (Editorial note: Summarize gaps in one single section at the end) Geng, et al. Expires 11 January 2024 [Page 30] Internet-Draft IETF Network Slice Application in 3GPP 5 July 2023 (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 sub-sections present several examples for illustrating the mapping of 3GPP objects to IETF NBI YANG model. Geng, et al. Expires 11 January 2024 [Page 31] Internet-Draft IETF Network Slice Application in 3GPP 5 July 2023 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 11. Geng, et al. Expires 11 January 2024 [Page 32] Internet-Draft IETF Network Slice Application in 3GPP 5 July 2023 +-----+ 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 21: CE-mode slice realization example between DU and CU-UP – OPTION 1 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 11 January 2024 [Page 33] Internet-Draft IETF Network Slice Application in 3GPP 5 July 2023 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 12 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 | 1.1.1.2 | | +---------------------------------+ | | remoteipaddress| 100.1.1.2 | | +---------------------------------+ | | epTransportRef |EP_Transport 100| | +---------------------------------+ | A | | | | | V | +-----------------------------------+ | | EP_Transport 100 | | +-----------------------------------+ | | Parameter | Value | | +-----------------------------------+ | | ipAddress | 1.1.1.1 | | +-----------------------------------+ | |logicInterfaceType| vlan | | +-----------------------------------+ | | logicInterfaceId | 100 | | +-----------------------------------+ | | NextHopInfo | 1.1.1.254 | | +-----------------------------------+ | | qosProfile | 5QI100 | | +-----------------------------------+ | | epApplicationRef | EP_F1U CU-UP1 |<--+ +-----------------------------------+ Figure 22: 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 13. Geng, et al. Expires 11 January 2024 [Page 34] Internet-Draft IETF Network Slice Application in 3GPP 5 July 2023 +---------------------------------+ | EP_F1U DU1 |<---+ +---------------------------------+ | | Parameter | Value | | +---------------------------------+ | | localAddress | 100.1.1.2 | | +---------------------------------+ | | remoteipaddress| 1.1.1.2 | | +---------------------------------+ | | epTransportRef |EP_Transport 100| | +---------------------------------+ | A | | | | | V | +-----------------------------------+ | | EP_Transport 100 | | +-----------------------------------+ | | Parameter | Value | | +-----------------------------------+ | | ipAddress | 100.1.1.1 | | +-----------------------------------+ | |logicInterfaceType| vlan | | +-----------------------------------+ | | logicInterfaceId | 100 | | +-----------------------------------+ | | NextHopInfo | 100.1.1.254 | | +-----------------------------------+ | | qosProfile | 5QI100 | | +-----------------------------------+ | | epApplicationRef | EP_F1U DU1 |<--+ +-----------------------------------+ Figure 23: 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 1.1.1.2 at the DU1 side and 100.1.1.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 information should be complemented by other means (e.g., the 3GPP Geng, et al. Expires 11 January 2024 [Page 35] Internet-Draft IETF Network Slice Application in 3GPP 5 July 2023 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 14. SDP1 SDP2 (100.1.1.2) (1.1.1.2) o<----------------- IETF Network Slice ---------------->o + + +|<------------------------- S1 ---------------------->|+ +| |+ +| EP_Transport EP_Transport |+ +| (1.1.1.1) |<------ T1 ---->| (100.1.1.1) |+ +| / v v \ |+ +v / +-----+ +-----+ \ v+ +--+--+ / | PE1 |================| PE2 | \ +-+---+ | + |/ | | | | | | \| + | | o X----------X | | X----------X o | | | | |\ | | /| | | | | | | | \ | | / | | | | | | | Peer SAP| | Peer SAP | | | | | | (1.1.1.254)|================|(100.1.1.254) | | | | | | | | | | | | +-----+ | +-----+ +-----+ | +-----+ Customer | Provider Provider | Customer Edge 1 | Edge 1 Edge 2 | Edge 2 | | AC (vlan 100) AC (vlan 100) Figure 24: 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 different block of prefixes, the NSC can take the decision of Geng, et al. Expires 11 January 2024 [Page 36] Internet-Draft IETF Network Slice Application in 3GPP 5 July 2023 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": "1.1.1.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 11 January 2024 [Page 37] Internet-Draft IETF Network Slice Application in 3GPP 5 July 2023 "ac-id": "100", "ac-ip-address": "1.1.1.1", "ac-ip-prefix-length": ?, "peer-sap-id": "1.1.1.254" } ] }, "status": { } }, { "sdp-id": "02", "node-id": "CU-UP1", "sdp-ip": "100.1.1.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": "100.1.1.1", "ac-ip-prefix-length": ?, "peer-sap-id": "100.1.1.254" }, ] }, "status": { } }, ] }, "connection-groups": { "connection-group": [ { "connection-group-id": "DU-CU", "connectivity-type": "ietf-vpn-common:any-to-any", "connectivity-construct": [ { "cc-id": 1, "a2a-sdp": [ Geng, et al. Expires 11 January 2024 [Page 38] Internet-Draft IETF Network Slice Application in 3GPP 5 July 2023 { "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 15. Geng, et al. Expires 11 January 2024 [Page 39] Internet-Draft IETF Network Slice Application in 3GPP 5 July 2023 +-----+ 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 25: PE-mode slice realization – OPTION 2 The resulting mapping is summarized in Figure 16. Geng, et al. Expires 11 January 2024 [Page 40] Internet-Draft IETF Network Slice Application in 3GPP 5 July 2023 SDP1 SDP2 (With PE1 parameters) (with PE2 parameters) (1.1.1.254) (100.1.1.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 26: 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 11 January 2024 [Page 41] Internet-Draft IETF Network Slice Application in 3GPP 5 July 2023 "status": { }, "sdps": { "sdp": [ { "sdp-id": "01", "node-id": "PE1", "sdp-ip": "1.1.1.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": "1.1.1.254", /* Next HopInfo IP address in EP_Transport, redundant, can be removed */ "ac-ip-prefix-length": ?, /* not available */ "peer-sap-id": "1.1.1.254" } ] }, "status": { } }, { "sdp-id": "02", "node-id": "PE2", "sdp-ip": "100.1.1.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 11 January 2024 [Page 42] Internet-Draft IETF Network Slice Application in 3GPP 5 July 2023 "attachment-circuit": [ { "ac-id": "100", /*logicInterfaceId*/ "ac-ip-address": "100.1.1.254", /* NextHopInfo IP address in EP_Transport, redundant, can be removed */ "ac-ip-prefix-length": ?, /* not available */ "peer-sap-id": "100.1.1.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 11 January 2024 [Page 43] Internet-Draft IETF Network Slice Application in 3GPP 5 July 2023 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 refering to the identifiers that are created using the data models specified in [I-D.boro-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 subsytem 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:attachement- 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.boro-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.boro-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 11 January 2024 [Page 44] Internet-Draft IETF Network Slice Application in 3GPP 5 July 2023 * Physical parameters of the bearer, captured in the "ietf-bearer- svc" YANG Module of [I-D.boro-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 connectiviy 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:attachement-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:attachement-circuits:ac:name" is depicted. Note: Possible values of the attribute, specifyng the type of the connection point identifier "connectionPointIdType" are VLAN, MPLS, Segment, IPv4, IPv6, and Attachment Circuit (AC). In current exmanple Option 3 "Attachment Circuit (AC)" is used. Figure 21 captures Transport-related parameters. Geng, et al. Expires 11 January 2024 [Page 45] Internet-Draft IETF Network Slice Application in 3GPP 5 July 2023 SDP1 SDP2 (With PE1 parameters) (with PE2 parameters) (1.1.1.254) (100.1.1.254) o<--------- IETF Network Slice 1 ------->o + | | + + |<----------- S1 ----------->| + + | | + + | |<------ T1 ------>| | + + v v v v + (1.1.1.1) + +----+ +----+ + (100.1.1.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 21 The following attributes mapping is assumed in this example: ---DU1--- 3GPP NRM {{TS-28.541}} Clause 6.3.18 EP_Transport ipAddress: '1.1.1.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 11 January 2024 [Page 46] Internet-Draft IETF Network Slice Application in 3GPP 5 July 2023 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: '100.1.1.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 11 January 2024 [Page 47] Internet-Draft IETF Network Slice Application in 3GPP 5 July 2023 "sdp-id": "01", "node-id": "PE1", "ietf-ac-glue:ac-ref": [ "ac01-DU1" ** 3GPP NRM {{TS-28.541}} DU1.ConnectionPointInfo."DU1_Meeting_point".connectionPointId ** ] "status": "active" { "sdp-id": "02", "node-id": "PE2", "ietf-ac-glue: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 11 January 2024 [Page 48] Internet-Draft IETF Network Slice Application in 3GPP 5 July 2023 "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": "1.1.1.254", "prefix-length": 24, "address": [ { "address-id": "1", "customer-address": "1.1.1.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 11 January 2024 [Page 49] Internet-Draft IETF Network Slice Application in 3GPP 5 July 2023 "bearer-reference": "line-345" }, "ip-connection": { "ipv4": { "local-address": "100.1.1.254", "prefix-length": 24, "address": [ { "address-id": "1", "customer-address": "100.1.1.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 11 January 2024 [Page 50] Internet-Draft IETF Network Slice Application in 3GPP 5 July 2023 ** 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 11 January 2024 [Page 51] Internet-Draft IETF Network Slice Application in 3GPP 5 July 2023 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 11. Evolution Considerations 3GPP NRM evolution to confiderated 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. 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. Geng, et al. Expires 11 January 2024 [Page 52] Internet-Draft IETF Network Slice Application in 3GPP 5 July 2023 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 11 January 2024 [Page 53] Internet-Draft IETF Network Slice Application in 3GPP 5 July 2023 +----------------------------------+ | 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 22: Slicing example realization between 3GPP subsystems and TN on the NgU/N3 interface Geng, et al. Expires 11 January 2024 [Page 54] Internet-Draft IETF Network Slice Application in 3GPP 5 July 2023 +----------------------------------+ | 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 23: 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 11 January 2024 [Page 55] Internet-Draft IETF Network Slice Application in 3GPP 5 July 2023 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 17 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 = 20.2.2.2 | | `. ,' ||+--------------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 11 January 2024 [Page 56] Internet-Draft IETF Network Slice Application in 3GPP 5 July 2023 Figure 24: 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 18 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 25: 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 19 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 11 January 2024 [Page 57] Internet-Draft IETF Network Slice Application in 3GPP 5 July 2023 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 10.1.1.2 |<--->| | ; : | |<-->| IP 10.1.1.2 ||| ||+----------------| | |; :| | +----------------+|| ||+----------------| | || || | +----------------+|| ||| EP_Transport | | || || | |EP_Transport for||| |||for S-NSSAI 200 o--------------PDU 2-------------o S-NSSAI 200 ||| ||| Vlan 200 | | || || | | Vlan 200 ||| ||| IP 20.2.2.2 |<--->| || TN || |<-->| IP 20.2.2.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 26: 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 11 January 2024 [Page 58] Internet-Draft IETF Network Slice Application in 3GPP 5 July 2023 +------------------------------------------------------------------+ | 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 27: 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 28: 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 11 January 2024 [Page 59] Internet-Draft IETF Network Slice Application in 3GPP 5 July 2023 (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 29: 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 30: Typical encapsulation in N3 interface Geng, et al. Expires 11 January 2024 [Page 60] Internet-Draft IETF Network Slice Application in 3GPP 5 July 2023 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 31: 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 11 January 2024 [Page 61] Internet-Draft IETF Network Slice Application in 3GPP 5 July 2023 * 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 32: 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 11 January 2024 [Page 62] Internet-Draft IETF Network Slice Application in 3GPP 5 July 2023 +------------------------+----------- | Application Protocols | ^ +------------------------+ | | IP (User) | Invisible +------------------------+ for | GTP | TN +------------------------+ | | UDP | V +------------------------+------------ | SRH | +------------------------+ | IPv6 | +------------------------+ | Ethernet | +------------------------+ Figure 33: 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 34: UDP Header for network slice interworking The following field in UDP header could be considered: Geng, et al. Expires 11 January 2024 [Page 63] Internet-Draft IETF Network Slice Application in 3GPP 5 July 2023 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 14 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 14 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 11 January 2024 [Page 64] Internet-Draft IETF Network Slice Application in 3GPP 5 July 2023 <-------------------- 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 35: 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 [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-07, 5 July 2023, . [I-D.ietf-teas-enhanced-vpn] Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A Framework for Enhanced Virtual Private Network (VPN+)", Work in Progress, Internet-Draft, draft-ietf-teas- Geng, et al. Expires 11 January 2024 [Page 65] Internet-Draft IETF Network Slice Application in 3GPP 5 July 2023 enhanced-vpn-13, 6 July 2023, . [I-D.ietf-teas-ietf-network-slice-nbi-yang] Wu, B., Dhody, D., Rokui, R., Saad, T., Han, L., and J. Mullooly, "A YANG Data Model for the IETF Network Slice Service", Work in Progress, Internet-Draft, draft-ietf- teas-ietf-network-slice-nbi-yang-06, 10 July 2023, . [I-D.ietf-teas-ietf-network-slice-use-cases] Contreras, L. M., Homma, S., Ordonez-Lucena, J. A., Tantsura, J., and H. Nishihara, "IETF Network Slice Use Cases and Attributes for the Slice Service Interface of IETF Network Slice Controllers", Work in Progress, Internet-Draft, draft-ietf-teas-ietf-network-slice-use- cases-01, 24 October 2022, . [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 IETF Network Slices", Work in Progress, Internet-Draft, draft-ietf-teas-ietf-network-slices-21, 15 June 2023, . [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, . [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, . 16.2. Informative References Geng, et al. Expires 11 January 2024 [Page 66] Internet-Draft IETF Network Slice Application in 3GPP 5 July 2023 [draft-ietf-dmm-tn-aware-mobility] "Mobility aware Transport Network Slicing for 5G", 19 April 2023, . [draft-srld-teas-5g-slicing] "A Realization of IETF Network Slices for 5G Networks Using Current IP/MPLS Technologies", 23 May 2023, . [GST] "GSMA Generic Network Slice Template", 27 January 2023, . [I-D.boro-opsawg-teas-attachment-circuit] Boucadair, M., Roberts, R., de Dios, O. G., Barguil, S., and B. Wu, "YANG Data Models for 'Attachment Circuits'-as- a-Service (ACaaS)", Work in Progress, Internet-Draft, draft-boro-opsawg-teas-attachment-circuit-07, 10 July 2023, . [I-D.ietf-teas-5g-ns-ip-mpls] Szarkowicz, K. G., Roberts, R., Lucek, J., Boucadair, M., and L. M. Contreras, "A Realization of IETF Network Slices for 5G Networks Using Current IP/MPLS Technologies", Work in Progress, Internet-Draft, draft-ietf-teas-5g-ns-ip- mpls-00, 3 July 2023, . [I-D.ietf-teas-nrp-scalability] Dong, J., Li, Z., Gong, L., Yang, G., Guichard, J., Mishra, G. S., Qin, F., Saad, T., and V. P. Beeram, "Scalability Considerations for Network Resource Partition", Work in Progress, Internet-Draft, draft-ietf- teas-nrp-scalability-02, 2 June 2023, . Geng, et al. Expires 11 January 2024 [Page 67] Internet-Draft IETF Network Slice Application in 3GPP 5 July 2023 [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-02, 13 March 2023, . [TS-23.501] "3GPP TS 23.501: System architecture for the 5G System (5GS)", 25 March 2022, . [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, . [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.622] "Telecommunication management; Generic Network Resource Model (NRM) Integration Reference Point (IRP); Information Service (IS)", 22 January 2015, . Geng, et al. Expires 11 January 2024 [Page 68] Internet-Draft IETF Network Slice Application in 3GPP 5 July 2023 [TS-28.623] "Generic Network Resource Model (NRM); Integration Reference Point (IRP); Solution Set (SS) definitions", 29 June 2023, . [TS-38.470] "NG-RAN; F1 general aspects and principles", 25 March 2022, . [ZSM-003] "ETSI ZSM003 Zero-touch network and Service Management (ZSM); End-to-end management and orchestration of network slicing", June 2021, . 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 Geng, et al. Expires 11 January 2024 [Page 69] Internet-Draft IETF Network Slice Application in 3GPP 5 July 2023 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 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 Geng, et al. Expires 11 January 2024 [Page 70] Internet-Draft IETF Network Slice Application in 3GPP 5 July 2023 Authors' Addresses Xuesong Geng Huawei Technologies Email: gengxuesong@huawei.com Luis M. Contreras Telefonica Email: luismiguel.contrerasmurillo@telefonica.com Reza Rokui Ciena Email: rrokui@ciena.com Jie Dong Huawei Technologies Email: jie.dong@huawei.com Ivan Bykov Ribbon Communications Email: Ivan.Bykov@rbbn.com Geng, et al. Expires 11 January 2024 [Page 71]