Intel Corporation

2191 Laurelwood Rd Santa Clara CA 95054 USA umac.ietf@gmail.com

Futurewei

USA john.kaippallimalil@futurewei.com

Rakuten Symphony

sridhar.bhaskaran@rakuten.com

Nvidia

jefftant.ietf@gmail.com

Telefonica

Telefonica Sur-3 building, 3rd floor Madrid 28050 Spain luismiguel.contrerasmurillo@telefonica.com

Internet DMM Working Group network slicing Network slicing in 5G enables logical networks for communication services of multiple 5G customers to be multiplexed over the same infrastructure. While 5G slicing covers logical separation of various aspects of 5G infrastructure and services, user's data plane packets over the Radio Access Network (RAN) and Core Network (5GC) use IP in many segments of an end-to-end 5G slice. When end-to-end slices in a 5G System use network resources, they are mapped to corresponding IP transport network slice(s) which in turn provide the bandwidth, latency, isolation, and other criteria required for the realization of a 5G slice. This document describes mapping of 5G slices to transport network slices using UDP source port number of the GTP-U bearer when the IP transport network (slice provider) is separated by an "attachment circuit" from the networks in which the 5G network functions are deployed, for example, 5G functions that are distributed across data centers. The slice mapping defined here is supported transparently when a 5G user device moves across 5G attachment points and session anchors.

3GPP architecture for 5G System (5GS) in , and for 5GC (5G Core), and the NG-RAN architecture defined in and describe slicing as one of the capabilities for the communication services that 5G systems provide. Slice types defined by the 3GPP include enhanced mobile broadband (eMBB) communications, ultra-reliable low latency communications (URLLC), massive internet of things (MIoT), vehicle-to-X (V2X) and high-performance machine type communications (HMTC). Other types can be defined in the future to include new slice types. 5G network slicing is defined by the 3GPP as an approach, "where logical networks/partitions are created, with appropriate isolation, resources, and optimized topology to serve a purpose or service category (e.g. use case/traffic category, or for MNO internal reasons) or customers logical system created "on-demand". A 5G slice instance requested by an end-user is realized by a 5G network slice subnet (NSS) which is a collection of network functions across RAN and 5GC that make up the 5G slice. However, 3GPP standards do not specify the capabilities of transport network (TN) slices or slice characteristics for QoS, hard /soft isolation, protection and other aspects. A TN slice across 3GPP interfaces N3, N9 and F1U may use multiple technologies or network providers. The slice in the 3GPP domain is mapped to each corresponding TN on the path. 5G system slices for the distributed infrastructure and NFs that make up the 5GS, and 5G slices provided to its end users (via UE) are mapped to TN slices to provide the corresponding level of bandwidth, isolation, and other capabilities. A 3GPP F1-U slice subnet instance may be used to carry all user traffic between a gNB-DU and gNB-CU since the lower layers of the radio access do not differentiate by user. On the other hand, an end-user's traffic for eMBB service and assigned 3GPP slice may be mapped to a different TN slice across N3 and N9 segments than traffic for URLLC service. Unlike mapping of a fronthaul 3GPP slice to a TN slice, the TN slice that F1-U/N3/N9 slice is mapped to is aware of the slice characteristics of the UE session during initial setup (user initiates 3GPP connectivity session) and following UE mobility. For example, a UE served by the 3GPP system for high throughput, low latency service and related 3GPP slice should be mapped to an TN slice that provides the corresponding characteristics even after handover. Several network scenarios and mechanisms to map 3GPP and IETF network slices are found in and . This document defines another mechanism where the source UDP port number of a layer 3 GTP bearer (or UDP encapsulated GTP) is used to map to the TN slice at the Provider Edge (PE). 3GPP slice management () and Attachment Circuit (AC) in provide the basis for the necessary mapping. Extensions to attachment circuit as a service to support a layer 3 GTP-U (or UDP encapsulated GTP) bearer as an attachment circuit is described in and . TN slices in this document can be used to realize slices between 3GPP control plane NFs or for a UE's user plane. For realizing control plane slicing, the TN slice is deployed along the interface between two 3GPP NFs. For realizing a 3GPP slice corresponding to a UE PDU session, the TN slice for each PDU session is mapped to corresponding TN slices and is the focus of this document. Since the 3GPP Single Network Slice Selection Assistance Information (S-NSSAI) is not visible to TNs, the source UDP port number of the GTP-U (or UDP encapsulated GTP) bearer is used to convey a mapping to the TN slices on each 3GPP interface (i.e., F-U, N3, N9). Following UE handover, the S-NSSAI is mapped seamlessly to the corresponding GTP-U (or UDP encapsulated GTP) source port number of the newly attached network and can be considered to be "mobility aware". Slice mapping using UDP source port numbers may be used in TN of public or private 3GPP networks.

