Carrying 5G Network Slice Identifiers in IP Headers for QoS Assurance Beyond the 3GPP-Managed Domain

5G network slicing, as defined by the 3rd Generation Partnership Project (3GPP) , enables multiple logical networks to coexist over a shared physical infrastructure, each tailored to specific service characteristics. Each slice is identified by an S-NSSAI (Single Network Slice Selection Assistance Information) and is associated with a set of Service Level Agreements (SLAs) covering parameters such as throughput, latency, and packet loss rate. The 3GPP end-to-end slice architecture spans the Radio Access Network (RAN), the Transport Network (TN), and the Core Network (CN). Within these domains, 3GPP and IETF have jointly developed mechanisms for slice awareness and traffic differentiation. In particular, provides a framework for IETF Network Slices using technologies such as L2VPN, L3VPN, and Segment Routing, while describes the mapping between 3GPP network slice parameters and IETF Network Slice Service models. However, 5G slice traffic frequently traverses networks that lie outside the 3GPP-managed domain. A representative example is the IP backbone network connecting the 5G Core's User Plane Function (UPF) to external service provider networks. When a 5G slice packet exits the UPF and enters the IP backbone, it carries no slice identification information recognizable by IP-layer devices. The IP backbone therefore treats all 5G traffic uniformly, unable to apply per-slice QoS policies or resource guarantees. This document addresses this gap by defining a method to encode the S-NSSAI directly into IP packet headers, enabling routers in the IP backbone to identify the originating 5G slice and apply corresponding QoS assurance policies. The method is designed with the following properties in mind: Backward compatibility: devices that do not implement this specification can safely ignore the new option fields without disrupting forwarding. Incremental deployability: only selected ingress and egress nodes in the IP backbone need to be upgraded; core transit nodes may remain unchanged, or optionally be upgraded on demand. Extensibility: the encoding is self-contained and does not preclude the concurrent use of other IP options or extension headers. This document is informational in nature. It does not specify a mandatory protocol behavior but rather describes a technical approach intended to stimulate discussion within the IETF community on extending 5G slice awareness beyond the 3GPP-managed domain.

This document uses the following terms: IP Backbone Network: A packet-switched network, based on IP technology, that lies outside the 3GPP-managed domain and provides interconnectivity between the 5G Core and external service provider networks. It is operated independently from the 3GPP RAN, TN, and CN, and does not natively implement 3GPP network slice management functions. Slice-Aware Node: A router or forwarding device in the IP backbone that has been upgraded to parse and act upon the S-NSSAI encoded in IP packet headers as defined in this document. Slice-Unaware Node: A router or forwarding device that does not implement the mechanisms defined in this document and forwards packets according to existing IP forwarding rules. Ingress UPF: The User Plane Function (UPF) at the boundary between the 5G Core and the IP backbone, responsible for encoding the S-NSSAI into outbound IP packets. Service Provider Server: A server operated by an external service provider that terminates 5G slice traffic. For downlink traffic, it is responsible for encoding the S-NSSAI into IP packets destined for the 5G Core. This document also uses terms as defined in and .

BOSS: Business and Operations Support System CN: Core Network CSMF: Communication Service Management Function NSC: Network Slice Controller RAN: Radio Access Network SD: Slice Differentiator SDP: Service Demarcation Point SLA: Service Level Agreement SLO: Service Level Objective SLE: Service Level Expectation S-NSSAI: Single Network Slice Selection Assistance Information SST: Slice/Service Type TN: Transport Network UE: User Equipment UPF: User Plane Function

The 3GPP end-to-end 5G network slice architecture encompasses the RAN, TN, and CN. A 5G Network Slice Instance (NSI) is identified by an S-NSSAI composed of a Slice/Service Type (SST) field (8 bits) and an optional Slice Differentiator (SD) field (24 bits), as illustrated below.

+---------+-----------+ | SST | SD | | (8 bits)| (24 bits) | +---------+-----------+ <-------- S-NSSAI ----> The SST field takes values in the range 0-255, where values 0-127 are reserved for standardized slice types and values 128-255 may be operator-defined. The SD field is operator-defined and distinguishes multiple slices of the same service type. The S-NSSAI is unique within a Public Land Mobile Network (PLMN). Within the 3GPP-managed domain, each network function has access to the S-NSSAI associated with a given session and can enforce per-slice policies accordingly. The Transport Network within this domain may additionally use IETF-defined mechanisms (e.g., those described in ) to provide slice-differentiated connectivity with committed SLOs.

In several important deployment scenarios, 5G slice traffic must traverse an IP backbone network that is not part of the 3GPP-managed domain. This network operates under its own administrative domain and its devices are not configured with 3GPP slice management functions. The following figure illustrates the topology:

