| Internet-Draft | Hierarchical IETF Network Slices | March 2022 |
| Dong & Li | Expires 8 September 2022 | [Page] |
- Workgroup:
- TEAS Working Group
- Internet-Draft:
- draft-dong-teas-hierarchical-ietf-network-slice-01
- Published:
- Intended Status:
- Informational
- Expires:
Considerations about Hierarchical IETF Network Slices
Abstract
Network slicing is targeted at existing or emerging customers or services which may request for network connectivity services with a specific set of Service Level Objectives (SLOs) and Service Level Expectations (SLEs). In some network scenarios, there can be requirements for the deployment of hierarchical network slices.The general framework of IETF network slice supports hierarchical network slicing, while the technologies for realizing hierarchical IETF network slice need to be considered.¶
This document describes the typical scenarios of hierarchical IETF network slices, and provides the considerations and requirements on the technologies in different network planes to realize hierarchical IETF network slices.¶
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 8 September 2022.¶
Copyright Notice
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.¶
1. Introduction
Network slicing is targeted at existing or emerging customers or services which may request for network connectivity services with a specific set of Service Level Objectives (SLOs) and Service Level Expectations (SLEs). The concept and general framework of IETF network slice are described in [I-D.ietf-teas-ietf-network-slices]. [I-D.ietf-teas-enhanced-vpn] describes the framework and technologies which can be used for IETF network slice realization by utilizing Virtual Private Network (VPN) and Traffic Engineering (TE) mechanisms with enhancements that specific services require over traditional VPNs.¶
[I-D.ietf-teas-ietf-network-slices] mentions that IETF Network Slices may be combined hierarchically, which means that a network slice may itself be further sliced. The technologies for realizing hierarchical IETF network slice need to be considered.¶
This document describes the typical scenarios in which the deployment of hierarchical IETF network slices may be needed. This document also provides the considerations and requirements on the technologies in different network planes to realize hierarchical IETF network slices.¶
2. Scenarios of Hierarchical IETF Network Slices
In this section, several possible network scenarios of hierarchical IETF network slicing are introduced.¶
2.1. Per-Customer Network Slices in an Industrial Network Slice
One of the typical network slice deployment is in the multi-industrial network case, in which a physical network is used to deliver services of multiple vertical industries. Separate IETF network slices are provided for different industries, such as health-care, education, manufacturing, governmental affairs, etc. Then within the network slice of a specific industry, there may be need to create separate network slices for some or all of the customers within this industry.¶
For example, within the education network slice, some of the universities may require for a separate network slice to connect with a set of the branch campuses. Another examples is within the health-care network slice, some of the hospitals may require for a separate network slice for the connectivity and services between a set of the branch hospitals.¶
---------------------------------/
/ Industry Slice 1 /
/ ----------------------- /
/ / Customer Slice 1 / /
/ -----------------------/ /
/ ----------------------- /
/ / Customer Slice 2 / /
/ -----------------------/ /
/ ... /
---------------------------------/
...
---------------------------------/
/ Industry Slice 2 /
/ ----------------------- /
/ / Customer Slice 1 / /
/ -----------------------/ /
/ ----------------------- /
/ / Customer Slice 2 / /
/ -----------------------/ /
/ ... /
---------------------------------/
Figure 1. Hierarchical Network Slices: Scenario 1
¶
2.2. Per-application Network Slices in a Customer Network Slice
Another network slice deployment case is to provide dedicated IETF network slices for some important customers as the first-level network slices. While the customers may require to further split their network slices into different sub-network slices for different applications.¶
For example, a network slice for a hospital may be further divided to carry different type of medical services, such as remote patient monitoring, remote ultrasound diagnose, medical image transmission etc.¶
---------------------------------/
/ Customer Slice 1 /
/ ----------------------- /
/ / APP Slice 1 / /
/ -----------------------/ /
/ ----------------------- /
/ / APP Slice 2 / /
/ -----------------------/ /
/ ... /
---------------------------------/
...
---------------------------------/
/ Customer Slice 2 /
/ ----------------------- /
/ / APP Slice 1 / /
/ -----------------------/ /
/ ----------------------- /
/ / APP Slice 2 / /
/ -----------------------/ /
/ ... /
---------------------------------/
Figure 2. Hierarchical Network Slices: Scenario 2
¶
2.3. Network Slice Services in a Wholesale Network Slice
IETF network slice can also be delivered as a wholesale service to other network operators. In this case a network operator can be the customer of a network slice, and it may also need to deliver IETF network slice services to its customers. This is similar to the Carrier's Carrier VPN service mode, while some additional requirements on the SLOs and SLEs may be required by the second-level network slice customer.¶
---------------------------------/
/ Wholesale Slice 1 /
/ ----------------------- /
/ / Customer Slice 1 / /
/ -----------------------/ /
/ ----------------------- /
/ / Customer Slice 2 / /
/ -----------------------/ /
/ ... /
---------------------------------/
...
---------------------------------/
/ Wholesale Slice 2 /
/ ----------------------- /
/ / Customer Slice 1 / /
/ -----------------------/ /
/ ----------------------- /
/ / Customer Slice 2 / /
/ -----------------------/ /
/ ... /
---------------------------------/
Figure 3. Hierarchical Network Slices: Scenario 3¶
3. Considerations about Hierarchical Network Slice Realization
To support the realization of hierarchical network slices, there will be specific requirements on the technologies used in each network plane. In this section, the requirements of hierarchical network slicing on the forwarding plane network resource partitioning, the data plane encapsulations, the control plane protocols and the management plane are analyzed.¶
3.1. Forwarding Plane Network Resource Partitioning
For the realization of IETF network slices, the network resources in the underlying forwarding plane needs to be partitioned into different network resource partitions (NRPs), each NRP is used as the underlay network construct to support one or a group of IETF network slice services. In order to support hierarchical network slices, the forwarding plane network resources needs to be able to be partitioned in a hierarchical manner. Taking a two-level hierarchical network slice as an example, the bandwidth resource of a physical interface needs to be partitioned in two levels. There can be different options in modeling the interface resources of network resource partition.¶
The first option is to treat the network resources in the first-level NRPs as a set of layer-3 sub-interfaces, each with dedicated link bandwidth, and the second-level NRPs are represented as virtual data channels under the layer-3 sub-interfaces, as shown in the figure below:¶
+----------------------+
| +----------------+ |
| | +------------+ | |
| | |Data Channel| | |
| | +------------+ | |
| | ... | |
| | +------------+ | |
| | |Data Channel| | |
| | +------------+ | |
| +----------------+ |
| layer-3 subinterface |
| |
| . . . |
| +----------------+ |
| | +------------+ | |
| | |Data Channel| | |
| | +------------+ | |
| | ... | |
| | +------------+ | |
| | |Data Channel| | |
| | +------------+ | |
| +----------------+ |
| layer-3 subinterface |
+----------------------+
Physical Interface
Figure 4. Modeling of Network Resource Partition on Interface: Option 1
¶
The second option is to treat the first-level NRPs as layer-2 sub-interface of the layer-3 interface, and the second-level NRPs are represented as virtual data channels under the layer-2 sub-interface, as shown in the figure below:¶
+----------------------+ | +----------------+ | | | +------------+ | | | | |Data Channel| | | | | +------------+ | | | | ... | | | | +------------+ | | | | |Data Channel| | | | | +------------+ | | | +----------------+ | | layer-2 subinterface | | | | . . . | | +----------------+ | | | +------------+ | | | | |Data Channel| | | | | +------------+ | | | | ... | | | | +------------+ | | | | |Data Channel| | | | | +------------+ | | | +----------------+ | | layer-2 subinterface | +----------------------+ Layer-3 Physical Interface Figure 5. Modeling of Network Resource Partition on Interface, Option 2¶
The options of the network resource partition modeling may have different impact to the control plane in terms of the number of control protocol sessions to be maintained, and the amount and types of information to be distributed in the control plane. Depends on the network deployment requirements, different resource partition modeling options may be used.¶
3.2. Data Plane Identifiers
Traffic of IETF network slices can be steered into the corresponding underlay network construct based on one or multiple fields in the data packet, so that the corresponding NRPs are used for processing and forwarding the packet. On the edge nodes of an IETF network slice, traffic flows can be classified and mapped to IETF network slices using flexible matching rules based on operators' local policy. While on the intermediate network nodes, a dedicated data plane NRP Identifier [I-D.dong-teas-nrp-scalability] can facilitate the identification of the NRP and the set of network resources allocated on the network nodes for packet processing.¶
For hierarchical IETF network slices, such data plane identifiers may need to be able to identify both the first-level NRP and the second-level NRP. There are several options in the design of the data plane NRP identifier for hierarchical network slices.¶
The first option is to use a unified data plane identifier for both the first-level NRP and the second-level NRP. In this case, the first-level NRPs and the second-level NRPs are identified using distinct identifier values.¶
+-----------------------------------------+ | Unified NRP ID for different levels | +-----------------------------------------+ Figure 6. Unified NRP ID¶
The second option is to use a hierarchical identifiers for the first-level NRP and the second-level NRP. In this case, the first part of the identifier is used to identify the first-level NRP, and the second part of the identifier is used to identify the second-level NRP. Depends on the data plane technologies used, the hierarchical NRP may be encapsulated in a continuous field in the packet, or may be positioned in separate fields.¶
+--------------------+--------------------+ | Level-1 NRP ID | Level-2 NRP ID | +--------------------+--------------------+ Figure 7. Hierarchical NRP IDs¶
3.3. Control Plane
The control plane may be used for the distribution of the attributes and states of the hierarchical NRPs and the associated data plane identifiers among network nodes in the NRP and also to the network controller. With different NRP modeling, the information may be advertised as either layer-3 or layer-2 network information, which may have different scalability implications to the control plane. And as the number of hierarchical network slices increases, some control plane optimization mechanisms may be needed to adopt to the amount of information advertised.¶
3.4. Management Plane
For the management hierarchical network slices, the management system of network operator needs to provide life-cycle management to both the first-level network slices and the second-level network slices. It should allow to manage the first-level and second-level network slices separately, while the relationship between the first-level and second-level network slices also need to be maintained in the management system. The management system may need to support additional functions and procedures for the management of hierarchical network slices. Further analysis about the requirement on the management plane is for further study.¶
5. IANA Considerations
This document makes no request of IANA.¶
6. Contributors
Zhibo Hu Email: huzhibo@huawei.com¶
7. Acknowledgments
The authors would like to thank Yawei Zhang for the review and discussion of this document.¶
8. References
8.1. Normative References
- [I-D.ietf-teas-ietf-network-slices]
- Farrel, A., Drake, J., Rokui, R., Homma, S., Makhijani, K., Contreras, L. M., and J. Tantsura, "Framework for IETF Network Slices", Work in Progress, Internet-Draft, draft-ietf-teas-ietf-network-slices-08, , <https://www.ietf.org/archive/id/draft-ietf-teas-ietf-network-slices-08.txt>.
8.2. Informative References
- [I-D.dong-teas-nrp-scalability]
- Dong, J., Li, Z., Gong, L., Yang, G., Guichard, J. N., Mishra, G., Qin, F., Saad, T., and V. P. Beeram, "Scalability Considerations for Network Resource Partition", Work in Progress, Internet-Draft, draft-dong-teas-nrp-scalability-01, , <https://www.ietf.org/archive/id/draft-dong-teas-nrp-scalability-01.txt>.
- [I-D.ietf-teas-enhanced-vpn]
- Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A Framework for Enhanced Virtual Private Network (VPN+) Services", Work in Progress, Internet-Draft, draft-ietf-teas-enhanced-vpn-09, , <https://www.ietf.org/archive/id/draft-ietf-teas-enhanced-vpn-09.txt>.