]> Intel Corporation

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

Futurewei

USA john.kaippallimalil@futurewei.com

Starten Systems

India sbhaskaran@startensystems.com

Nvidia

USA 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 Transport Network (TN) 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 TN slices using UDP source port number of the GTP-U bearer when the TN 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.

Introduction 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) and vehicle-to-X (V2X) and high-performance machine type communications (HMTC). 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, the capabilities of Transport Network (TN) slices and slice characteristics for QoS, hard /soft isolation, protection and other aspects are out of scope of 3GPP standards. Readers should refer to Section 3.2 of for positioning 5G Network Slicing versus Transport Network Slicing. TN slices in this document can be used to realize slices between 3GPP control plane Network Functions (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 and this is not considered further in this document. User plane 5G slice for each user's Protocol Data Unit (PDU) session is mapped to corresponding TN slices and is the focus of this document. A PDU session in 5G is a logical connection that provides a path between a User Equipment (UE) and a data network such as internet. 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., F1-U, N3, N9). The Dynamic Ports range, 49152-65535, is set aside for local and dynamic use by . A deployment can provision values or sub-ranges from this space for the mechanism described here. The number of slices is likely to be far fewer than the source port space available as each slice involves significant configuration to set up and manage. 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. Mapping a 3GPP slice to a TN slice using GTP-U (UDP) source port number is useful when the 3GPP network function and PE for TN slice are in different IP subnets, and using different IP source address instead would require far more configuration. Slice mapping using UDP source port numbers may be used in TN of public or private 3GPP networks. A TN slice across 3GPP interfaces may use multiple technologies or network providers. 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. Several network scenarios and mechanisms to map 3GPP and IETF network slices are found in . Unlike mapping of a fronthaul 3GPP slice to a TN slice, TN slice(s) for 3GPP backhaul (F1-U/N3/N9) corresponds to 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 a TN slice that provides the corresponding characteristics even after handover. This document defines a mechanism where the source UDP port number of a layer 3 GTP bearer (or UDP encapsulated GTP) is used to map a 3GPP slice to the TN slice at the Provider Edge (PE). 3GPP slice management (), Attachment Circuit (AC) in YANG data model for UDP tunnel bearer in provide the basis for the necessary mapping. It is not the purpose of this document to standardize or constrain the implementation of slicing or user plane functionality in 3GPP. This document describes a potential way to map user plane packets of a 3GPP PDU session identified by a 3GPP slice (S-NSSAI) to an IETF Network Slice Service as defined in . provides an overview on how IP transport slices apply in a 3GPP context. describes how to map a 3GPP slice to a TN slice at a provider edge. UDP source port ranges in TN underlays for slice mapping is described in .

Scope of Transport Networks in 5G Slicing 3GPP discusses TN in the context of network slice subnets, but does not specify further details. This section provides an overview of the processes to provision and map 5G slices in backhaul and mid-haul network segments with GTP-U (UDP) source port number.

Backhaul and Mid-haul Transport Network for 5G

depicts a 5G System (5GS) in which a gNB (Next Generation Node B) is split into a gNB-CU-CP (gNB Centralized Unit-Control Plane), multiple gNB-CU-UPs (gNB Centralized Unit-User Plane) and multiple gNB-DUs (gNB Distributed Unit), as described in . In addition, the figure is 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 TN slice provider. The IETF Network Slice Controller (NSC) interfaces with the 3GPP network (customer network) that requests for TN slices (IETF network slice). The 5G management plane in turn requests the Network Slice Controller (NSC) to set up resources and connectivity for the network slice as defined in . 5G E2E network slice orchestration is used to manage the life cycle of 5G E2E network slice across RAN, TN and core network. TN slices configuration via the control plane (i.e., 5G E2E Network Slice Orchestrator, IETF NSC) should be within a limited domain . The TN slice provider and the 3GPP operator enforce a strict boundary so that the source UDP port numbers and other configuration metadata that correspond to slices stay within this limited domain. In this architecture, end-to-end user plane connectivity between the UE and a specific Data Network (DN) is supported by the F1-U interface (between gNB-DU and gNB-CU-UP), the N3 interface between the gNB-CU-UP and the UPF, and the N9 interface between UPFs in the core network. Over these interfaces, GTP-U is used to transport UE PDUs (IPv4, IPv6, IPv4v6, Ethernet or Unstructured) as specified in . Data in each user's PDU session is mapped to corresponding TN slices across N3/N9/F1-U interfaces based on the 5G slice requirements. Multiple UEs traffic (e.g., eMBB) at a location that have the same requirements may use a 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. The TN PE does not consider 5QI in the DiffServ Code Point (DSCP) or GTP-U header for mapping the 5G slice. 3GPP QoS with 5QI and corresponding DSCP mapping can be applied to traffic flows in PDU sessions in the slice independently. Mapping a 3GPP slice to a TN slice using GTP-U (UDP) source port number is described in . The source UDP port numbers that map between a 3GPP slice and TN slice are only exchanged within the user (data) plane of the limited domain between 3GPP operator and TN slice provider to avoid metadata leakage. The gNB-DU can also be split into two entities (O-RU and O-DU) as defined by O-RAN Alliance and therefore the user plane includes the fronthaul interface between O-RU and O-DU. However, as this interface does not rely on GTP-U to transport UE PDU, the fronthaul interface is out of scope of this document. Mid-haul and backhaul are described further in .

Mapping 3GPP Slice to Transport Network Slices

Mid-haul and Backhaul Transport Networks As described in , 3GPP functions gNB-CU (user plane) and gNB-DU may 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 TN slice provider (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 TN slice provider. In this case, the source UDP port number of the GTP-U can be used to indicate the slice in the TN slice provider. The backhaul transport over which the protocols for N3 and N9 interfaces run are described in and . The PDU session is carried over the radio network, and GTP-U transport protocol across N3 and N9 interfaces to the data network. GTP-U between the 3GPP network functions (gNB, UPF) serves as an overlay protocol across one or more MPLS, SRv6 or Ethernet TNs 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 TN slice provider (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 TN slice provider. In this case, the source UDP port number of the GTP-U can be used to indicate the slice in the TN slice provider.

3GPP Slice Configuration Overview 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 may be realized in an NSS at that 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, a TN 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.

Slice Configuration

shows the slice hierarchy described in with 3 communication services enhanced to show the IP transport slice instances (TS1, TS2, TS3). NSSAI consists of an 8 bit Slice/Service Type (SST) and a 24 bit Slice Differentiator (SD) and is represented in as SST(8):SD(24). As an example, when a UE registers with 5GC with NSSAI 0x02:0x0A, 0x01:0x00, 0x03:0x0C or others, 5GC may allow NSSAI 0x01:0x00 in list of NSSAI for the UE based on the request from the UE and other factors in the network. Another factor 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 TN slice during initial attach, and following handover. For example, a UE that attaches to 5GC with S-NSSAI = 0x01:0x00 and served by user plane instances CN1 and AN2 uses TN slice NS = TS2 to provide the resources in the IP network that corresponds to the UE session. Following handover with S-NSSAI = 0x01:0x00, the UE may be served by user plane instances CN1' and AN2' over an IP slice TS2' in the new location.

Slice Mapping using UDP Source Port Number 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 TN (provider edge). The AC is provisioned between a 3GPP user plane node (i.e., gNB, UPF) in, for example, a data center, to a PE router that serves as the service demarcation point for the TN slice. The following paragraphs provide an outline of operations in a 5G system prior to PDU session setup, and during PDU session setup in mapping 3GPP slice to IETF transport slice. It should be noted that outlines of 3GPP procedures below and data structures in are only to illustrate the concepts in the use of YANG data model extensions for layer 3 GTP bearers in . It is not the purpose of this document to standardize or otherwise constrain the implementation of slicing and user plane functionality in 3GPP. Prior to PDU session setup, the TN and 3GPP user plane nodes are provisioned with the necessary information for mapping the slices. The PE router in TN is provisioned to map all packets arriving on a layer 3 attachment circuit (the outer header carrying the GTP-U tunnel), i.e., a UDP source port number/range to corresponding slice characteristics as shown in . 3GPP user plane nodes (gNB, UPF) are provisioned with GTP transport interface information parameters in . Each EP_Transport (a logical transport interface in 5G user plane entities) is configured with an ATTACHMENT_CIRCUIT containing UDP source port number/range for each of the slices (S-NSSAI) supported by the 3GPP user plane node. "ATTACHMENT_CIRCUIT" is one of the enumerated options in connectionPointId (externalEndPointRefList) attribute in EP_Transport. The YANG data model for the layer 3 GTP bearer (UDP tunnel with source port number/range) is defined in and inherits the attachment circuit in . Isolation correctness depends on consistent CE-and-PE provisioning via the YANG data model. Misconfiguration or NSC/management-plane compromise yields cross-tenant slice misassignment. During PDU session setup, the 5G control plane configures parameters to set up the user plane for the UE's PDU session across F1-U, N3 and N9 interfaces. One of parameters configured by the 5G control plane is the S-NSSAI. Data packets of the PDU session can be associated to the EP_Transport /S-NSSAI configured in the user plane entities for forwarding. The ATTACHMENT_CIRCUIT for the per S-NSSAI EP_Transport interface has UDP source port number/range which is used when forwarding a GTP-U packet belonging to the PDU session. The 3GPP user plane node can now associate the provisioned slice and EP_transport to the S-NSSAI signaled for the PDU session. PE ingress filtering binds {AC /CE source address /VLAN} to a permitted source-port range within the subscribed/provisioned limits for each slice per 3GPP operator and drops mismatches or out of bound TN slice usage to prevent oversubscribing or stealing of premium TN slice resources. An example is shown in .

Slice Mapping using UDP source port 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 = 50000 | |+--------------------------+ | |Action: | |+-----------------------------+| | select NS = TS2 | ||Slice Mapping to UPF-CN1-if: || +-------------------+ || S-NSSAI=0x01:0x00 || || EP_Transport: || || - ipAddress = UPF-CN1-if || || - connectionPointIDType = || || "ATTACHMENT_CIRCUIT" || || - connectionPointId = "ac1"--------+ |+-----------------------------+| | +-------------------------------+ | V +-----------------------------------------------+ | * "ac1" properties: | | - vlan-id: 100 | | - src-port = 50000 | | - CE address (gNB-CU): gNB-AN2-if | | - PE address: 203.0.113.0/24 | +-----------------------------------------------+ Note: VLAN (vlan-id) is only illustrative. ]]>

shows the configuration and mapping applied to network instances in a 3GPP network slice subnet and corresponding TN 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 (UDP tunnel) in . In this example, a GTP-U packet at gNB-CU (user plane) is from a UE session with S-NSSAI = 0x01:0x00 and to be forwarded to UPF-CN1 (i.e., as already setup by SMF during PDU session establishment). The associated 3GPP and TN instances in the figure provide mapping to slice resources. The gNB-CU (UP) uses the slice mapping to "ac1" shown in when forwarding the GTP-U packet to UPF-CN1-if with source address of gNB-AN2-if and UDP source port number 50000 (GTP-U /UDP outer encapsulation source port). 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 UDP 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 TN. The slice selector is encoded in the Source Port field of the UDP header that carries the GTP-U PDU. The encapsulated UE payload is not modified. The encapsulating node selects the source-port value before calculating the UDP checksum, so no post-encapsulation rewrite is required. MTU and fragmentation for GTP-U tunneling can continue to use procedures in 3GPP that configure Maximum Transmission Unit (MTU) sizes via Protocol Configuration Options (PCO) during connectivity session setup. Reserved UDP ports or port 0 can trigger unexpected behavior in some systems and should not be used. 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 UDP 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 Authentication Header (AH) and Encapsulating Security Payload (ESP) modes and says that ESP is preferred. Many inter and intra-operator scenarios do not have NATs on the path between 3GPP SEGs (Security Gateways). IPsec encapsulated GTP-U packets and slice information in outer UDP source ports can be used in these cases. However, this method cannot be used as such in scenarios (e.g. mobile virtual network operators) where NATs may be on path, as mandates setting source and destination ports to 4500. Adding mechanisms for UDP port diversity in IPsec/NAT (Network Address Translation) scenarios is beyond the scope of this document and may be addressed in other future work. 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.

Transport Network Underlays Traffic engineered underlay networks are an essential component to realize the slicing defined in this document. TNs 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 TN technologies including enhanced VPN , IP/MPLS and SR-TE . An example with different user plane slice types and transport paths is shown in . 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. shows UDP port ranges, SST, transport path (in this example pseudowire/VPN) and transport path characteristics.

Mapping of Transport Paths on F1-U/N3/N9

In some E2E scenarios, additional path characteristics with finer granularity may be desired in the underlying TN, such as for security. 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 TN technologies that may be used to realize these slices. These are described in .

Acknowledgements 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. Lionel Morand's suggestion to revise the UDP tunnel aspects to be applicable to not just GTPU but also other encapsulations like ESP-UDP makes this document more broadly applicable.

Security Considerations This document specifies the use of UDP source port to identify a (customer) 3GPP slice at the TN provider edge (PE). The YANG data model should conform to security constraints described in and . Isolation correctness depends on consistent CE-and-PE provisioning via the YANG data model. Misconfiguration or NSC/management-plane compromise yields cross-tenant slice misassignment. describes the configuration and management of slices that may be deployed with 3GPP nodes and TN nodes across 3GPP operator and TN provider. Slice selection, and hence resource allocation and isolation, hinges entirely on the UDP source port. To avoid leakage of metadata outside the boundaries of the limited domain () of 3GPP operator (CE) and TN provider (PE), the exchange of UDP source port number over the management and data plane should remain within the limited domain. Since the slice selector (UDP source port) is sent in the clear, segments can be targeted and traffic analysis is possible if this information is available to entities outside the limited domain. A TN slice provider (PE) may serve more than one 3GPP (or other) CE. The PE ingress filtering is necessary to bind {AC /CE source address /VLAN} to a permitted source port range and within the subscribed/provisioned limits for each slice/3GPP operator. This is necessary to prevent any party from injecting or rewriting packets on the CE to PE path, and thus avoid stealing of premium slice resources or oversubscribing and starving a slice. The use of UDP source port field for slice mapping has side effects including spoofing that are outlined in , section 5.1.1. To mitigate spoofing and other attacks, security mechanisms with ACLs and IPsec must be deployed. Overloading the source port as both ECMP entropy and slice selector forces range-based (coarser) validation at the PE, widening the spoofing surface and constraining entropy. Standard ESP-in-UDP in fixes both source and destination ports to 4500 for NAT traversal and this method which requires UDP port diversity cannot be used when there are NATs on path. The configuration and management procedures here should conform to security constraints for slice authentication, isolation, data confidentiality and integrity, and privacy described in section 10 of .

IANA Considerations This document has no requests for IANA code point allocations.

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

References Normative References This protocol specification defines methods to encapsulate and decapsulate IP Encapsulating Security Payload (ESP) packets inside UDP packets for traversing Network Address Translators. ESP encapsulation, as defined in this document, can be used in both IPv4 and IPv6 scenarios. Whenever negotiated, encapsulation is used with Internet Key Exchange (IKE). [STANDARDS-TRACK] The User Datagram Protocol (UDP) provides a minimal message-passing transport that has no inherent congestion control mechanisms. This document provides guidelines on the use of UDP for the designers of applications, tunnels, and other protocols that use UDP. Congestion control guidelines are a primary focus, but the document also provides guidance on other topics, including message sizes, reliability, checksums, middlebox traversal, the use of Explicit Congestion Notification (ECN), Differentiated Services Code Points (DSCPs), and ports. Because congestion control is critical to the stable operation of the Internet, applications and other protocols that choose to use UDP as an Internet transport must employ mechanisms to prevent congestion collapse and to establish some degree of fairness with concurrent traffic. They may also need to implement additional mechanisms, depending on how they use UDP. Some guidance is also applicable to the design of other protocols (e.g., protocols layered directly on IP or via IP-based tunnels), especially when these protocols do not themselves provide congestion control. This document obsoletes RFC 5405 and adds guidelines for multicast UDP usage. This document describes network slicing in the context of networks built from IETF technologies. It defines the term "IETF Network Slice" to describe this type of network slice and establishes the general principles of network slicing in the IETF context. The document discusses the general framework for requesting and operating IETF Network Slices, the characteristics of an IETF Network Slice, the necessary system components and interfaces, and the mapping of abstract requests to more specific technologies. The document also discusses related considerations with monitoring and security. This document also provides definitions of related terms to enable consistent usage in other IETF documents that describe or use aspects of IETF Network Slices. Delivery of network services assumes that appropriate setup is provisioned over the links that connect customer termination points and a provider network. The required setup to allow successful data exchange over these links is referred to as an attachment circuit (AC), while the underlying link is referred to as a "bearer". This document specifies a YANG service data model for ACs. This model can be used for the provisioning of ACs before or during service provisioning (e.g., RFC 9543 Network Slice Service). The document also specifies a YANG service data model for managing bearers over which ACs are established. Network slicing is a feature that was introduced by the 3rd Generation Partnership Project (3GPP) in Mobile Networks. Realization of 5G slicing implies requirements for all mobile domains, including the Radio Access Network (RAN), Core Network (CN), and Transport Network (TN). This document describes a network slice realization model for IP/MPLS networks with a focus on the Transport Network fulfilling the service objectives for 5G slicing connectivity. The realization model reuses many building blocks commonly used in service provider networks at the current time. Futurewei Telefonica Intel Corporation Delivery of network services over a Layer 3 tunnel assumes that the appropriate setup is provisioned over links that connect the customer termination points and provider network. The required setup to allow successful data exchange over these links is referred to as an attachment circuit (AC) while the underlying link for carrying network services is referred to as "bearer", in this case a Layer 3 UDP tunnel. This document specifies an extension for UDP tunnel as Layer 3 bearer to the YANG service data model for AC. 3rd Generation Partnership Project (3GPP) 3rd Generation Partnership Project (3GPP) Institute of Electrical and Electronics Engineers (IEEE) Informative References This document describes a method by which a Service Provider may use an IP backbone to provide IP Virtual Private Networks (VPNs) for its customers. This method uses a "peer model", in which the customers' edge routers (CE routers) send their routes to the Service Provider's edge routers (PE routers); there is no "overlay" visible to the customer's routing algorithm, and CE routers at different sites do not peer with each other. Data packets are tunneled through the backbone, so that the core routers do not need to know the VPN routes. [STANDARDS-TRACK] The early Multiprotocol Label Switching (MPLS) documents defined the form of the MPLS label stack entry. This includes a three-bit field called the "EXP field". The exact use of this field was not defined by these documents, except to state that it was to be "reserved for experimental use". Although the intended use of the EXP field was as a "Class of Service" (CoS) field, it was not named a CoS field by these early documents because the use of such a CoS field was not considered to be sufficiently defined. Today a number of standards documents define its usage as a CoS field. To avoid misunderstanding about how this field may be used, it has become increasingly necessary to rename this field. This document changes the name of the field to the "Traffic Class field" ("TC field"). In doing so, it also updates documents that define the current use of the EXP field. [STANDARDS-TRACK] This document defines the procedures that the Internet Assigned Numbers Authority (IANA) uses when handling assignment and other requests related to the Service Name and Transport Protocol Port Number registry. It also discusses the rationale and principles behind these procedures and how they facilitate the long-term sustainability of the registry. This document updates IANA's procedures by obsoleting the previous UDP and TCP port assignment procedures defined in Sections 8 and 9.1 of the IANA Allocation Guidelines, and it updates the IANA service name and port assignment procedures for UDP-Lite, the Datagram Congestion Control Protocol (DCCP), and the Stream Control Transmission Protocol (SCTP). It also updates the DNS SRV specification to clarify what a service name is and how it is registered. This memo documents an Internet Best Current Practice. This document replaces RFC 7321, "Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)". The goal of this document is to enable ESP and AH to benefit from cryptography that is up to date while making IPsec interoperable. There is a noticeable trend towards network behaviors and semantics that are specific to a particular set of requirements applied within a limited region of the Internet. Policies, default parameters, the options supported, the style of network management, and security requirements may vary between such limited regions. This document reviews examples of such limited domains (also known as controlled environments), notes emerging solutions, and includes a related taxonomy. It then briefly discusses the standardization of protocols for limited domains. Finally, it shows the need for a precise definition of "limited domain membership" and for mechanisms to allow nodes to join a domain securely and to find other members, including boundary nodes. This document is the product of the research of the authors. It has been produced through discussions and consultation within the IETF but is not the product of IETF consensus. Segment Routing (SR) allows a node to steer a packet flow along any path. Intermediate per-path states are eliminated thanks to source routing. SR Policy is an ordered list of segments (i.e., instructions) that represent a source-routed policy. Packet flows are steered into an SR Policy on a node where it is instantiated called a headend node. The packets steered into an SR Policy carry an ordered list of segments associated with that SR Policy. This document updates RFC 8402 as it details the concepts of SR Policy and steering into an SR Policy. Huawei Technologies Telefonica Ciena Huawei Technologies Ribbon Communications Network Slicing is one of the core features of 5G defined in 3GPP, which provides different network service as independent logical networks. To provide 5G network slices services, an end-to-end network slice has to span three network segments: Radio Access Network (RAN), Mobile Core Network (CN) and Transport Network (TN). This document describes the application of the IETF network slice framework in providing 5G end-to-end network slices, including network slice mapping in the management, control and data planes. 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)

