Realizing Network Slices in IP/MPLS Networks
draft-ietf-teas-ns-ip-mpls-08
| Document | Type | Active Internet-Draft (teas WG) | |
|---|---|---|---|
| Authors | Tarek Saad , Vishnu Pavan Beeram , Jie Dong , Joel M. Halpern , Shaofu Peng | ||
| Last updated | 2026-06-24 | ||
| Replaces | draft-bestbar-teas-ns-packet | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Document shepherd | Lou Berger | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | lberger@labn.net |
draft-ietf-teas-ns-ip-mpls-08
TEAS Working Group T. Saad
Internet-Draft Cisco Systems Inc.
Intended status: Informational V. Beeram
Expires: 26 December 2026 Juniper Networks
J. Dong
Huawei Technologies
J. Halpern
Ericsson
S. Peng
ZTE Corporation
24 June 2026
Realizing Network Slices in IP/MPLS Networks
draft-ietf-teas-ns-ip-mpls-08
Abstract
Realizing network slices may require the Service Provider to have the
ability to partition a physical network into multiple logical
networks of varying sizes, structures, and functions so that each
slice can be dedicated to specific services or customers. Multiple
network slices can be realized on the same network while ensuring
slice elasticity in terms of network resource allocation. This
document describes a scalable solution to realize network slicing in
IP/MPLS networks by supporting multiple services on top of a single
physical network by requiring compliant domains and nodes to provide
forwarding treatment (scheduling, drop policy, resource usage) based
on slice identifiers.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 26 December 2026.
Saad, et al. Expires 26 December 2026 [Page 1]
Internet-Draft IP/MPLS Network Slicing June 2026
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
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Acronyms and Abbreviations . . . . . . . . . . . . . . . 6
2. Network Resource Slicing Membership . . . . . . . . . . . . . 7
3. IETF Network Slice Realization . . . . . . . . . . . . . . . 7
3.1. Network Topology Filters . . . . . . . . . . . . . . . . 9
3.2. IETF Network Slice Service Request . . . . . . . . . . . 9
3.3. Slice-Flow Aggregation . . . . . . . . . . . . . . . . . 9
3.4. Path Placement over NRP Filtered Topology . . . . . . . . 10
3.5. NRP Policy . . . . . . . . . . . . . . . . . . . . . . . 10
3.6. NRP Policy Installation . . . . . . . . . . . . . . . . . 10
3.7. Path Instantiation . . . . . . . . . . . . . . . . . . . 11
3.8. Service Mapping . . . . . . . . . . . . . . . . . . . . . 11
4. Network Resource Partition Modes . . . . . . . . . . . . . . 11
4.1. Data plane Network Resource Partition Mode . . . . . . . 11
4.2. Control Plane Network Resource Partition Mode . . . . . . 12
4.3. Data and Control Plane Network Resource Partition Mode . 15
5. Network Resource Partition Instantiation . . . . . . . . . . 15
5.1. NRP Policy Definition . . . . . . . . . . . . . . . . . . 16
5.1.1. Network Resource Partition Selector . . . . . . . . . 17
5.1.2. Network Resource Partition Resource Reservation . . . 19
5.1.3. Network Resource Partition Per Hop Behavior . . . . . 20
5.1.4. Network Resource Partition Topology . . . . . . . . . 20
5.2. Network Resource Partition Boundary . . . . . . . . . . . 21
5.2.1. Network Resource Partition Edge Nodes . . . . . . . . 21
5.2.2. Network Resource Partition Interior Nodes . . . . . . 23
5.2.3. Network Resource Partition Incapable Nodes . . . . . 23
5.2.4. Combining Network Resource Partition Modes . . . . . 25
5.2.5. Multi-domain Network Resource Partition
Considerations . . . . . . . . . . . . . . . . . . . 25
6. Mapping Traffic on Slice-Flow Aggregates . . . . . . . . . . 26
6.1. Network Slice-Flow Aggregate Relationships . . . . . . . 27
Saad, et al. Expires 26 December 2026 [Page 2]
Internet-Draft IP/MPLS Network Slicing June 2026
7. Path Selection and Instantiation . . . . . . . . . . . . . . 27
7.1. Applicability of Path Selection to Slice-Flow
Aggregates . . . . . . . . . . . . . . . . . . . . . . . 27
7.2. Applicability of Path Control Technologies to Slice-Flow
Aggregates . . . . . . . . . . . . . . . . . . . . . . . 28
7.2.1. RSVP-TE Based Slice-Flow Aggregate Paths . . . . . . 28
7.2.2. SR Based Slice-Flow Aggregate Paths . . . . . . . . . 28
8. Network Resource Partition Protocol Extensions . . . . . . . 29
9. Outstanding Issues . . . . . . . . . . . . . . . . . . . . . 29
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
11. Security Considerations . . . . . . . . . . . . . . . . . . . 31
12. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 32
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 32
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 33
14.1. Normative References . . . . . . . . . . . . . . . . . . 33
14.2. Informative References . . . . . . . . . . . . . . . . . 34
Appendix A. NRP Mode Examples . . . . . . . . . . . . . . . . . 35
A.1. Data Plane NRP Mode Example . . . . . . . . . . . . . . . 36
A.2. Control Plane NRP Mode Example . . . . . . . . . . . . . 37
A.3. Data and Control Plane NRP Mode Example . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38
1. Introduction
Network slicing allows a Service Provider to create independent and
logical networks on top of a shared physical network infrastructure.
Such network slices can be offered to customers or used internally by
the Service Provider to enhance the delivery of their service
offerings. A Service Provider can also use network slicing to
structure and organize the elements of its infrastructure. The
solution discussed in this document works with any path control
technology (such as RSVP-TE, or SR) that can be used by a Service
Provider to realize network slicing in IP/MPLS networks.
[RFC9543] provides the definition of a network slice for use within
the IETF and discusses the general framework for requesting and
operating IETF Network Slices, their characteristics, and the
necessary system components and interfaces. It also discusses the
function of an IETF Network Slice Controller and the requirements on
its northbound and southbound interfaces.
This document introduces the notion of a Slice-Flow Aggregate which
comprises of one or more IETF network slice traffic streams. It also
describes the Network Resource Partition (NRP) and the NRP Policy
that can be used to instantiate control and data plane behaviors on
select topological elements associated with the NRP that supports a
Slice-Flow Aggregate - refer Section 5.1 for further details.
Saad, et al. Expires 26 December 2026 [Page 3]
Internet-Draft IP/MPLS Network Slicing June 2026
The IETF Network Slice Controller is responsible for the aggregation
of multiple IETF network traffic streams into a Slice-Flow Aggregate,
and for maintaining the mapping required between them. The
mechanisms used by the controller to determine the mapping of one or
more IETF network slice to a Slice-Flow Aggregate are outside the
scope of this document. The focus of this document is on the
mechanisms required at the device level to address the requirements
of network slicing in packet networks.
In a Diffserv (DS) domain [RFC2475], packets requiring the same
forwarding treatment (scheduling and drop policy) are classified and
marked with the respective Class Selector (CS) Codepoint (or the
Traffic Class (TC) field for MPLS packets [RFC5462]) at the DS domain
ingress nodes. Such packets are said to belong to a Behavior
Aggregate (BA) that has a common set of behavioral characteristics or
a common set of delivery requirements. At transit nodes, the CS is
inspected to determine the specific forwarding treatment to be
applied before the packet is forwarded. A similar approach is
adopted in this document to realize network slicing. The solution
proposed in this document does not mandate Diffserv to be enabled in
the network to provide a specific forwarding treatment. If Diffserv
is enabled within the network, the Slice-Flow Aggregate traffic can
further carry a Diffserv CS to enable differentiation of forwarding
treatments for packets within a Slice-Flow Aggregate.
When logical networks associated with an NRP are realized on top of a
shared physical network infrastructure, it is important to steer
traffic on the specific network resources partition that is allocated
for a given Slice-Flow Aggregate. In packet networks, the packets of
a specific Slice-Flow Aggregate may be identified by one or more
specific fields carried within the packet. An NRP ingress boundary
node (where Slice-Flow Aggregate traffic enters the NRP) populates
the respective field(s) in packets that are mapped to a Slice-Flow
Aggregate in order to allow interior NRP nodes to identify and apply
the specific Per NRP Hop Behavior (NRP-PHB) associated with the
Slice-Flow Aggregate. The NRP-PHB defines the scheduling treatment
and, in some cases, the packet drop probability.
This document covers different modes of NRPs and discusses how each
mode can ensure proper placement of Slice-Flow Aggregate paths and
respective treatment of Slice-Flow Aggregate traffic.
1.1. Terminology
The reader is expected to be familiar with the terminology specified
in [RFC9543].
The following terminology is used in the document:
Saad, et al. Expires 26 December 2026 [Page 4]
Internet-Draft IP/MPLS Network Slicing June 2026
IETF Network Slice:
refer to the definition of 'IETF network slice' in [RFC9543].
IETF Network Slice Controller (NSC):
refer to the definition in [RFC9543].
Network Resource Partition:
refer to the definition in [RFC9543].
Slice-Flow Aggregate:
a collection of packets that are mapped to an NRP and are given
the same forwarding treatment; a Slice-Flow Aggregate comprises
one or more IETF network slice traffic streams from one or more
connectivity constructs (belonging to one or more IETF network
slices); the mapping of one or more IETF network slice streams to
a Slice-Flow Aggregate is maintained by the IETF Network Slice
Controller. The boundary nodes MAY also maintain a mapping of
specific IETF network slice service(s) to a Slice-Flow Aggregate.
Network Resource Partition Policy (NRP):
a policy construct that enables instantiation of mechanisms in
support of IETF network slice specific control and data plane
behaviors on select topological elements; the enforcement of an
NRP Policy results in the creation of an NRP.
NRP Identifier (NRP-ID):
an identifier that is globally unique within an NRP domain and
that can be used in the control or management plane to identify
the resources associated with the NRP.
NRP Selector:
one or more fields (markings) in a packet's network layer header
that are used to map the packet to an NRP.
NRP Selector Identifier (NRP Selector ID):
a dedicated identifier that acts as an NRP Selector.
NRP Capable Node:
a node that supports one of the NRP modes described in this
document.
NRP Incapable Node:
a node that does not support any of the NRP modes described in
this document.
Slice-Flow Aggregate Path:
a path that is set up over the NRP that is associated with a
specific Slice-Flow Aggregate.
Saad, et al. Expires 26 December 2026 [Page 5]
Internet-Draft IP/MPLS Network Slicing June 2026
Slice-Flow Aggregate Packet:
a packet that traverses over the NRP that is associated with a
specific Slice-Flow Aggregate.
Filtered Topology:
a topology derived from the physical network by applying topology
filtering policies that select specific nodes and links based on
their capabilities and attributes (e.g., Resource Affinities or
Flexible Algorithm membership). The same Filtered Topology may be
shared by multiple NRPs.
NRP Topology:
the topology resulting from instantiating an NRP on a Filtered
Topology by associating NRP-specific resource reservations and Per
Hop Behavior (NRP-PHB) with the topological elements of the
Filtered Topology. Two NRPs may share the same Filtered Topology
while having different resource reservations and forwarding
treatments.
NRP state aware TE (NRP-TE):
a mechanism for TE path selection that takes into account the
available network resources associated with a specific NRP.
1.2. Acronyms and Abbreviations
BA: Behavior Aggregate
CS: Class Selector
NRP-PHB: NRP Per Hop Behavior as described in Section 5.1.3
SLA: Service Level Agreements
SLO: Service Level Objectives
SLE: Service Level Expectations
Diffserv: Differentiated Services
MPLS: Multiprotocol Label Switching
LSP: Label Switched Path
RSVP: Resource Reservation Protocol
TE: Traffic Engineering
SR: Segment Routing
Saad, et al. Expires 26 December 2026 [Page 6]
Internet-Draft IP/MPLS Network Slicing June 2026
VRF: VPN Routing and Forwarding
AC: Attachment Circuit
CE: Customer Edge
PE: Provider Edge
PCEP: Path Computation Element (PCE) Communication Protocol (PCEP)
2. Network Resource Slicing Membership
An NRP that supports a Slice-Flow Aggregate can be instantiated over
parts of an IP/MPLS network (e.g., all or specific network resources
in the access, aggregation, or core network), and can stretch across
multiple domains administered by a provider. The NRP topology may be
comprised of dedicated and/or shared network resources (e.g., in
terms of processing power, storage, and bandwidth).
The physical network resources may be fully dedicated to a specific
Slice-Flow Aggregate. For example, traffic belonging to a Slice-Flow
Aggregate can traverse dedicated network resources without being
subjected to contention from traffic of other Slice-Flow Aggregates.
Dedicated physical network resource slicing allows for simple
partitioning of the physical network resources amongst Slice-Flow
Aggregates without the need to distinguish packets traversing the
dedicated network resources since only one Slice-Flow Aggregate
traffic stream can traverse the dedicated resource at any time.
To optimize network utilization, sharing of the physical network
resources may be desirable. In such case, the same physical network
resource capacity is divided among multiple NRPs that support
multiple Slice-Flow Aggregates. The shared physical network
resources can be partitioned in the data plane (for example by
applying hardware policers and shapers) and/or partitioned in the
control plane by providing a logical representation of the physical
link that has a subset of the network resources available to it.
3. IETF Network Slice Realization
Figure 1 describes the steps required to realize an IETF network
slice service in a provider network using the solution proposed in
this document. While Figure 4 of [RFC9543] provides an abstract
architecture of an IETF Network Slice, this section intends to offer
a realization of that architecture specific for IP/MPLS packet
networks.
Each of the steps is further elaborated on in a subsequent section.
Saad, et al. Expires 26 December 2026 [Page 7]
Internet-Draft IP/MPLS Network Slicing June 2026
-- -- --
|CE| |CE| |CE|
-- -- --
AC : AC : AC :
---------------------- -------
( |PE|....|PE|....|PE| ) ( IETF )
IETF Network ( --: -- :-- ) ( Network )
Slice Service ( :............: ) ( Slice )
Request ( IETF Network Slice ) ( ) Customer
v ---------------------- ------- View
v ............................\........./...............
v \ / Provider
v >>>>>>>>>>>>>>> Slice-Flow \ / View
v ^ Aggregate Mapping v v
v ^ -----------------------------------------
v ^ ( |PE|.......|PE|........|PE|.......|PE| )
--------- ( --: -- :-- -- )
| | ( :...................: )
| NSC | ( Network Resource Partition )
| | -----------------------------------------
| | ^
| |>>>>> Resource Partitioning |
--------- of Filtered Topology|
v v |
v v ----------------------------- --------
v v (|PE|..-..|PE|... ..|PE|..|PE|) ( )
v v ( :-- |P| -- :-: -- :-- ) ( Filter )
v v ( :.- -:.......|P| :- ) ( Topology )
v v ( |P|...........:-:.......|P| ) ( )
v v ( - Filtered Topology ) --------
v v ----------------------------- ^
v >>>>>>>>>>>> Topology Filter ^ /
v ...........................\............../...........
v \ / Underlay
---------- \ / (Physical)
| | \ / Network
| Network | ----------------------------------------------
|Controller| ( |PE|.....-.....|PE|...... |PE|.......|PE| )
| | ( -- |P| -- :-...:-- -..:-- )
---------- ( : -:.............|P|.........|P| )
v ( -......................:-:..- - )
>>>>>>> ( |P|.........................|P|......: )
Program the ( - - )
Network ----------------------------------------------
(NRP Policies and Paths)*
* : NRP Policy installation and path placement can be centralized
or distributed.
Saad, et al. Expires 26 December 2026 [Page 8]
Internet-Draft IP/MPLS Network Slicing June 2026
Figure 1: IETF network slice realization steps.
3.1. Network Topology Filters
The Physical Network may be filtered into a number of Filter
Topologies. Filter actions may include selection of specific nodes
and links according to their capabilities and are based on network-
wide policies. The resulting topologies can be used to host IETF
Network Slices and provide a useful way for the network operator to
know that all of the resources they are using to plan a network slice
meet specific SLOs. This step can be done offline during planning
activity, or could be performed dynamically as new demands arise.
Section 5.1.4 describes how topology filters can be associated with
the NRP instantiated by the NRP Policy.
3.2. IETF Network Slice Service Request
The customer requests an IETF Network Slice Service specifying the
CE-AC-PE points of attachment, the connectivity matrix, and the SLOs/
SLEs as described in [RFC9543]. These capabilities are always
provided based on a Service Level Agreement (SLA) between the network
slice customer and the provider.
This defines the traffic flows that need to be supported when the
slice is realized. Depending on the mechanism and encoding of the
Attachment Circuit (AC), the IETF Network Slice Service may also
include information that will allow the operator's controllers to
configure the PEs to determine what customer traffic is intended for
this IETF Network Slice.
IETF Network Slice Service Requests are likely to arrive at various
times in the life of the network, and may also be modified.
3.3. Slice-Flow Aggregation
A network may be called upon to support very many IETF Network
Slices, and this could present scaling challenges in the operation of
the network. In order to overcome this, the IETF Network Slice
streams may be aggregated into groups according to similar
characteristics.
A Slice-Flow Aggregate is a construct that comprises the traffic
flows of one or more IETF Network Slices. The mapping of IETF
Network Slices into a Slice-Flow Aggregate is a matter of local
operator policy and is a function executed by the Controller. The
Slice-Flow Aggregate may be preconfigured, created on demand, or
modified dynamically.
Saad, et al. Expires 26 December 2026 [Page 9]
Internet-Draft IP/MPLS Network Slicing June 2026
3.4. Path Placement over NRP Filtered Topology
Depending on the underlying network technology, the paths are
selected in the network in order to best deliver the SLOs for the
different services carried by the Slice-Flow Aggregate. The path
placement function (carried on ingress node or by a controller) is
performed on the Filtered Topology that is selected to support the
Slice-Flow Aggregate.
Note that this step may indicate the need to increase the capacity of
the underlying Filtered Topology or to create a new Filtered
Topology.
3.5. NRP Policy
An NRP policy is a policy construct that enables instantiation of
mechanisms in support of service specific control and data plane
behaviors on select topological elements associated with the NRP.
The NRP Policy is a construct that enables the instantiation of
control and data plane behaviors on select topological elements in
support of the IETF network slice service. The NRP Policy
encompasses policy actions (see Section 5.1) that manage the specific
resources in the network associated with the NRP.
3.6. NRP Policy Installation
A Controller function programs the physical network with the NRP
policies to define specific handling for traffic flows belonging to
the Slice-Flow Aggregate. These NRP policies may be consumed on
select topological elements in the network and as a result define how
routers handle traffic for the Slice-Flow Aggregate associated with
the NRP.
For example, the routers that instantiate the NRP Policy can
correlate markers that are present in packets that belong to the
Slice-Flow Aggregate and apply specific treatments to them.
The way in which the NRP Policy is installed in the routers and the
way that the traffic is marked is implementation specific. The NRP
Policy instantiation in the network is further described in
Section 5.
Saad, et al. Expires 26 December 2026 [Page 10]
Internet-Draft IP/MPLS Network Slicing June 2026
3.7. Path Instantiation
Depending on the underlying network technology, a Controller function
may install the forwarding state specific to the Slice-Flow Aggregate
so that traffic is routed along paths derived in the Path Placement
step described in Section 3.4. The way in which the paths are
instantiated is implementation specific.
3.8. Service Mapping
The edge points can be configured to support the network slice
service by mapping the customer traffic to Slice-Flow Aggregates,
possibly using information supplied when the IETF network slice
service was requested. The edge points may also be instructed to
mark the packets so that the network routers will know which policies
and routing instructions to apply. The steering of traffic onto
Slice-Flow Aggregate paths is further described in Section 6.
4. Network Resource Partition Modes
An NRP Policy can be used to dictate if the network resource
partitioning of the shared network resources among multiple Slice-
Flow Aggregates can be achieved:
a) in data plane only,
b) in control plane only, or
c) in both control and data planes.
4.1. Data plane Network Resource Partition Mode
The physical network resources can be partitioned on network devices
by applying a Per Hop forwarding Behavior (PHB) onto packets that
traverse the network devices.
When data plane NRP mode is applied, packets need to be forwarded on
the specific NRP that supports the Slice-Flow Aggregate to ensure the
proper forwarding treatment dictated in the NRP Policy is applied
(refer to Section 5.1 below). In this case, an NRP Selector must be
carried in each packet to identify the Slice-Flow Aggregate that it
belongs to.
The ingress node of an NRP domain adds an NRP Selector field (if not
already present) in each Slice-Flow Aggregate packet. In the data
plane NRP mode, the transit nodes within an NRP domain use the NRP
Selector to associate packets with a Slice-Flow Aggregate and to
determine the Network Resource Partition Per Hop Behavior (NRP-PHB)
Saad, et al. Expires 26 December 2026 [Page 11]
Internet-Draft IP/MPLS Network Slicing June 2026
that is applied to the packet (refer to Section 5.1.3 for further
details). The CS MAY be used to apply a Diffserv PHB on to the
packet to allow differentiation of traffic treatment within the same
Slice-Flow Aggregate.
When data plane only NRP mode is used, routers may rely on a network
state independent view of the topology to determine the best paths.
In this case, the best path selection dictates the forwarding path of
packets to the destination. The NRP Selector field carried in each
packet determines the specific NRP-PHB treatment along the selected
path.
The data plane NRP mode can provide two levels of isolation between
NRPs:
* Strict isolation: Each NRP is assigned dedicated hardware
resources (e.g., queues, schedulers, and policers) that are not
shared with other NRPs. This ensures that traffic of one NRP
cannot contend with or impact traffic of another NRP.
* Shared hardware isolation: Multiple NRPs may share the same
underlying hardware resources, but are differentiated by the NRP
Selector and the NRP-PHB applied to their traffic. In this case,
isolation is statistical and depends on the configured scheduling
and policing policies.
4.2. Control Plane Network Resource Partition Mode
Multiple NRPs can be realized over the same set of physical
resources. Each NRP is identified by an identifier (NRP-ID) that is
globally unique within the NRP domain. The NRP state reservations
for each NRP can be maintained on the network element or on a
controller.
The network reservation states for a specific partition can be
represented in a topology that contains all or a subset of the
physical network elements (nodes and links) and reflect the network
state reservations in that NRP. The logical network resources that
appear in the NRP topology can reflect a part, whole, or in-excess of
the physical network resource capacity (e.g., when oversubscription
is desirable).
For example, the physical link bandwidth can be divided into
fractions, each dedicated to an NRP that supports a Slice-Flow
Aggregate. The topology associated with the NRP supporting a Slice-
Flow Aggregate can be used by routing protocols, or by the ingress/
PCE when computing NRP state aware TE paths.
Saad, et al. Expires 26 December 2026 [Page 12]
Internet-Draft IP/MPLS Network Slicing June 2026
To perform NRP state aware Traffic Engineering (NRP-TE), the resource
reservation on each link needs to be NRP aware. The NRP reservations
state can be managed locally on the device or off device (e.g. on a
controller).
The same physical link may be a member of multiple slice policies
that instantiate different NRPs. The NRP reservable or utilized
bandwidth on such a link is updated (and may be advertised) whenever
new paths are placed in the network. The NRP reservation state, in
this case, is maintained on each device or off the device on a
resource reservation manager that holds reservation states for those
links in the network.
Multiple NRPs that support Slice-Flow Aggregates can form a group and
share the available network resources allocated to each. In this
case, a node can update the reservable bandwidth for each NRP to take
into consideration the available bandwidth from other NRPs in the
same group.
For illustration purposes, Figure 2 describes bandwidth partitioning
or sharing amongst a group of NRPs. In Figure 2a, the NRPs
identified by the following NRP-IDs: NRP1, NRP2, NRP3 and NRP4 are
not sharing any bandwidths between each other. In Figure 2b, the
NRPs: NRP1 and NRP2 can share the available bandwidth portion
allocated to each amongst them. Similarly, NRP3 and NRP4 can share
amongst themselves any available bandwidth allocated to them, but
they cannot share available bandwidth allocated to NRP1 or NRP2. In
both cases, the Max Reservable Bandwidth may exceed the actual
physical link resource capacity to allow for oversubscription.
Saad, et al. Expires 26 December 2026 [Page 13]
Internet-Draft IP/MPLS Network Slicing June 2026
I-----------------------------I I-----------------------------I
<--NRP1-> I I-----------------I I
I---------I I I <-NRP1-> I I
I I I I I-------I I I
I---------I I I I I I I
I I I I-------I I I
<-----NRP2------> I I I I
I-----------------I I I <-NRP2-> I I
I I I I I---------I I I
I-----------------I I I I I I I
I I I I---------I I I
<---NRP3----> I I I I
I-------------I I I NRP1 + NRP2 I I
I I I I-----------------I I
I-------------I I I I
I I I I
<---NRP4----> I I-----------------I I
I-------------I I I <-NRP3-> I I
I I I I I-------I I I
I-------------I I I I I I I
I I I I-------I I I
I NRP1+NRP2+NRP3+NRP4 I I I I
I I I <-NRP4-> I I
I-----------------------------I I I---------I I I
<--Max Reservable Bandwidth--> I I I I I
I I---------I I I
I I I
I NRP3 + NRP4 I I
I-----------------I I
I NRP1+NRP2+NRP3+NRP4 I
I I
I-----------------------------I
<--Max Reservable Bandwidth-->
(a) No bandwidth sharing (b) Sharing bandwidth between
between NRPs. NRPs of the same group.
Figure 2: Bandwidth isolation/sharing among NRPs.
Saad, et al. Expires 26 December 2026 [Page 14]
Internet-Draft IP/MPLS Network Slicing June 2026
The control plane NRP mode provides isolation at admission time by
ensuring that the total bandwidth reserved across NRPs does not
exceed the available physical link capacity (subject to any
configured oversubscription). However, since no per-packet
forwarding enforcement is applied in this mode, traffic from
different NRPs may contend for the same physical resources at
runtime, and isolation guarantees are soft. To compensate, the
control plane MAY monitor link utilization and detect congestion, and
react by reoptimizing the placement of affected traffic flows onto
less loaded paths within the NRP topology.
4.3. Data and Control Plane Network Resource Partition Mode
In order to support strict guarantees for Slice-Flow Aggregates, the
network resources can be partitioned in both the control plane and
data plane.
The control plane partitioning allows the creation of customized
topologies per NRP that each supports a Slice-Flow Aggregate. The
ingress routers or a Path Computation Engine (PCE) may use the
customized topologies and the NRP state to determine optimal path
placement for specific demand flows using NRP-TE.
The data plane partitioning provides isolation for Slice-Flow
Aggregate traffic, and protection when resource contention occurs due
to bursts of traffic from other Slice-Flow Aggregate traffic that
traverses the same shared network resource.
The combination of control and data plane partitioning provides the
strongest form of NRP isolation. The control plane ensures that
admitted traffic across NRPs does not exceed the available network
resources, while the data plane enforces per-packet forwarding
treatment at runtime, preventing traffic bursts from one NRP from
impacting the resources available to other NRPs.
5. Network Resource Partition Instantiation
A network slice can span multiple technologies and multiple
administrative domains. Depending on the network slice customer
requirements, a network slice can be differentiated from other
network slices in terms of data, control, and management planes.
The customer of a network slice service expresses their intent by
specifying requirements rather than mechanisms to realize the slice
as described in Section 3.2.
Saad, et al. Expires 26 December 2026 [Page 15]
Internet-Draft IP/MPLS Network Slicing June 2026
The network slice controller is fed with the network slice service
intent and realizes it with an appropriate Network Resource Partition
Policy (NRP Policy). Multiple IETF network slices are mapped to the
same Slice-Flow Aggregate as described in Section 3.3.
The network wide consistent NRP Policy definition is distributed to
the devices in the network as shown in Figure 1. The specification
of the network slice intent on the northbound interface of the
controller and the mechanism used to map the network slice to a
Slice-Flow Aggregate are outside the scope of this document and will
be addressed in separate documents.
5.1. NRP Policy Definition
The NRP Policy is a network-wide construct that is supplied to
network devices, and may include rules that control the following:
* Data plane specific policies: This includes the NRP Selector, any
firewall rules or flow-spec filters, and QoS profiles associated
with the NRP Policy and any classes within it.
* Control plane specific policies: This includes bandwidth
reservations, any network resource sharing amongst slice policies,
and reservation preference to prioritize reservations of a
specific NRP over others.
* Topology membership policies: This defines the topology filter
policies that dictate node/link/function membership to a specific
NRP.
There is a desire for flexibility in realizing network slices to
support the services across networks consisting of implementations
from multiple vendors. These networks may also be grouped into
disparate domains and deploy various path control technologies and
tunnel techniques to carry traffic across the network. It is
expected that a standardized data model for NRP Policy will
facilitate the instantiation and management of the NRP on the
topological elements selected by the NRP Policy topology filter.
It is also possible to distribute the NRP Policy to network devices
using several mechanisms, including protocols such as NETCONF or
RESTCONF, or exchanging it using a suitable routing protocol that
network devices participate in (such as IGP(s) or BGP). The
extensions to enable specific protocols to carry an NRP Policy
definition will be described in separate documents.
Saad, et al. Expires 26 December 2026 [Page 16]
Internet-Draft IP/MPLS Network Slicing June 2026
5.1.1. Network Resource Partition Selector
A router needs to be able to identify a packet belonging to a Slice-
Flow Aggregate before it can apply the associated data plane
forwarding treatment or NRP-PHB. One or more fields within the
packet are used as an NRP Selector to do this. There are several
possible approaches as follows.
The NRP Selector can be defined for and carried in different
forwarding data planes. For example:
* In MPLS networks, the NRP Selector may be encoded within the MPLS
label stack or post stack.
* In IPv6 networks, the NRP Selector may be carried within fields of
the IPv6 header (e.g., source or destination address), or within
an IPv6 extension header.
* In SRv6 networks, the NRP Selector may be encoded as a SRv6 SID or
carried within the Segment Routing Header (SRH) (e.g., as a TLV).
The specific encoding depends on the data plane technology deployed
in the NRP domain and is outside the scope of this document.
Overloaded forwarding identifier as NRP Selector:
It is possible to assign a different forwarding address or MPLS
forwarding label for each Slice-Flow Aggregate on a specific node
in the network. This allows Slice-Flow Aggregate packets destined
to a node to be distinguished by the destination address or the
MPLS forwarding label that is carried in the packet.
This approach requires maintaining per Slice-Flow Aggregate state
for each destination in the network in both the control and data
plane and on each router in the network. Hence this approach
scales as a multiple of the number of Slice-Flow Aggregates and
the number of adjacencies each node has which is a scalability
challenge in both the control and data planes.
Overloaded service identifier as NRP Selector:
VPN identifiers can be carried in the IP/MPLS forwarding plane
using a variety of techniques (including MPLS VPN service labels).
These identifiers can be overloaded to act as NRP Selectors to
allow VPN packets to be mapped to the Slice-Flow Aggregate. In
this case, a single VPN identifier acting as an NRP Selector needs
to be allocated by all Egress PEs of a VPN.
Saad, et al. Expires 26 December 2026 [Page 17]
Internet-Draft IP/MPLS Network Slicing June 2026
In other cases, a range of VPN identifiers can map to a single NRP
Selector to map traffic from multiple VPNs to a Slice-Flow
Aggregate.
SR Adj-SID: NRP Selector (VPN service label) on PE2: 1001
9012: P1-P2
9023: P2-PE2
/-----\ /-----\ /-----\ /-----\
| PE1 | ----- | P1 | ------ | P2 |------ | PE2 |
\-----/ \-----/ \-----/ \-----/
In
packet:
+------+ +------+ +------+ +------+
| IP | | 9012 | | 9023 | | 1001 |
+------+ +------+ +------+ +------+
| Pay- | | 9023 | | 1001 | | IP |
| Load | +------+ +------+ +------+
+------+ | 1001 | | IP | | Pay- |
+------+ +------+ | Load |
| IP | | Pay- | +------+
+------+ | Load |
| Pay- | +------+
| Load |
+------+
Figure 3: NRP Selector as VPN label at bottom of label stack.
Dedicated identifier as NRP Selector:
A dedicated identifier may be defined to act as the NRP Selector
ID to be carried in packets of Slice-Flow Aggregate, independent
of the forwarding address or MPLS forwarding label bound to the
destination and independent of any VPN identifiers. Routers
within the NRP domain can use the forwarding address or MPLS
forwarding label to determine the forwarding next-hops, and use
the NRP Selector in the packet to infer the specific forwarding
treatment that needs to be applied on the packet.
The NRP Selector, in this case, can be carried in one of multiple
fields in the packet, depending on the data plane in use. All
packets that belong to the same Slice-Flow Aggregate may carry the
same NRP Selector, but it is also possible to have multiple NRP
Selectors map to the same Slice-Flow Aggregate.
Fallback treatment for unclassified packets:
Saad, et al. Expires 26 December 2026 [Page 18]
Internet-Draft IP/MPLS Network Slicing June 2026
A packet carrying an NRP Selector may arrive at an NRP-capable
node on which no NRP matching that NRP Selector value is
instantiated. In such cases, the node is unable to associate the
packet with any NRP and therefore cannot apply the corresponding
NRP-PHB forwarding treatment.
The following fallback treatments MAY be applied in this case:
- Drop: The packet is discarded. This is the RECOMMENDED default
behavior, as it prevents packets with unrecognized NRP
Selectors from consuming resources of other NRPs on the node.
- Best-effort forwarding: The packet is forwarded using the
node's default best-effort forwarding treatment, without any
NRP-specific resource guarantees.
- Default NRP forwarding: The packet is mapped to a pre-
configured default NRP on the node, which provides a baseline
forwarding treatment for unmatched traffic.
The choice of fallback treatment SHOULD be configurable via local
policy. When a dedicated identifier is used as the NRP Selector,
a field within the NRP Selector ID MAY be used to signal the
desired fallback treatment, allowing the ingress node to influence
the behavior at downstream nodes.
5.1.2. Network Resource Partition Resource Reservation
Bandwidth and network resource allocation strategies for slice
policies are essential to achieve optimal placement of paths within
the network while still meeting the target SLOs.
Resource reservation allows for the management of available bandwidth
and the prioritization of existing allocations to enable preference-
based preemption when contention on a specific network resource
arises. Sharing of a network resource's available bandwidth amongst
a group of NRPs may also be desirable. For example, a Slice-Flow
Aggregate may not be using all of the NRP reservable bandwidth; this
allows other NRPs in the same group to use the available bandwidth
resources for other Slice-Flow Aggregates.
Congestion on shared network resources may result from sub-optimal
placement of paths in different slice policies. When this occurs,
preemption of some Slice-Flow Aggregate paths may be desirable to
alleviate congestion. A preference-based allocation scheme enables
prioritization of Slice-Flow Aggregate paths that can be preempted.
Saad, et al. Expires 26 December 2026 [Page 19]
Internet-Draft IP/MPLS Network Slicing June 2026
Since network characteristics and its state can change over time, the
NRP topology and its network state need to be propagated in the
network to enable ingress TE routers or Path Computation Engine
(PCEs) to perform accurate path placement based on the current state
of the NRP network resources.
5.1.3. Network Resource Partition Per Hop Behavior
The NRP Per Hop Behavior (NRP-PHB) is the externally observable
forwarding behavior applied to a specific packet belonging to a
Slice-Flow Aggregate. The goal of an NRP-PHB is to provide a
specified amount of network resources for traffic belonging to a
specific Slice-Flow Aggregate. A single NRP may also support
multiple forwarding treatments or services that can be carried over
the same logical network.
The Slice-Flow Aggregate traffic may be identified at NRP ingress
boundary nodes by carrying a NRP Selector to allow routers to apply a
specific forwarding treatment that guarantees the SLA(s).
To support multiple forwarding treatments over the same Slice-Flow
Aggregate, a Slice-Flow Aggregate packet may also carry a Diffserv CS
to identify the specific Diffserv forwarding treatment to be applied
on the traffic belonging to the same NRP.
At transit nodes, the CS field carried inside the packets are used to
determine the specific PHB that determines the forwarding and
scheduling treatment before packets are forwarded, and in some cases,
drop probability for each packet.
5.1.4. Network Resource Partition Topology
The relationship between the physical network, the Filtered Topology,
and the NRP topology can be described as follows:
1. The Physical Network comprises the underlying nodes and links
with their actual hardware resources (e.g., bandwidth, processing
capacity).
2. A Filtered Topology is derived from the Physical Network by
applying topology filtering policies that select specific nodes
and links based on their capabilities and attributes (as
described in Section 5.1). The same Filtered Topology may be
shared by multiple NRPs.
3. An NRP is instantiated on a Filtered Topology by associating NRP-
specific resource reservations (Section 5.1.2) and Per Hop
Behavior (Section 5.1.3) with the topological elements of the
Saad, et al. Expires 26 December 2026 [Page 20]
Internet-Draft IP/MPLS Network Slicing June 2026
Filtered Topology. The resulting topology, comprising the
filtered nodes and links together with their NRP-specific
resource attributes, is referred to as the NRP Topology.
Since the same Filtered Topology may underlie multiple NRPs, two NRPs
may share the same set of nodes and links while having different
resource reservations and forwarding treatments applied to them.
A key element of the NRP Policy is a customized topology that may
include the full or a subset of the physical network topology. The
NRP topology could also span multiple administrative domains and/or
multiple dataplane technologies.
An NRP topology can overlap or share a subset of links with another
NRP topology. A number of topology filtering policies can be defined
as part of the NRP Policy to limit the specific topology elements
that belong to the NRP. For example, a topology filtering policy can
leverage Resource Affinities as defined in [RFC2702] to include or
exclude certain links that the NRP is instantiated on in support of
the Slice-Flow Aggregate.
The NRP Policy may also include a reference to a predefined topology
(e.g., derived from a Flexible Algorithm Definition (FAD) as defined
in [I-D.ietf-lsr-flex-algo], or Multi-Topology ID as defined in
[RFC4915].
5.2. Network Resource Partition Boundary
A network slice originates at the edge nodes of a network slice
provider. Traffic that is steered over the corresponding NRP
supporting a Slice-Flow Aggregate may traverse NRP capable as well as
NRP incapable interior nodes.
The network slice may encompass one or more domains administered by a
provider. For example, an organization's intranet or an ISP. The
network provider is responsible for ensuring that adequate network
resources are provisioned and/or reserved to support the SLAs offered
by the network end-to-end.
5.2.1. Network Resource Partition Edge Nodes
NRP edge nodes sit at the boundary of a network slice provider
network and receive traffic that requires steering over network
resources specific to a NRP that supports a Slice-Flow Aggregate.
These edge nodes are responsible for identifying Slice-Flow Aggregate
specific traffic flows by possibly inspecting multiple fields from
inbound packets (e.g., implementations may inspect IP traffic's
network 5-tuple in the IP and transport protocol headers) to decide
Saad, et al. Expires 26 December 2026 [Page 21]
Internet-Draft IP/MPLS Network Slicing June 2026
on which NRP it can be steered.
Network slice ingress nodes may condition the inbound traffic at
network boundaries in accordance with the requirements or rules of
each service's SLAs. The requirements and rules for network slice
services are set using mechanisms which are outside the scope of this
document.
When data plane NRP mode is employed, the NRP ingress nodes are
responsible for setting a suitable NRP Selector on packets that
belong to the Slice-Flow Aggregate, and optionally the desired
Diffserv CS.
[RFC9543] describes different IETF Network Slice Service Demarcation
Point (SDP) locations that determine where the NRP edge function is
performed. The following describes how the solution described in
this document caters to each SDP location:
SDP within the CE: When the CE is operated by the IETF Network Slice
Service provider, the CE itself acts as the NRP ingress node. The
CE may classify inbound traffic, set the NRP Selector, and enforce
the NRP-PHB on the outgoing interface. In this case, slicing
resources may include buffers and queues on the CE outgoing
interfaces.
SDP at the CE/AC boundary: When the IETF Network Slice extends to
include the Attachment Circuit (AC), traffic conditioning and
policing are applied at the AC ends. The CE or PE may use traffic
tagging (e.g., Ethernet VLAN tags) to identify the IETF Network
Slice. The NRP Selector may be set by the CE or by the PE upon
receiving the tagged traffic from the AC.
SDP at the PE customer-facing port: The PE's customer-facing port
acts as the NRP ingress node. In this case, the port or VLAN tag
on the incoming traffic identifies the IETF Network Slice and the
corresponding Slice-Flow Aggregate. The PE sets the NRP Selector
on the inbound packets before forwarding them into the NRP domain.
SDP within the PE: The PE classifies inbound traffic from the AC by
inspecting multiple packet fields (e.g., the IP 5-tuple) to
identify the IETF Network Slice and the corresponding Slice-Flow
Aggregate. The PE then sets the NRP Selector on the classified
packets before forwarding them into the NRP domain.
Saad, et al. Expires 26 December 2026 [Page 22]
Internet-Draft IP/MPLS Network Slicing June 2026
5.2.2. Network Resource Partition Interior Nodes
An NRP interior node receives slice traffic and may be able to
identify the packets belonging to a specific Slice-Flow Aggregate by
inspecting the NRP Selector field carried inside each packet, or by
inspecting other fields within the packet that may identify the
traffic streams that belong to a specific Slice-Flow Aggregate. For
example, when data plane NRP mode is applied, interior nodes can use
the NRP Selector carried within the packet to apply the corresponding
NRP-PHB forwarding behavior.
5.2.3. Network Resource Partition Incapable Nodes
Packets that belong to a Slice-Flow Aggregate may need to traverse
nodes that are NRP incapable. In this case, several options are
possible to allow the slice traffic to continue to be forwarded over
such devices and be able to resume the NRP forwarding treatment once
the traffic reaches devices that are NRP-capable.
When data plane NRP mode is employed, packets carry a NRP Selector to
allow slice interior nodes to identify them. To support end-to-end
network slicing, the NRP Selector is maintained in the packets as
they traverse devices within the network -- including NRP capable and
incapable devices.
For example, when the NRP Selector is an MPLS label at the bottom of
the MPLS label stack, packets can traverse over devices that are NRP
incapable without any further considerations. On the other hand,
when the NRP Selector label is at the top of the MPLS label stack,
packets can be bypassed (or tunneled) over the NRP incapable devices
towards the next device that supports NRP as shown in Figure 4.
Saad, et al. Expires 26 December 2026 [Page 23]
Internet-Draft IP/MPLS Network Slicing June 2026
SR Node-SID: NRP Selector: 1001 @@@: NRP Policy
1601: P1 Label enforced
1602: P2 ...: NRP Policy
1603: P3 not enforced
1604: P4
1605: P5
@@@@@@@@@@@@@@ ........................
.
/-----\ /-----\ /-----\ .
| P1 | ----- | P2 | ----- | P3 | .
\-----/ \-----/ \-----/ .
| @@@@@@@@@@
|
/-----\ /-----\
| P4 | ------ | P5 |
\-----/ \-----/
+------+ +------+ +------+
| 1001 | | 1604 | | 1001 |
+------+ +------+ +------+
| 1605 | | 1001 | | IP |
+------+ +------+ +------+
| IP | | 1605 | | Pay- |
+------+ +------+ | Load |
| Pay- | | IP | +------+
| Load | +------+
+------+ | Pay- |
| Load |
+------+
Figure 4: Extending network slice over NRP incapable device(s).
An NRP-capable node needs to identify which of its downstream
neighbors are NRP incapable in order to apply the appropriate bypass
or tunnel treatment described above. The following mechanisms MAY be
used for this purpose:
Controller-based discovery: In controller-based deployments, NRP
node capabilities MAY be distributed to a controller using
mechanisms such as NETCONF [RFC6241], BGP-LS [RFC7752], or PCEP
[RFC5440]. The controller or PCE can then use this information
when computing paths to steer traffic around NRP incapable nodes
or to select appropriate bypass tunnels.
Static configuration: As a fallback, operators MAY statically
Saad, et al. Expires 26 December 2026 [Page 24]
Internet-Draft IP/MPLS Network Slicing June 2026
configure on each node which of its downstream neighbors are NRP
incapable. This approach is simple but does not adapt
automatically to topology or capability changes.
5.2.4. Combining Network Resource Partition Modes
It is possible to employ a combination of the NRP modes that were
discussed in Section 4 to realize a network slice. For example, data
and control plane NRP modes can be employed in parts of a network,
while control plane NRP mode can be employed in the other parts of
the network. The path selection, in such case, can take into account
the NRP available network resources. The NRP Selector carried within
packets allow transit nodes to enforce the corresponding NRP-PHB on
the parts of the network that apply the data plane NRP mode. The NRP
Selector can be maintained while traffic traverses nodes that do not
enforce data plane NRP mode, and so slice PHB enforcement can resume
once traffic traverses capable nodes.
5.2.5. Multi-domain Network Resource Partition Considerations
A network slice may span multiple NRP domains, each administered by
the same or different providers. In such deployments, the NRP
boundary nodes at the edges of each domain are responsible for
ensuring that the appropriate NRP treatment is applied within their
domain and that end-to-end SLAs are maintained across domain
boundaries.
When a network slice traverses multiple NRP domains, the NRP Selector
carried in packets may be handled at domain boundaries in one of the
following ways:
NRP Selector Stacking: The original NRP Selector (e.g., for NRP1) is
preserved in the packet end-to-end. When entering an intermediate
NRP domain (e.g., NRP2), the ingress boundary node of that domain
adds the intermediate domain's NRP Selector to the packet.
Interior nodes within the intermediate domain use the added NRP
Selector to apply the corresponding NRP-PHB treatment. Upon
exiting the intermediate domain, the egress boundary node removes
the intermediate domain's NRP Selector, re-exposing the original
NRP Selector. The original NRP treatment resumes in the next NRP
domain. The specific mechanism for adding and removing the NRP
Selector is data-plane dependent (e.g., pushing and popping a
label in MPLS, or encoding in a packet header field in other data
planes). This approach does not require NRP-ID coordination
across domain boundaries.
NRP Selector Remapping: At the boundary between two NRP domains, the
Saad, et al. Expires 26 December 2026 [Page 25]
Internet-Draft IP/MPLS Network Slicing June 2026
boundary node replaces the incoming NRP Selector with the
appropriate NRP Selector for the downstream domain. This requires
coordination of NRP-ID mappings at inter-domain boundaries, which
may be achieved via static configuration or via a controller
(e.g., using NETCONF [RFC6241], BGP-LS [RFC7752], or PCEP
[RFC5440]). The boundary node is also responsible for
conditioning traffic to conform to the downstream domain's SLA
allocation before forwarding.
In both approaches, each NRP domain is responsible for provisioning
sufficient resources within its domain to meet its portion of the
end-to-end SLA. The overall end-to-end SLA is satisfied when the
combined resource allocations across all NRP domains collectively
meet the SLOs and SLEs agreed upon in the IETF Network Slice Service
request.
Inter-domain path computation for network slices spanning multiple
NRP domains may be performed using a hierarchical PCE (H-PCE)
architecture, per-domain PCEs coordinating via PCEP [RFC5440], or a
centralized controller with visibility across all domains.
6. Mapping Traffic on Slice-Flow Aggregates
The usual techniques to steer traffic onto paths can be applicable
when steering traffic over paths established for a specific Slice-
Flow Aggregate.
For example, one or more (layer-2 or layer-3) VPN services can be
directly mapped to paths established for a Slice-Flow Aggregate. In
this case, the per Virtual Routing and Forwarding (VRF) instance
traffic that arrives on the Provider Edge (PE) router over external
interfaces can be directly mapped to a specific Slice-Flow Aggregate
path. External interfaces can be further partitioned (e.g., using
VLANs) to allow mapping one or more VLANs to specific Slice-Flow
Aggregate paths.
Another option is steer traffic to specific destinations directly
over multiple slice policies. This allows traffic arriving on any
external interface and targeted to such destinations to be directly
steered over the slice paths.
A third option that can also be used is to utilize a data plane
firewall filter or classifier to enable matching of several fields in
the incoming packets to decide whether the packet belongs to a
specific Slice-Flow Aggregate. This option allows for applying a
rich set of rules to identify specific packets to be mapped to a
Slice-Flow Aggregate. However, it requires data plane network
resources to be able to perform the additional checks in hardware.
Saad, et al. Expires 26 December 2026 [Page 26]
Internet-Draft IP/MPLS Network Slicing June 2026
6.1. Network Slice-Flow Aggregate Relationships
The following describes the generalization relationships between the
IETF network slice and different parts of the solution as described
in Figure 1.
o A customer may request one or more IETF Network Slices.
o Any given Attachment Circuit (AC) may support the traffic for one
or more IETF Network Slices. If there is more than one IETF Network
Slice using a single AC, the IETF Network Slice Service request must
include enough information to allow the edge nodes to demultiplex the
traffic for the different IETF Network Slices.
o By definition, multiple IETF Network Slices may be mapped to a
single Slice-Flow Aggregate. However, it is possible for an Slice-
Flow Aggregate to contain just a single IETF Network Slice.
o The physical network may be filtered to multiple Filter Topologies.
Each such Filtered Topology facilitates planning the placement of
paths for the Slice-Flow Aggregate by presenting only the subset of
links and nodes that meet specific criteria. Note, however, in
absence of any Filtered Topology, Slice-Flow Aggregate are free to
operate over the full physical network.
o It is anticipated that there may be very many IETF Network Slices
supported by a network operator over a single physical network. A
network may support a limited number of Slice-Flow Aggregates, with
each of the Slice-Flow Aggregates grouping any number of the IETF
Network Slices streams.
7. Path Selection and Instantiation
7.1. Applicability of Path Selection to Slice-Flow Aggregates
In State-dependent TE [I-D.ietf-teas-rfc3272bis], the path selection
adapts based on the current state of the network. The state of the
network can be based on parameters flooded by the routers as
described in [RFC2702]. The link state is advertised with current
reservations, thereby reflecting the available bandwidth on each
link. Such link reservations may be maintained centrally on a
network wide network resource manager, or distributed on devices (as
usually done with RSVP-TE). TE extensions exist today to allow IGPs
(e.g., [RFC3630] and [RFC5305]), and BGP-LS [RFC7752] to advertise
such link state reservations.
Saad, et al. Expires 26 December 2026 [Page 27]
Internet-Draft IP/MPLS Network Slicing June 2026
When the network resource reservations are maintained for NRPs, the
link state can carry per NRP state (e.g., reservable bandwidth).
This allows path computation to take into account the specific
network resources available for an NRP. In this case, we refer to
the process of path placement and path provisioning as NRP aware TE
(NRP-TE).
7.2. Applicability of Path Control Technologies to Slice-Flow
Aggregates
The NRP modes described in this document are agnostic to the
technology used to set up paths that carry Slice-Flow Aggregate
traffic. One or more paths connecting the endpoints of the mapped
IETF network slices may be selected to steer the corresponding
traffic streams over the resources allocated for the NRP that
supports a Slice-Flow Aggregate.
The feasible paths can be computed using the NRP topology and network
state subject the optimization metrics and constraints.
7.2.1. RSVP-TE Based Slice-Flow Aggregate Paths
RSVP-TE [RFC3209] can be used to signal LSPs over the computed
feasible paths in order to carry the Slice-Flow Aggregate traffic.
The specific extensions to the RSVP-TE protocol required to enable
signaling of NRP aware RSVP-TE LSPs are outside the scope of this
document.
7.2.2. SR Based Slice-Flow Aggregate Paths
Segment Routing (SR) [RFC8402] can be used to set up and steer
traffic over the computed Slice-Flow Aggregate feasible paths.
The SR architecture defines a number of building blocks that can be
leveraged to support the realization of NRPs that support Slice-Flow
Aggregates in an SR network.
Such building blocks include:
* SR Policy with or without Flexible Algorithm.
* Steering of services (e.g. VPN) traffic over SR paths
* SR Operation, Administration and Management (OAM) and Performance
Management (PM)
Saad, et al. Expires 26 December 2026 [Page 28]
Internet-Draft IP/MPLS Network Slicing June 2026
SR allows a headend node to steer packets onto specific SR paths
using a Segment Routing Policy (SR Policy). The SR policy supports
various optimization objectives and constraints and can be used to
steer Slice-Flow Aggregate traffic in the SR network.
The SR policy can be instantiated with or without the IGP Flexible
Algorithm (Flex-Algorithm) feature. It may be possible to dedicate a
single SR Flex-Algorithm to compute and instantiate SR paths for one
Slice-Flow Aggregate traffic. In this case, the SR Flex-Algorithm
computed paths and Flex-Algorithm SR SIDs are not shared by other
Slice-Flow Aggregates traffic. However, to allow for better scale,
it may be desirable for multiple Slice-Flow Aggregates traffic to
share the same SR Flex-Algorithm computed paths and SIDs.
8. Network Resource Partition Protocol Extensions
Some protocols may need to be extended to carry additional NRP state.
It is essential, however, that routing protocols, like IGPs or BGP,
remain uninvolved in these areas to ensure they are isolated and
maintain their scalability and stability. Furthermore, the
complexity of routing protocols path selection should not be impacted
by the increasing number of network slices and/or NRPs.
The instantiation of an NRP Policy may need to be automated.
Multiple options are possible to facilitate automation of
distribution of an NRP Policy to capable devices.
For example, a YANG data model for the NRP Policy may be supported on
network devices and controllers. A suitable transport (e.g., NETCONF
[RFC6241], RESTCONF [RFC8040], or gRPC) may be used to enable
configuration and retrieval of state information for slice policies
on network devices. The NRP Policy YANG data model is outside the
scope of this document.
9. Outstanding Issues
Note to RFC Editor: Please remove this section prior to publication.
This section records non-blocking issues that were raised during the
Working Group Adoption Poll for the document. The below list of
issues needs to be fully addressed before progressing the document to
publication in IESG.
Saad, et al. Expires 26 December 2026 [Page 29]
Internet-Draft IP/MPLS Network Slicing June 2026
1. [DONE] Add new Appendix section with examples for the NRP modes
described in Section 4. Addressed by adding Appendix A with
three sub-sections (A.1, A.2, A.3) providing concrete examples
for the data plane, control plane, and combined NRP modes
respectively, using a common 4-node topology.
2. [DONE] Elaborate on the Slice-Flow Aggregate packet treatment
when no rules to associate the packet to an NRP are defined in
the NRP Policy. Addressed in Section 5.1.1 by adding fallback
treatment options for packets carrying an NRP Selector that does
not match any NRP instantiated on the node.
3. [DONE] Clarify how the solution caters to the different IETF
Network Slice Service Demarcation Point locations described in
Section 4.2 of [RFC9543]. Addressed by adding explicit
descriptions of how the NRP ingress classification and NRP
Selector setting applies to each of the four SDP location
options: SDP within the CE, SDP at the CE/AC boundary, SDP at the
PE customer-facing port, and SDP within the PE.
4. [DONE] Clarify the relationship the underlay physical network,
the Filtered Topology and the NRP resources. Addressed in
Section 5.1.4 by adding a three-step description of the layering:
Physical Network -> Filtered Topology -> NRP Topology, and
clarifying that the same Filtered Topology may be shared by
multiple NRPs, each with its own resource reservations and
forwarding treatments.
5. [DONE] Expand on how isolation between NRPs can be realized
depending on the deployed NRP mode. Addressed in Section 4.1,
Section 4.2, and Section 4.3 by adding explicit isolation
characterization for each mode.
6. [DONE] Revise Section 5.2.3 to describe how nodes can discover
NRP incapable downstream neighbors. Addressed by adding three
discovery mechanisms: IGP-based capability advertisement (IS-IS/
OSPF extensions), controller-based discovery (NETCONF [RFC6241],
BGP-LS [RFC7752], or PCEP [RFC5440]), and static configuration as
a fallback. Also clarified that dynamic NRP state SHOULD NOT be
advertised via routing protocols to avoid convergence impact.
7. [DONE] Expand Section 11 on additional security threats
introduced with the solution. Added four new threat
descriptions: NRP Policy Manipulation, NRP State Disclosure,
Fallback NRP Abuse, and Inter-domain NRP Selector Spoofing, with
corresponding mitigation guidance for each.
Saad, et al. Expires 26 December 2026 [Page 30]
Internet-Draft IP/MPLS Network Slicing June 2026
8. [DONE] Expand Section 5.2 on NRP domain boundary and multi-domain
aspects. Addressed by adding Section 5.2.5 describing two
approaches for handling NRP Selectors at inter-domain boundaries:
NRP Selector Stacking (original NRP Selector preserved end-to-
end, intermediate domain adds/removes its own NRP Selector) and
NRP Selector Remapping (boundary node replaces NRP Selector with
downstream domain equivalent). Also covers end-to-end SLA
stitching and inter-domain path computation options.
10. IANA Considerations
This document has no IANA actions.
11. Security Considerations
The main goal of network slicing is to allow for varying treatment of
traffic from multiple different network slices that are utilizing a
common network infrastructure and to allow for different levels of
services to be provided for traffic traversing a given network
resource.
A variety of techniques may be used to achieve this, but the end
result will be that some packets may be mapped to specific resources
and may receive different (e.g., better) service treatment than
others. The mapping of network traffic to a specific NRP is
indicated primarily by the NRP Selector, and hence an adversary may
be able to utilize resources allocated to a specific NRP by injecting
packets carrying the same NRP Selector field in their packets.
Such theft-of-service may become a denial-of-service attack when the
modified or injected traffic depletes the resources available to
forward legitimate traffic belonging to a specific NRP.
The defense against this type of theft and denial-of-service attacks
consists of a combination of traffic conditioning at NRP domain
boundaries with security and integrity of the network infrastructure
within an NRP domain.
NRP Policy Manipulation: The NRP Policy controls resource
allocation, topology membership, and forwarding treatment for each
NRP. An adversary that gains access to the management plane
(e.g., via a compromised controller or network device) may modify
NRP Policies to reroute traffic, alter resource reservations, or
deprive legitimate NRPs of network resources. Securing the
management plane through authentication, authorization, and
integrity protection of NRP Policy distribution mechanisms (e.g.,
NETCONF/RESTCONF) is therefore essential.
Saad, et al. Expires 26 December 2026 [Page 31]
Internet-Draft IP/MPLS Network Slicing June 2026
NRP State Disclosure: Extensions that advertise NRP topology and
resource reservation states may expose sensitive information about
the network's internal resource allocations to any adversary
participating in the routing protocol. Operators SHOULD apply
appropriate route filtering and authentication mechanisms on
routing protocol sessions to limit the propagation of NRP state
information to trusted participants only.
Fallback NRP Abuse: When a fallback NRP or best-effort treatment is
configured for packets carrying unrecognized NRP Selectors, an
adversary may deliberately inject packets with invalid or
unrecognized NRP Selector values to consume the resources of the
fallback NRP. Operators SHOULD apply traffic conditioning and
rate limiting at NRP domain boundaries to mitigate this threat.
Inter-domain NRP Selector Spoofing: In deployments where NRP
Selectors traverse administrative domain boundaries, an adversary
at a peering point may inject or modify NRP Selector values to
gain access to resources of a specific NRP in the downstream
domain. Operators SHOULD validate and condition NRP Selector
values at inter-domain boundaries, and SHOULD NOT trust NRP
Selectors received from untrusted domains without appropriate
verification.
12. Acknowledgement
The authors would like to thank Krzysztof Szarkowicz, Swamy SRK,
Navaneetha Krishnan, Prabhu Raj Villadathu Karunakaran, and Mohamed
Boucadair for their review of this document and for providing
valuable feedback on it. The authors would also like to thank Adrian
Farrel for detailed discussions that resulted in Section 3.
13. Contributors
The following individuals contributed to this document:
Saad, et al. Expires 26 December 2026 [Page 32]
Internet-Draft IP/MPLS Network Slicing June 2026
Colby Barth
Juniper Networks
Email: cbarth@juniper.net
Srihari R. Sangli
Juniper Networks
Email: ssangli@juniper.net
Chandra Ramachandran
Juniper Networks
Email: csekar@juniper.net
Adrian Farrel
Old Dog Consulting
United Kingdom
Email: adrian@olddog.co.uk
Bin Wen
Comcast
Email: Bin_Wen@cable.comcast.com
Daniele Ceccarelli
Cisco Systems Inc.
Email: daniele.ietf@gmail.com
Xufeng Liu
IBM Corporation
Email: xufeng.liu.ietf@gmail.com
Luis M. Contreras
Telefonica
Email: luismiguel.contrerasmurillo@telefonica.com
Reza Rokui
Ciena
Email: rrokui@ciena.com
Ran Chen
ZTE Corporation
Email: chen.ran@zte.com.cn
Luay Jalil
Verizon
Email: luay.jalil@verizon.com
14. References
14.1. Normative References
Saad, et al. Expires 26 December 2026 [Page 33]
Internet-Draft IP/MPLS Network Slicing June 2026
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<https://www.rfc-editor.org/rfc/rfc3209>.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630,
DOI 10.17487/RFC3630, October 2003,
<https://www.rfc-editor.org/rfc/rfc3630>.
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic
Engineering", RFC 5305, DOI 10.17487/RFC5305, October
2008, <https://www.rfc-editor.org/rfc/rfc5305>.
[RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and
S. Ray, "North-Bound Distribution of Link-State and
Traffic Engineering (TE) Information Using BGP", RFC 7752,
DOI 10.17487/RFC7752, March 2016,
<https://www.rfc-editor.org/rfc/rfc7752>.
14.2. Informative References
[I-D.ietf-lsr-flex-algo]
Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and
A. Gulko, "IGP Flexible Algorithm", Work in Progress,
Internet-Draft, draft-ietf-lsr-flex-algo-26, 17 October
2022, <https://datatracker.ietf.org/doc/html/draft-ietf-
lsr-flex-algo-26>.
[I-D.ietf-teas-rfc3272bis]
Farrel, A., "Overview and Principles of Internet Traffic
Engineering", Work in Progress, Internet-Draft, draft-
ietf-teas-rfc3272bis-27, 12 August 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-teas-
rfc3272bis-27>.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, DOI 10.17487/RFC2475, December 1998,
<https://www.rfc-editor.org/rfc/rfc2475>.
[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J.
McManus, "Requirements for Traffic Engineering Over MPLS",
RFC 2702, DOI 10.17487/RFC2702, September 1999,
<https://www.rfc-editor.org/rfc/rfc2702>.
Saad, et al. Expires 26 December 2026 [Page 34]
Internet-Draft IP/MPLS Network Slicing June 2026
[RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P.
Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF",
RFC 4915, DOI 10.17487/RFC4915, June 2007,
<https://www.rfc-editor.org/rfc/rfc4915>.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440,
DOI 10.17487/RFC5440, March 2009,
<https://www.rfc-editor.org/rfc/rfc5440>.
[RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching
(MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic
Class" Field", RFC 5462, DOI 10.17487/RFC5462, February
2009, <https://www.rfc-editor.org/rfc/rfc5462>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/rfc/rfc6241>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/rfc/rfc8040>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/rfc/rfc8402>.
[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/rfc/rfc9543>.
Appendix A. NRP Mode Examples
This appendix provides examples to illustrate the NRP modes described
in Section 4. All examples use the following common network
topology:
/-----\ 10G /----\ 10G /----\ 10G /-----\
| PE1 |--------| P1 |--------| P2 |--------| PE2 |
\-----/ \----/ \----/ \-----/
| |
[CE1] [CE2]
Figure 5: Common topology for NRP mode examples.
Saad, et al. Expires 26 December 2026 [Page 35]
Internet-Draft IP/MPLS Network Slicing June 2026
Two NRPs are instantiated over this network:
* NRP1: supports low-latency Slice-Flow Aggregate (SFA1), with a
minimum bandwidth guarantee of 4 Gbps per link.
* NRP2: supports best-effort Slice-Flow Aggregate (SFA2), with up to
6 Gbps per link.
A.1. Data Plane NRP Mode Example
In this example, network resource partitioning is performed in the
data plane only. PE1 acts as the NRP ingress node and classifies
inbound CE1 traffic into two Slice-Flow Aggregates based on the IP
5-tuple, and pushes a dedicated NRP Selector label onto each packet:
* SFA1 (NRP1): NRP Selector label = 1001
* SFA2 (NRP2): NRP Selector label = 1002
Transit nodes P1 and P2 use the NRP Selector label to apply the
corresponding NRP-PHB. PE2 pops the NRP Selector label before
forwarding traffic to CE2.
NRP Selectors: NRP-PHB at P1 and P2:
1001: NRP1 (SFA1) +-----------------------------+
1002: NRP2 (SFA2) | NRP1: strict-priority queue |
| (4 Gbps guaranteed) |
| NRP2: weighted fair queue |
| (up to 6 Gbps) |
+-----------------------------+
/-----\ 10G /----\ 10G /----\ 10G /-----\
| PE1 |------| P1 |------| P2 |------| PE2 |
\-----/ @@@@ \----/ @@@@ \----/ @@@@ \-----/
| |
[CE1] @@@@: NRP-PHB enforced [CE2]
The packet label stack at each node for an SFA1 (NRP1) packet:
At PE1 (ingress): At P1 and P2: At PE2 (egress):
+-----------+ +--------+ +-----------+
| IP Header | | 1001 | | IP Header |
+-----------+ +--------+ +-----------+
| Payload | | IP Hdr | | Payload |
+-----------+ +--------+ +-----------+
| Payload|
+--------+
Saad, et al. Expires 26 December 2026 [Page 36]
Internet-Draft IP/MPLS Network Slicing June 2026
Since data plane only NRP mode is used, P1 and P2 do not maintain
per-NRP routing state. The forwarding path is determined by standard
best-path selection; the NRP Selector solely determines the NRP-PHB
applied at each hop.
A.2. Control Plane NRP Mode Example
In this example, network resource partitioning is performed in the
control plane only. No NRP Selector is carried in packets. Instead,
per-NRP bandwidth is reserved on each link, and NRP-aware TE paths
are computed using these reservations.
The 10 Gbps physical link bandwidth is divided between the two NRPs:
* NRP1: 4 Gbps reserved bandwidth per link
* NRP2: 6 Gbps reserved bandwidth per link
The per-NRP reservations are maintained on each network element (or
on a controller) and may be advertised via a routing protocol for
NRP-state-aware path computation.
/-----\ 10G /----\ 10G /----\ 10G /-----\
| PE1 |------| P1 |------| P2 |------| PE2 |
\-----/ \----/ \----/ \-----/
Per-link NRP reservations:
NRP1: 4 Gbps
NRP2: 6 Gbps
Total: 10 Gbps (= physical capacity)
The ingress node PE1 (or a PCE) uses the NRP-specific topology and
available bandwidth to compute TE paths for each SFA:
* SFA1 path: PE1->P1->P2->PE2 (using NRP1's 4 Gbps pool)
* SFA2 path: PE1->P1->P2->PE2 (using NRP2's 6 Gbps pool)
Since no NRP Selector is carried in packets, transit nodes P1 and P2
apply no per-packet NRP-specific forwarding treatment. Isolation
between NRP1 and NRP2 is enforced at admission time only; traffic
from both NRPs shares the same physical queues at runtime, and
isolation guarantees are soft.
Saad, et al. Expires 26 December 2026 [Page 37]
Internet-Draft IP/MPLS Network Slicing June 2026
A.3. Data and Control Plane NRP Mode Example
In this example, network resource partitioning is performed in both
the control plane and the data plane, combining the mechanisms of
Appendix A.1 and Appendix A.2.
As in A.2, per-NRP bandwidth is reserved per link (NRP1: 4 Gbps,
NRP2: 6 Gbps), and NRP-aware TE paths are computed for each SFA.
Additionally, as in A.1, PE1 pushes an NRP Selector label onto each
packet, and P1/P2 apply dedicated per-NRP queues based on the NRP
Selector.
/-----\ 10G /----\ 10G /----\ 10G /-----\
| PE1 |------| P1 |------| P2 |------| PE2 |
\-----/ @@@@ \----/ @@@@ \----/ @@@@ \-----/
| |
[CE1] @@@@: NRP-PHB enforced [CE2]
Per-link NRP reservations (control plane):
NRP1: 4 Gbps, NRP2: 6 Gbps
NRP-PHB at P1 and P2 (data plane):
NRP1 (label 1001): strict-priority queue (4 Gbps)
NRP2 (label 1002): weighted fair queue (6 Gbps)
The combined mode provides the strongest isolation:
* The control plane ensures the total admitted traffic across NRP1
and NRP2 does not exceed the physical link capacity.
* The data plane enforces per-packet forwarding treatment at
runtime, preventing traffic bursts from NRP2 from consuming
resources reserved for NRP1.
Authors' Addresses
Tarek Saad
Cisco Systems Inc.
Email: tsaad.net@gmail.com
Vishnu Pavan Beeram
Juniper Networks
Email: vbeeram@juniper.net
Jie Dong
Huawei Technologies
Saad, et al. Expires 26 December 2026 [Page 38]
Internet-Draft IP/MPLS Network Slicing June 2026
Email: jie.dong@huawei.com
Joel Halpern
Ericsson
Email: joel.halpern@ericsson.com
Shaofu Peng
ZTE Corporation
Email: peng.shaofu@zte.com.cn
Saad, et al. Expires 26 December 2026 [Page 39]