+------+ +-----+ +----+ +-----+ +-----+ | UE |--| RAN |--| TN |--| CN |--| | +------+ +-----+ +----+ +-----+ | UPF | | | +--+--+ +----------+ | | Service | +----------+------+ | Provider | | IP Backbone Nw |-- | Servers | | (outside 3GPP) | +----------+ +-----------------+ When a slice packet departs the UPF and enters the IP backbone, the S-NSSAI -- which is carried in 3GPP control plane signaling and encoded in domain-internal identifiers (such as VLAN IDs or GTP-U TEID) -- is no longer present in a form recognizable by standard IP routers. The IP backbone therefore cannot determine the slice membership of a packet and is unable to apply differentiated forwarding or QoS policies on a per-slice basis.

defines the framework for IETF Network Slices in networks built from IETF technologies. It establishes the concept of IETF Network Slice Services -- characterized by a set of Service Demarcation Points (SDPs), connectivity constructs, and associated SLOs and SLEs -- and introduces the IETF Network Slice Controller (NSC) as the management and orchestration component. and the present document address complementary but distinct scopes. focuses on the connectivity within the provider-managed network domain, where an NSC can configure network resources and enforce SLOs using mechanisms such as L3VPN, Segment Routing Traffic Engineering, or Enhanced VPN. In this model, the S-NSSAI is not directly visible in the data plane; instead, the NSC translates slice service requests into domain-local resource commitments, as described in . The present document addresses the complementary case: traffic that exits the 3GPP-managed domain entirely and traverses an IP backbone that may not be under the control of any NSC. In this environment, domain-local identifiers (such as VLANs or MPLS labels configured by the NSC) are absent, and there is no NSC to enforce per-slice policies on individual routers. The proposed mechanism of encoding S-NSSAI in IP headers directly provides the identification signal that enables IP backbone nodes to perform slice-aware forwarding without requiring integration with a 3GPP or IETF network slice management system. The two approaches are compatible and can coexist. An operator may deploy -based mechanisms for the Transport Network segment within the 3GPP domain and the S-NSSAI-in-IP-header mechanism defined in this document for the IP backbone segment beyond the 3GPP domain. The UPF serves as the demarcation point where the two approaches meet: on the 3GPP side, the slice is identified through 3GPP and IETF Network Slice mechanisms; on the IP backbone side, the S-NSSAI is encoded in the IP packet header.

describes the application of the IETF Network Slice framework () to 3GPP 5G end-to-end network slices. It specifies how 3GPP slice parameters -- primarily derived from the EP_Transport Information Object Class (IOC) defined in -- are mapped to IETF Network Slice Service parameters expressed in the IETF Network Slice NBI YANG data model . The document covers management- and control-plane mapping procedures, as well as data-plane encoding options including VLAN, MPLS/SR-MPLS, SRv6, Policy-Based Routing, and UDP source port-based methods. The data-plane encoding methods discussed in apply within the 3GPP-managed Transport Network segment. They encode slice context using network-local identifiers that are meaningful within the administrative domain of the transport provider. These identifiers (such as VLAN IDs or SR SIDs) are allocated by the transport provider's NSC and do not persist beyond the provider network boundary. The present document is distinct in that it defines a mechanism for encoding the globally unique S-NSSAI identifier -- rather than a network-local surrogate -- directly into the IP packet header. This mechanism is intended for use on the IP backbone segment that lies outside the transport provider's administrative domain, where network-local identifiers allocated by an NSC are not available. Furthermore, the Gap Analysis section of identifies that 3GPP EP_Transport IOC information is insufficient for fully instructing the IETF NSC in all deployment cases, particularly for virtualized network functions. The present document approaches a related challenge -- the absence of slice context on the IP backbone -- through a complementary data-plane mechanism that does not rely on management-plane coordination between 3GPP and IETF systems.

The relationship between this document and the existing IETF slicing work can be summarized in terms of network segments:

UE -> RAN -> [Transport Network] -> CN/UPF -> [IP Backbone] -> Server | | Addressed by RFC 9543, Addressed by this RFC 9889, and document draft-5g-ns-app The method described in this document is explicitly designed to operate at and beyond the UPF egress boundary. It does not replace or modify any mechanism used within the IETF Network Slice framework; it extends the observable slice context into a network segment where that framework does not currently reach.

The proposed solution comprises three functional components, which together extend 5G network slice awareness into the IP backbone network. The first component is the encoding of the S-NSSAI into outbound IP packet headers. For uplink traffic (from the 5G Core toward the service provider network), the UPF encodes the S-NSSAI of the associated session into the IP header of each packet before forwarding it to the IP backbone. For downlink traffic (from the service provider network toward the 5G Core), the service provider server encodes the S-NSSAI into the IP header of packets that it transmits into the IP backbone. The S-NSSAI value used by the service provider server is obtained through a prior service subscription or provisioning exchange with the mobile network operator. The second component is the specific encoding format for the S-NSSAI in IPv6 headers. The encoding uses the Hop-by-Hop Options extension header, carrying the full 32-bit S-NSSAI value. The detailed formats are specified in . The third component is the slice-aware QoS assurance mechanism in the IP backbone. The IP backbone management system obtains the SLA requirements for each 5G slice from the operator's management systems and configures corresponding QoS policies on slice-aware forwarding devices. When a slice-aware node receives a packet carrying a Slice ID option, it extracts the S-NSSAI value, looks up the corresponding QoS policy, and applies the appropriate forwarding treatment. The QoS enforcement mechanisms themselves (such as priority scheduling, traffic shaping, or traffic engineering) are outside the scope of this document and may be selected from existing IP QoS techniques.

