| Internet-Draft | Generalized IETF Network Slicing | July 2022 |
| Li & Dong | Expires 11 January 2023 | [Page] |
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.¶
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 11 January 2023.¶
Copyright (c) 2022 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.¶
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 compute and storage availability. [I-D.ietf-teas-ietf-network-slices] introduce the concept and the characteristics of IETF network slice, and a general framework for IETF network slice management and operation. [I-D.ietf-teas-enhanced-vpn] describes a layered architecture and the candidate technologies of enhanced VPN, which could be used to deliver network slice services.¶
For the realization of IETF network slices, one or more network resource partitions (NRPs) need 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. An NRP identifier could be encapsulated in the IETF network slice service 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 networks, there are emerging requirements about the capability and functionality of IETF network slices. To meet those requirements, it is expected that the concept of IETF network slice and NRP needs be generalized.¶
This document describes the considerations about possible generalization of IETF network slice and NRP.¶
NRP: Network Resource Partition. It is defined in [I-D.ietf-teas-ietf-network-slices].¶
VTN: Virtual Transport Network. It is defined in [I-D.ietf-teas-enhanced-vpn].¶
VxLAN: Virtual eXtensible Local Area Network. It is defined in [RFC7348].¶
An NRP is defined as a collection of network resources allocated in the underlay network. In order to specify the set of resources of an NRP, an NRP need to be scoped with a network topology, which can be either the whole underlay topology or a sub-topology of the underlay network. Thus it is considered that topology is also one of the basic attributes of NRP.¶
IETF network slice service packets which are mapped to an NRP needs to carry some NRP specific identifiers, which could be used by network nodes to determine the topology and the network resources of the NRP so as to perform NRP specific packet processing and forwarding. The identifiers for the topology and the resource of the NRP could be either separated or consolidated. [I-D.ietf-spring-resource-aware-segments] introduces resource-aware segments which can be considered as both the topology and resource identifier for packets sending towards a specific network segment. [I-D.ietf-6man-enhanced-vpn-vtn-id] proposes a mechanism to carry the VTN resource ID (which is equivalent to NRP ID in the network slicing context) in IPv6 HBH header, and it relies on the destination address in the IPv6 header to determine the topology which the packet belongs to.¶
[I-D.li-6man-topology-id] proposes to carry a topology identifier in the IPv6 extensions header, which can be used to identify the Multi-Topology in [RFC4915] [RFC5120] and Flex-Algorithm in [I-D.ietf-lsr-flex-algo], so that the same forwarding address (e.g. the same SRv6 Locator or the same MPLS forwarding label) could be used for packets in different topologies. Following this approach, the NRP ID in the data plane may be used not only to identify the set of network resources of the NRP, but also to identify the topology of the NRP.¶
An NRP is allocated with a set of forwarding plane network resources, such as the buffer, queuing and scheduling resources, which help ensure the performance of services mapped to the NRP are not impacted by other traffic in the network. As described in [RFC8655], there are services which require low latency or bounded latency. In order to meet the requirement of such services, the scope of NRP resources may need to be extended to also cover other types of resources which are needed for latency guarantee. As described in [I-D.ietf-spring-resource-aware-segments], the resource-aware SR segments can be associated with bandwidth and buffer resources, but also other type of resources. Then an NRP which is associated with a group of resource-aware segments is also associated with the various types resources which are represented by the resource-aware segments. The same methodology also applies to an NRP which is identified by an NRP ID, in which case the NRP ID could be used to identify various types of resources. Moreover, in some networks, the network devices may be virtualized, then the resources allocated to an NRP need to include the CPU resources, the storage resources and the virtualized computing resources (such as the virtual machines and containers) which are used for the software-based forwarding with guaranteed SLA.¶
In addition, the NRP resources may not be limited to the resources required for SLA guarantee, but could also be the resources used to execute some network functions, such as the resources which are used to provide the security functions for the NRP. This would extend the functionality of network slices from connectivity and SLA assurance to various types of network functions.¶
For a point-to-point virtual leased line service, usually a point-to-point resource reserved TE path needs to be established. With the introduction of IETF network slices, such virtual leased line service could be considered as a network slice service and could be delivered by mapping a point-to-point connectivity construct to an NRP. It is possible that each leased line service is mapped to an individual NRP, in this case the NRP would be equivalent to an point-to-point resource reserved TE path. While for better scalability, it is more practical that multiple leased line services are mapped to a shared NRP, then it is important that this NRP can meet the requirement of all the leased line services mapped to it. This depends on how the network resources are planned and allocated to this NRP.¶
Similarly, for network scenarios where different types of connectivity constructs are mapped to the same NRP, the resource planning and allocation of the NRP would also be a non-trivial problem.¶
The initial application of IETF network slice and NRP is to provide transport network slices for 5G end-to-end network slices. The application of IETF network slice is extended to operator's metro networks and backbone networks, and it can be used not only for the mobile services, but also for the fixed broadband services, the industrial verticals and the enterprise services. Due to the wide deployment of IP technologies, IETF network slice will not only be used in operators' IP networks, but will also be introduced to the campus networks and the data center networks. The various types of services in the campus networks and the data center networks will bring diverse requirements to the network. In addition, with the trend of migrating services to the cloud, SDWAN has become a popular approach for providing the connection between the enterprise sites with the cloud. For some of the cloud services, there are also requirements to provide guaranteed performance and security assurance.¶
In these application scenarios beyond the operators' IP networks, overlay technologies such as VxLAN has been used to provide service and tenant separation, while there are also requirement to provide resource partitioning to meet the service performance requirement. The support of IETF network slices and NRP with these IP tunnel and overlay technologies need to be considered.¶
This document makes no request of IANA.¶
TBD¶