Carrying 5G Network Slice Identifiers in IP Headers for QoS Assurance Beyond the 3GPP-Managed Domain
draft-zdz-teas-5g-slice-ipextension-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Cheng Zhou , Jie Dong , Guangyu Zhao | ||
| Last updated | 2026-07-06 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-zdz-teas-5g-slice-ipextension-00
TEAS Working Group C. Zhou
Internet-Draft China Mobile
Intended status: Informational J. Dong
Expires: 7 January 2027 Huawei Technologies
G. Zhao
China Mobile
6 July 2026
Carrying 5G Network Slice Identifiers in IP Headers for QoS Assurance
Beyond the 3GPP-Managed Domain
draft-zdz-teas-5g-slice-ipextension-00
Abstract
3GPP defines 5G network slicing as an end-to-end service spanning the
Radio Access Network (RAN), Transport Network (TN), and Core Network
(CN). Within these domains, dedicated slice-awareness and management
mechanisms are specified by 3GPP. However, when 5G slice traffic
traverses an IP backbone network that lies outside the 3GPP-managed
domain -- such as when a User Plane Function (UPF) connects to an
external service provider network -- slice context information is
lost, and the IP backbone cannot differentiate or assure the quality
of individual slices.
This document proposes a method for preserving 5G network slice
awareness in IP backbone networks by encoding the 3GPP Single Network
Slice Selection Assistance Information (S-NSSAI) directly into IPv6
packet headers. This document also describes the associated
procedures for slice-aware QoS assurance in the IP backbone.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in RFC
2119 [RFC2119].
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/.
Zhou, et al. Expires 7 January 2027 [Page 1]
Internet-Draft Carry 5G Slice ID in IP Backbone July 2026
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 7 January 2027.
Copyright Notice
Copyright (c) 2026 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. Conventions and Terminology . . . . . . . . . . . . . . . . . 4
2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5
3.1. 5G End-to-End Slice Architecture . . . . . . . . . . . . 5
3.2. The IP Backbone Gap . . . . . . . . . . . . . . . . . . . 6
4. Relationship to Existing IETF Network Slice Work . . . . . . 6
4.1. Relationship to RFC 9543 . . . . . . . . . . . . . . . . 7
4.2. Relationship to
draft-ietf-teas-5g-network-slice-application . . . . . . 7
4.3. Complementary Scope . . . . . . . . . . . . . . . . . . . 8
5. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 9
6. Encoding S-NSSAI in IP Packet Headers . . . . . . . . . . . . 9
7. Slice-Aware QoS Assurance in the IP Backbone . . . . . . . . 9
7.1. Control Plane Procedures . . . . . . . . . . . . . . . . 10
7.2. Data Plane Procedures . . . . . . . . . . . . . . . . . . 10
7.3. End-to-End Slice Assurance Flow . . . . . . . . . . . . . 10
8. Deployment Considerations . . . . . . . . . . . . . . . . . . 11
8.1. Incremental Deployment . . . . . . . . . . . . . . . . . 11
8.2. Applicability to Service Provider Networks . . . . . . . 12
9. Security Considerations . . . . . . . . . . . . . . . . . . . 12
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
11.1. Normative References . . . . . . . . . . . . . . . . . . 12
Zhou, et al. Expires 7 January 2027 [Page 2]
Internet-Draft Carry 5G Slice ID in IP Backbone July 2026
11.2. Informative References . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction
5G network slicing, as defined by the 3rd Generation Partnership
Project (3GPP) [TS23.501], 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,
[RFC9543] provides a framework for IETF Network Slices using
technologies such as L2VPN, L3VPN, and Segment Routing, while
[I-D.ietf-teas-5g-network-slice-application] 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.
Zhou, et al. Expires 7 January 2027 [Page 3]
Internet-Draft Carry 5G Slice ID in IP Backbone July 2026
* 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.
2. Conventions and Terminology
2.1. Definitions
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 [RFC9543] and
[I-D.ietf-teas-5g-network-slice-application].
2.2. Abbreviations
BOSS: Business and Operations Support System
CN: Core Network
Zhou, et al. Expires 7 January 2027 [Page 4]
Internet-Draft Carry 5G Slice ID in IP Backbone July 2026
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
3. Problem Statement
3.1. 5G End-to-End Slice Architecture
The 3GPP end-to-end 5G network slice architecture [TS23.501]
[TS28.530] 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 ---->
Figure 1: S-NSSAI Format (32-bit total)
Zhou, et al. Expires 7 January 2027 [Page 5]
Internet-Draft Carry 5G Slice ID in IP Backbone July 2026
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
[RFC9543]) to provide slice-differentiated connectivity with
committed SLOs.
3.2. The IP Backbone Gap
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) | +----------+
+-----------------+
Figure 2: 5G Slice Traffic Traversing the IP Backbone
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.
4. Relationship to Existing IETF Network Slice Work
Zhou, et al. Expires 7 January 2027 [Page 6]
Internet-Draft Carry 5G Slice ID in IP Backbone July 2026
4.1. Relationship to RFC 9543
[RFC9543] 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.
[RFC9543] and the present document address complementary but distinct
scopes. [RFC9543] 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 [RFC9889].
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 [RFC9543]-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.
4.2. Relationship to draft-ietf-teas-5g-network-slice-application
[I-D.ietf-teas-5g-network-slice-application] describes the
application of the IETF Network Slice framework ([RFC9543]) 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 [TS28.541] -- are mapped to IETF Network Slice
Service parameters expressed in the IETF Network Slice NBI YANG data
model [I-D.ietf-teas-ietf-network-slice-nbi-yang]. The document
covers management- and control-plane mapping procedures, as well as
Zhou, et al. Expires 7 January 2027 [Page 7]
Internet-Draft Carry 5G Slice ID in IP Backbone July 2026
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
[I-D.ietf-teas-5g-network-slice-application] 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
[I-D.ietf-teas-5g-network-slice-application] 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.
4.3. Complementary Scope
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
Figure 3: complementary scope
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.
Zhou, et al. Expires 7 January 2027 [Page 8]
Internet-Draft Carry 5G Slice ID in IP Backbone July 2026
5. Solution Overview
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 Section 6.
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.
6. Encoding S-NSSAI in IP Packet Headers
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
[I-D.ietf-6man-enhanced-vpn-vtn-id]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.
7. Slice-Aware QoS Assurance in the IP Backbone
Zhou, et al. Expires 7 January 2027 [Page 9]
Internet-Draft Carry 5G Slice ID in IP Backbone July 2026
7.1. Control Plane Procedures
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 [RFC9543]. 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.
7.2. Data Plane Procedures
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 Section 6. 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 [RFC8200].
7.3. End-to-End Slice Assurance Flow
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.
Zhou, et al. Expires 7 January 2027 [Page 10]
Internet-Draft Carry 5G Slice ID in IP Backbone July 2026
* 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 Section 6 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.
8. Deployment Considerations
8.1. Incremental Deployment
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.
Zhou, et al. Expires 7 January 2027 [Page 11]
Internet-Draft Carry 5G Slice ID in IP Backbone July 2026
8.2. Applicability to Service Provider Networks
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.
9. Security Considerations
(TBD)
10. IANA Considerations
The required IANA will be coverd by
[I-D.ietf-6man-enhanced-vpn-vtn-id]. This document does not require
any new IANA actions.
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.
11.2. Informative References
[I-D.ietf-6man-enhanced-vpn-vtn-id]
Dong, J., Li, Z., Xie, C., Ma, C., and G. S. Mishra,
"Carrying Network Resource (NR) related Information in
IPv6 Extension Headers", Work in Progress, Internet-Draft,
draft-ietf-6man-enhanced-vpn-vtn-id-16, 10 June 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-6man-
enhanced-vpn-vtn-id-16>.
Zhou, et al. Expires 7 January 2027 [Page 12]
Internet-Draft Carry 5G Slice ID in IP Backbone July 2026
[I-D.ietf-teas-5g-network-slice-application]
Geng, X., Contreras, L. M., Rokui, R., Dong, J., and I.
Bykov, "IETF Network Slice Application in 3GPP 5G End-to-
End Network Slice", Work in Progress, Internet-Draft,
draft-ietf-teas-5g-network-slice-application-07, 6 July
2026, <https://datatracker.ietf.org/doc/html/draft-ietf-
teas-5g-network-slice-application-07>.
[I-D.ietf-teas-ietf-network-slice-nbi-yang]
Wu, B., Dhody, D., Rokui, R., Saad, T., and J. Mullooly,
"A YANG Data Model for the RFC 9543 Network Slice
Service", Work in Progress, Internet-Draft, draft-ietf-
teas-ietf-network-slice-nbi-yang-26, 26 May 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-teas-
ietf-network-slice-nbi-yang-26>.
[RFC9543] Farrel, A., Ed., Drake, J., Ed., Rokui, R., Homma, S.,
Makhijani, K., Contreras, L., and J. Tantsura, "A
Framework for Network Slices in Networks Built from IETF
Technologies", RFC 9543, DOI 10.17487/RFC9543, March 2024,
<https://www.rfc-editor.org/info/rfc9543>.
[RFC9889] Szarkowicz, K., Ed., Roberts, R., Ed., Lucek, J.,
Boucadair, M., Ed., and LM. Contreras, "A Realization of
Network Slices for 5G Networks Using Current IP/MPLS
Technologies", RFC 9889, DOI 10.17487/RFC9889, November
2025, <https://www.rfc-editor.org/info/rfc9889>.
[TS23.501] 3GPP, "System architecture for the 5G System (5GS)", 3GPP
TS 23.501, 2024, <https://www.3gpp.org/ftp/Specs/
archive/23_series/23.501/>.
[TS28.530] 3GPP, "Management and orchestration of networks and
network slicing", 3GPP TS 28.530, 2024,
<https://www.3gpp.org/ftp/Specs/
archive/28_series/28.530/>.
[TS28.541] 3GPP, "Management and orchestration; 5G Network Resource
Model (NRM)", 3GPP TS 28.541, 2024,
<https://www.3gpp.org/ftp/Specs/
archive/28_series/28.541/>.
Authors' Addresses
Zhou, et al. Expires 7 January 2027 [Page 13]
Internet-Draft Carry 5G Slice ID in IP Backbone July 2026
Cheng Zhou
China Mobile
Beijing
100053
China
Email: zhouchengyjy@chinamobile.com
Jie Dong
Huawei Technologies
Beijing
100095
China
Email: jie.dong@huawei.com
Guangyu Zhao
China Mobile
Beijing
100053
China
Email: zhaoguangyu@chinamobile.com
Zhou, et al. Expires 7 January 2027 [Page 14]