Since the IETF is no longer developing new extensions for IPv4, this draft does not consider schemes that carry S-NSSA information within IPv4 packets. . This option, referred to as the "Slice ID Option", carries the full 32-bit S-NSSAI value. IPv6 extension headers can be designed based on the draft-ietf-6man-enhanced-vpn-vtn-id draft, utilizing the "Context Type" field to define an N:1 or 1:1 mapping from N-SSAID to NRP ID.

The IP backbone management system coordinates with the mobile network operator's management infrastructure to obtain the SLA requirements associated with each active 5G network slice. This coordination is performed through existing inter-system interfaces, such as those provided by the operator's Business and Operations Support System (BOSS), using the Communication Service Management Function (CSMF) as an intermediary when applicable. For each active slice, the management system retrieves the relevant SLA parameters, which may include committed throughput (uplink and downlink), maximum one-way latency, maximum jitter, and maximum packet loss rate. These parameters correspond to the SLO constructs defined in Section 5.1 of . Based on the retrieved SLA parameters, the management system generates QoS policies indexed by S-NSSAI value and distributes these policies to Slice-Aware Nodes in the IP backbone using applicable network management interfaces.

Upon receiving an IP packet, a Slice-Aware Node performs the following sequence of operations. It first inspects the packet for the presence of a Slice ID Option, as defined in . If a Slice ID Option is present, the node extracts the 32-bit S-NSSAI value and uses it as a lookup key in the locally installed QoS policy table. If a matching policy entry is found, the node applies the corresponding forwarding treatment (such as queue selection, traffic marking, or rate limiting) to the packet. If no Slice ID Option is present, or if no matching policy is found, the node forwards the packet according to its default IP forwarding behavior. A Slice-Unaware Node forwards all packets according to default IP forwarding rules. The presence of an unrecognized option in an IPv6 packet does not cause forwarding failure on such nodes, by virtue of the option processing rules defined in .

The following sequence describes the complete operational flow for uplink traffic (UE to service provider server): At slice instantiation time, the 3GPP Core Network Slice Subnet Management Function (CN-NSSMF) provisions the UPF with the mapping between the VLAN ID (or other access-side identifier) and the corresponding S-NSSAI value. The service provider establishes a subscription agreement with the mobile network operator for one or more named slices. As part of this agreement, the service provider obtains the S-NSSAI values identifying each subscribed slice. When the UPF receives an uplink packet from the 5G Core, it determines the S-NSSAI associated with the packet's session using the locally maintained mapping table. The UPF then encodes this S-NSSAI into the IP packet header according to and forwards the packet into the IP backbone. The IP backbone management system has previously configured Slice-Aware Nodes with per-S-NSSAI QoS policies based on SLA parameters obtained from the operator's management system. As the packet traverses the IP backbone, Slice-Aware Nodes extract the S-NSSAI from the packet and apply the corresponding QoS treatment. For downlink traffic, the service provider's server encodes the appropriate S-NSSAI into the IP packet header before transmitting into the IP backbone, enabling the same per-slice QoS treatment for return traffic.

A significant practical advantage of the proposed mechanism is that it supports incremental deployment. Not all nodes in the IP backbone need to be upgraded to support slice-aware processing. An operator can selectively upgrade ingress and egress nodes -- specifically, the UPF-facing border routers and the service-provider-facing border routers -- while leaving core transit nodes unchanged. In this configuration, the border nodes apply per-slice QoS marking (e.g., DSCP remarking) based on the extracted S-NSSAI, and core transit nodes perform standard DSCP-based differentiated service forwarding without needing to process the Slice ID Option directly. This allows the deployment to leverage the existing DiffServ infrastructure of the IP backbone while extending per-slice awareness to the network boundaries.

The slice identification mechanism defined in this document is not limited to the IP backbone between the UPF and external service providers. The same encoding approach is applicable within service provider networks (such as enterprise data center networks or content delivery networks) that wish to maintain per-slice traffic differentiation for 5G services terminating at their servers. In such deployments, the service provider's ingress gateway would be configured to recognize the S-NSSAI encoded in incoming IP packets and apply appropriate internal forwarding policies.

(TBD)

The required IANA will be coverd by . This document does not require any new IANA actions.