Skip to main content

Considerations about Generalized IETF Network Slicing

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Expired & archived
Authors Zhenbin Li , Jie Dong
Last updated 2023-01-11 (Latest revision 2022-07-10)
RFC stream (None)
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state Expired
Telechat date (None)
Responsible AD (None)
Send notices to (None)

This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:


IETF network slice has been introduced to meet specific service requirements, such as the connectivity requirements and the associated network capabilities such as bandwidth, latency, jitter and network functions with the resource behaviors such as computing and storage availability. For the realization of IETF network slices, one or more network resource partitions (NRPs) can be created in the network. Each NRP is a collection of network resources (buffer, queuing, scheduling, etc.) allocated in the underlay network. The connectivity constructs from one or more IETF network slices can be mapped to an NRP. NRP specific identifiers could be carried in the IETF network slice packets, which could be used to determine the set of network resources to be used for the processing and forwarding of the packets in the corresponding NRP. With the development of IETF network slicing technologies and the deployment of IETF network slices in different types of networks, there are emerging requirements about the new capability and functionality of IETF network slices. To meet those requirements, it is expected that the concept IETF network slice and NRP needs be generalized. This document describes the considerations about possible generalization of IETF network slice and NRP.


Zhenbin Li
Jie Dong

(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)