3GPP discusses transport network in the context of network slice subnets, but do not specify further details. The application of 5GS slices in transport network for backhaul, mid-haul and front haul are not explicitly covered in 3GPP and is the topic here. To support specific characteristics in backhaul (N3, N9), mid-haul (F1) and front haul, it is necessary to provision corresponding resources in the transport domain and carry a slice identifier that is understood by both the customer (3GPP network) and the provider (TN). This section provides an overview and subsequent sections describe how to provision the mapping information in the TN and apply it so that user plane packets can be provided the transport resources (QoS, isolation, protection, etc.) expected by the 5GS slices.

5G Control and Management Planes +--------------------------------------------------------------------+ | +----------------------------------------------------------------+ | | | 5G E2E Network Slice Orchestrator | | | +---+--------------+-------------+---------------+-----------+---+ | | | | | | | | | +---+--+ | F1-C +----+-----+ | N2 +----+---+ | | | |----------(---------|gNB-CU(CP)|--------(-------| 5GC CP | | | | | | +----+-----+ | +----+---+ | +-| |-----------|-------------|---------------|-----------|-----+ | | | | | | | | +---V---+ | +---V---+ | | | | IETF | | | IETF | | |gNB-DU| | NSC | E1 | NSC | | | | +---+---+ | +---+---+ | | | | | | | | | __ V__ | ___V__ | | | __/ \__ +--+---+ __/ \__ +-+-+ | | / IP/L2 \ | gNB | / IP \ | | UE-+ +--(PE) Mid-haul (PE)--+CU(UP)+--(PE) Backhaul(PE)--+UPF+--DN +------+ \__ __/ +------+ \__ __/ +---+ \______/ \______/ |------ F1-U -------| |----- N3 or N9 -----|

depicts 5GS expanded to show the IP transport and PE (Provider Edge) providing IP transport service to 5GS user plane entities 5G-AN (e.g., gNB) and UPF. Each PE hosts the Service Demarcation Points (SDPs) to the transport network that provides the slice capabilities. The IETF Network Slice Controller (NSC) interfaces with the 3GPP network (customer network) that requests for transport network slices (IETF network slice). The 5G management plane in turn requests the Network Slice Controller (NSC) to setup resources and connectivity in the transport network to realize the network slice. 5G E2E network slice orchestration is used to manage the life cycle of 5G E2E network slice across RAN, TN and core network. In practice, the orchestration and architecture may not be monolithic or uniform. For example, there may be distinct connectivity domains including Data Centers, Public Cloud, Wide Area Networks, and different orchestration entities. Further details are in , section 3. The slices provisioned in the TN correspond to 3GPP slices represented by NSSAI (set of 3GPP slices) available at 3GPP access/data networks and locations. During 3GPP procedures for session initialization, the network grants an S-NSSAI (single one out of the NSSAI) based on the user's session request. The S-NSSAI for the UE's session is signaled to the user plane nodes (gNB, UPF) during the session setup and used to associate to the corresponding TN slice. The N3, N9 and F1-U user planes use GTP-U to transport UE PDUs (IPv4, IPv6, IPv4v6, Ethernet or Unstructured). Unlike the slice requirements for mid-haul segment (F1-U), the slice requirements for the backhaul (N3, N9) are setup in the 3GPP network on a per UE basis. Many UEs traffic (e.g., eMBB) at a location that have the same requirements from a TN slice are mapped to a single TN slice. 3GPP network functions (i.e., gNB-DU, gNB-CU and UPF) may however be distributed (e.g., across multiple data centers) and therefore require multiple TN slices across the respective interfaces. When the gNB functionality is split between a central unit (CU) and a distributed unit (DU), a mid-haul transport segment provides the connectivity as shown in . Further, the gNB central unit can be split into the control plane (CP) and user plane (UP) logical functions as shown in . If the RAN uses lower layer split architecture as specified by O-RAN alliance, then the user plane path from UE to DN also includes the fronthaul interface. The fronthaul interface carries the radio frames in the form of In-phase (I) and Quadrature (Q) samples using eCPRI encapsulation over Ethernet or UDP over IP. Signaling and data transport over the fronthaul transport has no notion of an end-user/UE session, but is rather defined by low latency and other requirements required for processing radio signaling and data transport between the network entities that compose gNB. Data of different users between RAN functions have the same requirements from a TN slice, and can therefore be carried in the same TN slice. There may however be more than one TN slice required for RAN based on the distribution of the RAN functions. For the front-haul described further in , an Ethernet transport with VLANs can be expected to be the case in many deployments. The TN slice may use 5G QoS Indicator (5QI) aware or 5QI unaware treatment in the provider network. If 5QI aware treatment is provisioned, packets in the TN slice will additionally be differentiated by the 5QI value (represented by DSCP in IP header). If 5QI unaware treatment is provisioned, all packets in the TN slice regardless of the 5QI (DSCP value) will be treated by TN slice characteristics. Details of the two layer QoS mechanism are found in section 5 of . Mapping a 3GPP slice to a TN slice using GTP-U (UDP) source port number is described in .

The O-RAN Alliance defined a lower layer split at the physical layer of the radio access network whereby the gNB-DU is split into two entities (O-RU and O-DU) and has specified the fronthaul interface between the O-RU and the O-DU in . The radio layer information, in the form of In-phase (I) and Quadrature (Q) samples are transported using enhanced Common Public Radio Interface (eCPRI) framing over Ethernet or UDP. On an Ethernet based fronthaul interface, the network slice instance (NSI) information is carried in the Ethernet header through the VLAN tags and/or PCP marking. The Ethernet switches in the fronthaul transport network inspects the slice information (VLAN tag and/or PCP marking) in the Ethernet header and provide the provisioned capabilities. The mapping of I and Q samples of different radio resources (radio resource blocks or carriers) to different slices and to their respective VLAN tags and or PCP marking on the fronthaul interface is controlled by the O-RAN fronthaul C-Plane and M-Plane interfaces. The fronthaul transport network is latency and jitter sensitive. The provisioned slice capabilities in the fronthaul transport network MUST take care of the latency and jitter budgets of the specific slice for the fronthaul interface. The provisioning of the fronthaul transport network is handled by the NC pertaining to the fronthaul transport. 3GPP functions gNB-CU (user plane) and gNB-DU may also be distributed and have a mid-haul transport between the two 3GPP network functions. If an IP based mid-haul interface is used, the network slice instance (NSI) information can be MPLS, SRv6 based as defined in . However, if the 3GPP network function (slice customer) is physically separated from the slice provider network (e.g., a gNB-CU (user plane) with baseband units deployed in a data center), the MPLS, SRv6 information may not be practical to carry across to the separated IP transport network (slice provider). In this case, the source UDP port number of the GTP-U can be used to indicate the slice in the transport network (slice provider).

The backhaul transport over which the protocols for N3 and N9 interfaces run are described in and . The end-user (UE) sessions (IP, Ethernet, unstructured) are carried over GTP-U transport protocol over the N3 and N9 interfaces. GTP-U between the 3GPP network functions (gNB, UPF) serves as an overlay protocol across one or more MPLS, SRv6 or Ethernet transport networks in between. During UE session setup, a number of parameters for context management are configured in the gNB, UPF and that includes network slice (S-NSSAI). On an Ethernet based backhaul interface, the slice information is carried in the Ethernet header through the VLAN tags. If an IP based backhaul interface is used, the network slice instance (NSI) information can be MPLS, SRv6 based as defined in . However, if the 3GPP network function (slice customer) is physically separated from the slice provider network (e.g., a gNB-CU (user plane) or UPF, or both are deployed in a data center), the MPLS, SRv6 information may not be practical to carry across to the separated IP transport network (slice provider). In this case, the source UDP port number of the GTP-U can be used to indicate the slice in the IP transport network (slice provider).

Communication services in 3GPP and the concepts to provision and manage it are described in . A brief overview is given here with the intent to describe how it is related to an IP transport slice and the mapping between it and the 3GPP slice. Communication services (e.g., an eMBB service) may be realized in a 3GPP network using one or more slices identified by NSSAI (Network Slice Selection Assistance Information) in the 3GPP control plane signaling. In the 3GPP management plane, the network slice identified by NSSAI is realized in a Network Slice Subnet (NSS). For example, a slice S-NSSAI is available to a user at different locations (and even PLMNs) and maybe realized in an NSS at that a location. An NSS consists of sets of functions from 5GC and RAN that belong to the NSS. Network interfaces of functions in an NSS may be associated to one or more slice subnets. These relationships are illustrated in . From the viewpoint of IP transport slicing and mapping to 3GPP slices, an IP transport network slice is associated to 3GPP core or RAN network functions in a 3GPP Network Slice Subnet (NSS). Thus, it can represent a slice of a transport path for a tenant between two 3GPP user plane functions.

+-------------------+ +-------------------+ +-------------------+ | Comm. Service A | | Comm. Service B | | Comm. Service C | +-----+-------------+ +--+-----+----------+ +--------+----------+ | ______________/ | \ | / | \ +-----+---+---+ +-------+-----+ +------+------+ |NSSAI = 000A | |NSSAI = 000B | |NSSAI = 000C | +-------^-----+ +------^------+ +------^------+ / / | ______/______ _____/_______ ______|_______ \ Net.Slice \ \ Net.Slice \ | Net.Slice | \ Subnet-A \ \ Subnet-B \ | Subnet-C | \ (NSS-A) \ \ (NSS-B) \ | (NSS-C) | \ \ \ \ | | \ +--------+\ \ +--------+\ | +--------+ | \ |NSSI=CN1| \ \ |NSSI=CN1| \ | |NSSI=CN3| | \+-----\--+ \ \+---\----+ \ | +---|----+ | \ \ \ \ \ \ | | | \ +===\====+\ \ +==\=====+ \ | +===|====+ | \ |NS = TS1| \ \|NS = TS2| \ | |NS = TS3| | \+====\===+ \ +====\===+ \ | +===|====+ | \ \ \ \ \ \ | | | \ +--\-----+\ +--------\-----------+ | | \ |NSSI=AN1| \ \ \ +--\-----+ \ | | \+--------+ \ \ \|NSSI=AN2+-----------+ | \____________\ \ +--------+ \ | +----\------------\--------------+ +------------+

shows the slice hierarchy described in with 3 communication services enhanced to show the IP transport slice instances (TS1, TS2, TS3). As an example, when a UE registers with 5GC with NSSAI 000A, OOOB and others, 5GC may select NSSAI 000B in list of NSSAI allowed for the UE. One of the factors in selecting the NSSAI is whether the UE may move to another location during the lifetime of the session. In this case, the NSSAI should be such that it has a mapping to IP transport network slice during initial attach, and following handover. For example, a UE that attaches to 5GC with S-NSSAI = 000B and served by user plane instances CN1 and AN2 uses IP transport network slice NS = TS2 to provide the resources in the IP network that corresponds to the UE session. Following handover with S-NSSAI = 000B, the UE may be served by user plane instances CN1' and AN2' over an IP slice TS2' in the new location. When a 3GPP user plane function (5G-AN, UPF) and IP transport PE are on different nodes or separated across a network, the PE router needs to have the means by which to classify the IP packet from 3GPP entity based on some header information. In terminology, this is a scenario where there is an AC between the 3GPP entity (customer edge) and the SDP (Service Demarcation Point) in the IP transport network (provider edge). The AC may, for example, be between a UPF in a data center to a (provider edge) router that serves as the service demarcation point for the transport network slice. The identification information is provisioned between the 5G provider and IP transport network and corresponding information should be carried in each IP packet on the F1-U, N3, N9 interface. For IP transport edge nodes to inspect the transport context information efficiently, it should be carried in an IP header field that is easy to inspect. It may be noted that the F1-U, N3 and N9 interfaces in 5GS are IP interfaces. This is illustrated in .

upstream GTP-U packet =====================================> customer edge attachment slice provider customer edge circuit "ac1" ______ +-------------+ ______ __/ \__ +-----------+ | gNB-CU | __/ \__ / IP \ | UPF | |N3 IP i/f = +--/ Data Center\---(PE) Backhaul (PE)--+N3 IP i/f =| | gNB-AN2-if | \__ Network__/ \__ __/ |UPF-CN1-if | +-------\-----+ \______/ \___\__/ +-----------+ \ \ \ \+-------------------+ +--------------\----------------+ | Slice Mapping: | |+--------------------------+ | |Match: | ||3GPP CP Config: | | | vlan-id = 100 | ||NSSI = AN2 | | | src-port = 5678| |+--------------------------+ | |Action: | |+-----------------------------+| | select NS = TS2 | ||Slice Mapping to UPF-CN1-if: || +-------------------+ || EP_Transport S-NSSAI=000B || || ipAddress = UPF-CN1-if || || connectionPointIDType = || || "ATTACHMENT_CIRCUIT" || || connectionPointId = "ac1" ---------+ |+-----------------------------+| | +-------------------------------+ | V +-----------------------------------------------+ | * "ac1" properties: | | - vlan-id: 100 | | - src-port = 5678 | | - CE address (gNB-CU): gNB-AN2-if | | - PE address: 192.0.2.2/30 | | - Routing: static 198.51.100.0/24 via | | 192.9.2.1 tag primary_UP_slice | +-----------------------------------------------+

shows the configuration and mapping applied to network instances in a 3GPP network slice subnet and corresponding IP transport network instances for sending an upstream GTP packet from gNB-CU (user plane) to UPF. The gNB-CU (user plane) function is in a data center (site 1) and separated from the IP transport slice provider by an AC ("ac1" in ). The AC ("ac1") is for an EP_Transport configured as specified in and realized using and related extensions for GTP in . In this example, a GTP-U packet at gNB-CU (user plane) is from a UE session with S-NSSAI = 000B (and thus associated to 3GPP and IP transport network instances in the figure for providing slice resources). Since the GTP-U packet belongs to a session with S-NSSAI = 000B, the gNB-CU (UP) maps it to UDP port 5678 in the GTP-U header (outer encapsulation source port) and uses VLAN ID 100 based on the slice mapping to EP_Transport and "ac1" as shown in the figure. The slice mapping proposed in this document does not depend on VLANs, however, this example is to illustrate that the UDP mapping can be used in conjunction with other AC properties. The GTP-U packet is forwarded by the data center network to the PE router at IP backhaul network. The PE matches on VLAN ID of GTP-U packet and IP source port to select the provisioned slice (NS = TS2). The GTP-U packet is then forwarded to the UPF. For a downstream GTP-U packet, the UPF customer edge may similarly be attached to a PE and have similar slice configuration and mapping (details are not shown in the figure). PEs can thus be provisioned with a policy based on the source UDP port number (and other identifiers like VLAN) to the underlying transport path and then deliver the QoS/slice resource provisioned in the transport network. The source UDP port number that is encoded is the outer IP (corresponding to GTP-U header) while the inner IP packet (UE payload) is unaltered. The source UDP port number is encoded by the node that creates the GTP-U encapsulation and therefore, this mechanism has no impact on UDP checksum calculations. 3GPP network operators may use IPsec gateways (SEG) to secure packets between two sites - for example over an F1-U, N3 or N9 segment. The IP network slice identifier in the GTP-U packet should be in the outer IP source port number even after IPSec encryption for PE transport routers to inspect and provide the level of service provisioned. Tunnel mode - which is the case for SEG/IPSec gateways - adds an outer IP header in both AH (Authenticated Header) and ESP (Encapsulated Security Payload) modes. The IPSec secured GTP-U packet should be UDP encapsulated and the GTP-U source port number copied to the outer UDP encapsulation source port number for the PE to select the slice. When GTP-U packets use the source port number as an entropy field for load balancing, copying it to the outer UDP source port number would preserve this as intended for load balancing , section 5.1.1. UDP source port and ranges in allow for slice selection at the PE when the UDP source port is also used for load balancing.

Traffic engineered underlay networks are an essential component to realize the slicing defined in this document. Transport networks should be able to realize midhaul, backhaul and control plane slices shown in . This section outlines how GTP/UDP source ports are used to map to slice types. , section 7 describes in more detail how a network slice can be realized over different transport network technologies including enhanced VPN, IP/MPLS and SR-TE. An example with different user plane slice types and transport paths is shown in the figure. In this case with 3 different 3GPP Slice and Service Types (SSTs), 3 transport TE paths are setup. For uplink traffic, an underlying TE transport path may be from a gNB-CU to a UPF for example. A similar downlink path and underlying transport from UPF to gNB-CU is configured. The figure shows UDP port ranges, SST, transport path (in this example pseudowire/VPN) and transport path characteristics.

In some E2E scenarios, security is desired granularly in the underlying transport network. In such cases, there would be a need to have separate sub-ranges under each SST to provide the TE path in preserving the security characteristics. The UDP source port range captured in would be sub-divided to maintain the TE path for the current SSTs with the security. The current solution doesn't provide any mandate on the UE traffic in selecting the type of security. There are many possible transport network technologies that may be used to realize these slices. These are described in .

provided a description of how a GTP-U connection AC can be mapped using source address and port number to an IETF transport slice. To facilitate slice capabilities within a provider network, the AC is a means to bind the slice service that is previously agreed between the customer (i.e., 3GPP network) and provider (i.e., IP network provider). This section uses provisioning of attachment circuits described in and extends it to support UDP tunnels - GTP and encapsulated GTP. The 'l3-service' and 'l3-tunnel-service' in the attachment circuits structure in is used to configure the relevant layer 3 tunnel properties of a UDP tunnel AC. IPv4 and IPv6 properties of the UDP tunnel AC are provided in "ip-connection" and the extension below adds source port number and range for the UDP tunnel.

module: ietf-ac-udpt augment /ac-svc:attachment-circuits/ac-svc:ac/ac-svc:ip-connection /ac-svc:l3-service/ac-svc:l3-tunnel-service /ac-svc:l3-tunnel-service: +--rw (udp-port)? +--:(port-range-or-operator) +--rw source-port-range-or-operator +--rw (port-range-or-operator)? +--:(range) | +--rw lower-port inet:port-number | +--rw upper-port inet:port-number +--:(operator) +--rw operator? operator +--rw port inet:port-number

'l3-tunnel-service' in is extended in this document to carry UDP source port number/range. For encapsulations other than UDP, the underlying transports may use mappings using the relevant constructs native to the respective technology (e.g., MPLS, SR-MPLS and SRv6). This is not covered in this document.

The "ietf-ac-udp-tunnel" module uses definitions in and .

WG List: Author: Mohamed Boucadair "; description "This YANG module defines a YANG model for augmenting the ACaaS service model with UDP Encapsulation as Layer 3 tunnel service. Copyright (c) 2024 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Revised BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices."; revision 2023-11-13 { description "Initial revision."; reference "RFC XXXX: Mobility-aware Transport Network Slicing for 5G"; } identity udp { base ac-common:l3-tunnel-type; description "UDP Encapsulation."; reference "RFC 8085: UDP Usage Guidelines, Section 3.1.11"; } augment "/ac-svc:attachment-circuits/ac-svc:ac" + "/ac-svc:ip-connection/ac-svc:l3-service" + "/ac-svc:l3-tunnel-service/ac-svc:l3-tunnel-service" { when "derived-from-or-self(./type, 'ac-udpt:udp')" { description "Only applicable if l3 service type is UDP encapsualtion."; } description "Augments Layer 3 AC service with required data nodes for UDP encapsulation support."; choice udp-port { description "Choice of specifying the source port number or referring to a group of port numbers."; container source-port-range-or-operator { description "Indicates a set of source ports numbers."; uses packet-fields:port-range-or-operator; } } } } ]]>

Note to RFC Editor: Replace "RFC XXXX" with the RFC number to be assigned to this document. Replace "RFC SSSS" with the RFC number to be assigned to .

Thanks to Young Lee for discussions on this document including 3GPP and IETF slice orchestration in the early discussions. Thanks to Sri Gundavelli, Kausik Majumdar, Hannu Flinck, Joel Halpern, Satoru Matsushima and Tianji Jiang who provided detailed feedback on this document. Mohamed Boucadair provided detailed Yang structures for the ietf-ac-udp-tunnel attachment circuit to make it flexible for use in this document and for future services. Lionel Morand's suggestion to revise the UDP tunnel module to be applicable to not just GTPU but also other encapsulations like ESP-UDP makes this document more broadly applicable.

This section is modeled after the template described in Section 3.7 of . The "ietf-ac-udp-tunnel" YANG module defines a data model that is designed to be accessed via YANG-based management protocols, such as NETCONF and RESTCONF . These protocols have to use a secure transport layer (e.g., SSH , TLS or QUIC and have to use mutual authentication. The Network Configuration Access Control Model (NACM) provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. Data nodes defined in the ietf-ac-udp-tunnel YANG module are writable/creatable/deletable (i.e., config true, which is the default). These data nodes may be considered sensitive or vulnerable in some network environments. Write operations (e.g., edit-config) and delete operations to these data nodes without proper protection or authentication can have a negative effect on network operations. The 'udp-port' information may be used to track a customer of the slice service and may be considered a violation of the customer-provider trust relationship.

IANA is requested to register the following URI in the "ns" subregistry within the "IETF XML Registry" : URI: urn:ietf:params:xml:ns:yang:ietf-ac-udp-tunnel Registrant Contact: The IESG. XML: N/A; the requested URI is an XML namespace. IANA is requested to register the following YANG module in the "YANG Module Names" subregistry within the "YANG parameters" registry. Name: ietf-ac-udp-tunnel Maintained by IANA? N Namespace: urn:ietf:params:xml:ns:yang:ietf-ac-udp-tunnel Prefix: ac-udp-tunnel Reference: RFC XXXX

The following people contributed substantially to the content of this document and should be considered co-authors.

3rd Generation Partnership Project (3GPP) 3rd Generation Partnership Project (3GPP) 3rd Generation Partnership Project (3GPP) 3rd Generation Partnership Project (3GPP) 3rd Generation Partnership Project (3GPP) 3rd Generation Partnership Project (3GPP) 3rd Generation Partnership Project (3GPP) 3rd Generation Partnership Project (3GPP) 3rd Generation Partnership Project (3GPP) O-RAN Alliance (O-RAN)

5G Access Network 5G System Attachment Circuit Cell Site Router Control Plane (5G) Centralized Unit (5G, gNB) Data Network (5G) Distributed Unit (5G, gNB) enhanced Mobile Broadband (5G) Next Generation Node B Guaranteed Bit Rate (5G) GPRS Tunneling Protocol - User plane (3GPP) Massive IoT (5G) Multi Protocol Label Switching Next Generation Radio Access Network (i.e., gNB, NG-eNB - RAN functions which connect to 5GC) Network Slice Controller Network Slice Subnet Network Slice Selection Assistance Information Network Slice Subnet Identifier Network Slice Selection Function Protocol Data Unit (5G) Pseudo Wire Service Demarcation Point Single Network Slice Selection Assistance Information Slice and Service Types (5G) Segment Routing Traffic Engineering User Plane(5G) User Plane Function (5G) Ultra reliable and low latency communications (5G)