Abbreviations

5G-AN –

5G Access Network

5GS –

5G System

5GC –

5G Core

AC –

Attachment Circuit

AH –

Authentication Header

CE –

Customer Edge

CSR –

Cell Site Router

CP –

Control Plane (5G)

CU –

Centralized Unit (5G, gNB)

DN –

Data Network (5G)

DSCP –

DiffServ Code Point

DU –

Distributed Unit (5G, gNB)

eMBB –

enhanced Mobile Broadband (5G)

ESP –

Encapsulating Security Payload

gNB –

Next Generation Node B

GBR –

Guaranteed Bit Rate (5G)

GTP-U –

GPRS Tunneling Protocol - User plane (3GPP)

HMTC –

High-performance Machine Type Communications

MIoT –

Massive IoT (5G)

MPLS –

Multi Protocol Label Switching

MTU –

Maximum Transmission Unit

NAT –

Network Address Translation

NG-RAN –

Next Generation Radio Access Network (i.e., gNB, NG-eNB - RAN functions which connect to 5GC)

NSC –

Network Slice Controller

NSS –

Network Slice Subnet

NSSAI –

Network Slice Selection Assistance Information

NSSI –

Network Slice Subnet Identifier

NSSF –

Network Slice Selection Function

PCO –

Protocol Configuration Options (5G)

PDU –

Protocol Data Unit (5G)

PE –

Provider Edge

PW –

Pseudowire

RU –

Radio Unit

SA –

Security Association

SDP –

Service Demarcation Point

S-NSSAI –

Single Network Slice Selection Assistance Information

SD –

Slice Differentiator (5G)

SEG –

Security Gateway (5G)

SST –

Slice and Service Types (5G)

SR –

Segment Routing

TE –

Traffic Engineering

TN –

Transport Network

UDP –

User Datagram Protocol

UE –

User Equipment

UP –

User Plane(5G)

UPF –

User Plane Function (5G)

V2X –

Vehicle-to-Everything

VLAN –

Virtual Local Area Network

URLLC –

Ultra reliable and low latency communications (5G)