Realization of Composite IETF Network Slices
draft-li-teas-composite-network-slices-00
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 "Active".
|
|
|---|---|---|---|
| Authors | Zhenbin Li , Jie Dong , Ran Pang , Yongqing Zhu , Luis M. Contreras | ||
| Last updated | 2023-03-13 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-li-teas-composite-network-slices-00
Network Working Group Z. Li
Internet-Draft J. Dong
Intended status: Informational Huawei Technologies
Expires: 14 September 2023 R. Pang
China Unicom
Y. Zhu
China Telecom
L. Contreras
Telefonica
13 March 2023
Realization of Composite IETF Network Slices
draft-li-teas-composite-network-slices-00
Abstract
Network slicing can be used to meet the connectivity and performance
requirement of different applications or customers in a shared
network. An IETF network slice may be used for 5G or other network
scenarios. In the context of 5G, a 5G end-to-end network slice
consists of three different types of network technology segments:
Radio Access Network (RAN), Transport Network (TN) and Core Network
(CN). The transport segments of the 5G end-to-end network slice can
be provided using IETF network slices. In some scenarios, IETF
network slices may span multiple network domains, and IETF network
slices may be composed hierarchically, which means a network slice
may itself be further sliced.
This document first describes the possible use cases of composite
IETF network slices, then it provides considerations about the
realization of composite IETF network slices. For the interaction
between IETF network slices with 5G network slices, the identifiers
of the 5G network slice may be introduced into IETF networks. For
the multi-domain IETF network slices, the Inter-Domain Network
Resource Partition Identifier (Inter-domain NRP ID) is defined. For
the hierarchical IETF network slices, the structure of the NRP ID is
discussed. These network slice-related identifiers may be used in
the data plane, control plane and management plane of the network for
the instantiation and management of composite IETF network slices.
This document also describes the management considerations of
composite network slices.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Li, et al. Expires 14 September 2023 [Page 1]
Internet-Draft Composite IETF Network Slices March 2023
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 14 September 2023.
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Composite Network Slice Use Cases . . . . . . . . . . . . . . 4
2.1. Multi-domain IETF Network Slices . . . . . . . . . . . . 4
2.2. Hierarchical IETF Network Slices . . . . . . . . . . . . 5
2.2.1. Per-Customer Network Slices in an Industrial Slice . 5
2.2.2. Per-Application Network Slices in a Customer Slice . 6
2.2.3. Network Slice Services in a Wholesale Network
Slice . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Realization of Composite Network Slices . . . . . . . . . . . 8
3.1. Network Slices Related Identifiers . . . . . . . . . . . 8
3.2. Data Plane . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.1. Forwarding Resource Partitioning . . . . . . . . . . 10
3.2.2. Data Plane Identifiers . . . . . . . . . . . . . . . 10
3.3. Control Plane . . . . . . . . . . . . . . . . . . . . . . 11
4. Management Considerations . . . . . . . . . . . . . . . . . . 12
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
Li, et al. Expires 14 September 2023 [Page 2]
Internet-Draft Composite IETF Network Slices March 2023
9.1. Normative References . . . . . . . . . . . . . . . . . . 13
9.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction
Network slicing can be used to meet the connectivity and performance
requirement of different applications or customers in a shared
network. [I-D.ietf-teas-ietf-network-slices] defines the
terminologies and the characteristics of IETF network slices. It
also discusses the general framework, the components and interfaces
for requesting and operating IETF network slices. A Network Resource
Partition (NRP) is a subset of network resources in the underlay
network and the associated policies, which can be used to deliver the
IETF network slice services with the required Service Level
Objectives (SLOs) and Service Level Expectations (SLEs).
[I-D.ietf-teas-enhanced-vpn] describes the framework and the
candidate technologies for providing enhanced VPN (VPN+) services.
VPN+ leverages the VPN and Traffic Engineering (TE) technologies and
adds characteristics that specific services require beyond those
provided by conventional VPNs. VPN+ could be used to underpin
network slicing, and could also be of use in general scenarios
providing enhanced connectivity services between customer sites. For
delivering VPN+ service, the concept of Virtual Transport Network
(VTN) is introduced, which is a virtual underlay network consisting
of a set of dedicated or shared network resources allocated from the
physical underlay network, and is associated with a customized
network topology. VPN+ services can be delivered by mapping one or a
group of overlay VPNs to the appropriate VTNs as the underlay, so as
to provide the network characteristics required by the customers. In
the context of IETF network slicing, NRP can be seen as an
instantiation of VTN.
An IETF network slice may be used for 5G or other network scenarios.
In the context of 5G, the 5G end-to-end network slices consist of
three different types of network technology segments: Radio Access
Network (RAN), Transport Network (TN) and Core Network (CN). The
transport segments of 5G end-to-end network slice can be provided
using IETF network slices. In some scenarios, IETF network slices
may span multiple network domains, and IETF network slices may be
composed hierarchically, which means a network slice may itself be
further sliced.
This document first describes the possible use cases of composite
IETF network slices, then it provides considerations about the
realization of composite IETF network slices. For the interaction
between IETF network slices with 5G network slices, the identifiers
Li, et al. Expires 14 September 2023 [Page 3]
Internet-Draft Composite IETF Network Slices March 2023
of 5G network slice may be introduced into IETF networks. For the
multi-domain IETF network slices, the Inter-Domain Network Resource
Partition Identifier (Inter-domain NRP ID) is defined. For the
hierarchical IETF network slices, the structure of the NRP ID is
discussed. These network slice related identifiers may be used in
the data plane, control plane and management plane of the network for
the instantiation and management of composite IETF network slices.
This document also describes the management considerations of
composite network slices.
2. Composite Network Slice Use Cases
2.1. Multi-domain IETF Network Slices
One typical scenario of multi-domain IETF network slice is to support
5G network slicing as shown in Figure 1. 5G end-to-end network slices
consists of the slice subnets in RAN, Mobile Core and Transport
networks. In the RAN and Mobile Core networks, the 5G end-to-end
network slice is identified by a Single Network Slice Selection
Assistance Information (S-NSSAI). In the transport network, the 5G
network slice is mapped to one or multiple IETF network slices.
The IETF network slice itself may span multiple network domains. An
IETF network slice may be realized as an inter-domain VPN+ service,
which is similar to the inter-domain VPNs with additional resource
and performance commitments. In the underlay network, the IETF
network slices can be supported by the multi-domain NRPs, which is
the concatenation of multiple intra-domain NRPs from different
network domains.
Li, et al. Expires 14 September 2023 [Page 4]
Internet-Draft Composite IETF Network Slices March 2023
5G Network Slices (S-NSSAI)
o--------------------------------------------------------------------o
/----\ /----\ /----\ /----\ /----\
/ \ // \\ // \\ // \\ / \
| RAN |---| TN-1 |---| TN-2 |----| TN-3 |----| Core |
\ / \\ // \\ // \\ // \ /
\----/ \----/ \----/ \----/ \----/
Multi-domain IETF Network Slice
o--------------------------------------------------o
Multi-domain NRPs
o=========================================o
Local NRPs Local NRPs Local NRPs
o**********o o***********o o***********o
o##########o o###########o o###########o
o@@@@@@@@@@o o@@@@@@@@@@@o o@@@@@@@@@@@o
Figure 1. Multi-domain IETF Network Slice in 5G Scenario
2.2. Hierarchical IETF Network Slices
2.2.1. Per-Customer Network Slices in an Industrial Slice
A typical network slice deployment scenario is in the multi-
industrial network case, in which a physical network is used to
deliver services to 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, it may be necessary
to create separate network slices for some or all of the customers
within each industry.
For example, within the education network slice, some of the
universities may require a separate network slice to connect with a
set of branch campuses. Another example is within the health-care
network slice, some of the hospitals may require a separate network
slice for the connectivity and services between a set of the branch
hospitals.
Li, et al. Expires 14 September 2023 [Page 5]
Internet-Draft Composite IETF Network Slices March 2023
---------------------------------/
/ Industry Slice 1 /
/ ----------------------- /
/ / Customer Slice 1 / /
/ -----------------------/ /
/ ----------------------- /
/ / Customer Slice 2 / /
/ -----------------------/ /
/ ... /
---------------------------------/
...
---------------------------------/
/ Industry Slice 2 /
/ ----------------------- /
/ / Customer Slice 1 / /
/ -----------------------/ /
/ ----------------------- /
/ / Customer Slice 2 / /
/ -----------------------/ /
/ ... /
---------------------------------/
Figure 2. Hierarchical Network Slices: Scenario 1
2.2.2. Per-Application Network Slices in a Customer 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 split further
their network slices into different sub-network slices for a subset
of applications.
For example, a network slice for a hospital may be further divided to
carry different types of medical applications, such as remote patient
monitoring, remote ultrasound diagnosis, medical image transmission
etc.
Li, et al. Expires 14 September 2023 [Page 6]
Internet-Draft Composite IETF Network Slices March 2023
---------------------------------/
/ Customer Slice 1 /
/ ----------------------- /
/ / APP Slice 1 / /
/ -----------------------/ /
/ ----------------------- /
/ / APP Slice 2 / /
/ -----------------------/ /
/ ... /
---------------------------------/
...
---------------------------------/
/ Customer Slice 2 /
/ ----------------------- /
/ / APP Slice 1 / /
/ -----------------------/ /
/ ----------------------- /
/ / APP Slice 2 / /
/ -----------------------/ /
/ ... /
---------------------------------/
Figure 3. Hierarchical Network Slices: Scenario 2
2.2.3. Network Slice Services in a Wholesale Network Slice
An 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, while some additional requirements on
the SLOs and SLEs may be required by the second-level network slice
customer.
Li, et al. Expires 14 September 2023 [Page 7]
Internet-Draft Composite IETF Network Slices March 2023
---------------------------------/
/ Wholesale Slice 1 /
/ ----------------------- /
/ / Customer Slice 1 / /
/ -----------------------/ /
/ ----------------------- /
/ / Customer Slice 2 / /
/ -----------------------/ /
/ ... /
---------------------------------/
...
---------------------------------/
/ Wholesale Slice 2 /
/ ----------------------- /
/ / Customer Slice 1 / /
/ -----------------------/ /
/ ----------------------- /
/ / Customer Slice 2 / /
/ -----------------------/ /
/ ... /
---------------------------------/
Figure 4. Hierarchical Network Slices: Scenario 3
3. Realization of Composite Network Slices
The realization of composite network slices may require additional
capability and functionality in the data plane, control plane and
management plane technologies. These considerations are analyzed in
the following subsections.
3.1. Network Slices Related Identifiers
For the realization of multi-domain network slices, the following
network slice related identifiers may be introduced in the management
plane, control plane and the data plane.
* Intra-domain NRP ID: This is the NRP-ID as defined in
[I-D.ietf-teas-nrp-scalability]. It is used by the network nodes
in a network domain to determine the set of local network
resources reserved for an NRP.
* Multi-domain NRP ID: This identifier uniquely identifies a multi-
domain NRP. In each network domain, the domain border nodes can
map the multi-domain NRP-ID to the intra-domain NRP IDs within the
local network domain.
Li, et al. Expires 14 September 2023 [Page 8]
Internet-Draft Composite IETF Network Slices March 2023
A multi-domain network slice may be supported by a multi-domain NRP
in the underlay, which consists of the concatenation of multiple
intra-domain NRPs. Each intra-domain NRP can be identified using a
domain-significant NRP ID. In order to facilitate the concatenation
of multiple intra-domain NRPs into a multi-domain NRP, the multi-
domain NRP may be needed.
For the scenarios of 5G network slicing, in order to facilitate the
mapping and management of 5G network slice services in the IETF
network slices, the identifier of 5G network slice may be needed in
the transport network.
* 5G network slice ID (S-NSSAI): This identifies the 5G network
slice. When required, it may be used by the network entities of
IETF network slices to provide traffic monitoring at the 5G
network slice granularity.
For the service scenarios which are not specific to 5G network
slicing, other types of service identifiers may be used to identify
the IETF network slice services.
The existence of the multi-domain NRP-ID depends on how the intra-
domain NRP IDs are managed. In some network scenarios, different
network domains can have consistent NRP ID allocation, then the
intra-domain NRP IDs can also be used to identify the multi-domain
NRPs. The awareness to the S-NSSAI and other network slice service
identifiers depend on whether the performance of 5G end-to-end
network slices need to be monitored in the transport network.
For the realization of hierarchical IETF network slices, since
network resources may be partitioned hierarchically, the NRP IDs may
be used to identify the first-level NRPs, the second-level NRPs, or
the both.
3.2. Data Plane
The considerations about the network slice data plane can be
classified into two aspects. The first is the mechanisms used for
partitioning the data plane network resources, and the second is the
mechanisms used to determine to which network slice a data packet
belongs.
Li, et al. Expires 14 September 2023 [Page 9]
Internet-Draft Composite IETF Network Slices March 2023
3.2.1. Forwarding Resource Partitioning
For multi-domain network slices, in order to fulfil the end-to-end
network slice service commitment, it is important that the forwarding
plane network resources in each of the involved network domains can
be partitioned, so that the intra-domain NRPs can be created, which
together constitute the multi-domain NRPs for the end-to-end network
slice services.
For hierarchical network slices, the forwarding plane network
resources may need to be partitioned hierarchically. Taking a two-
level hierarchical network slice as an example, the bandwidth and
associated resources of a physical interface needs to be partitioned
into two levels.
Different technologies may be used for the data plane resource
partitioning in different network domains or different network
hierarchy. For example, for resource partitioning of multi-domain
network slices, it could be the case that in one network domain, the
forwarding resources may partitioned using Flexible Ethernet (FlexE),
while in another network domain, the resources may be partitioned
using dedicated queues under the same interface. Similarly, for
hierarchical network resource partitioning, the network resources of
the first-level NRPs may be partitioned using separate layer-3 sub-
interfaces with dedicated link bandwidth, while the second-level NRPs
may be further partitioned using virtual data channels under the
layer-3 sub-interfaces.
3.2.2. Data Plane Identifiers
The traffic of IETF network slices can be steered into the
corresponding NRPs based on one or multiple fields in the data
packet, so that the set of network resources of 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.ietf-teas-nrp-scalability]
can facilitate the identification of the NRP a packet belongs to.
Li, et al. Expires 14 September 2023 [Page 10]
Internet-Draft Composite IETF Network Slices March 2023
When IETF network slice service packets traverse a multi-domain NRP,
the identifier of the multi-domain NRP may be carried in the packet,
so that the border nodes of each network domain can determine the
local domain NRP according to the mapping relationship between the
multi-domain NRP ID and the local domain NRP ID. The intra-domain
NRP ID may be carried in the packet for the NRP-specific packet
processing on network nodes in the local domain. This usually
requires that the involved network domains of a multi-domain NRP are
in the same trusted domain.
For the 5G end-to-end network slices, in order to facilitate the
mapping and management of 5G network slice services in the IETF
network slices, the S-NSSAI of 5G network slice may be carried in the
packet sent to the transport network. For the service scenarios
which are not specific to 5G network slicing, other types of service
identifiers may be carried in the packet sent to the transport
network.
For hierarchical IETF network slices, the data plane NRP ID may be
used to identify the first-level NRPs, the second-level NRPs, or the
both. There may be different options in the design of the data plane
NRP ID 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.
* The second option is to use hierarchical identifiers for the
first-level NRP and the second-level NRP respectively. 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.
3.3. Control Plane
For multi-domain network slices, the control plane would be similar
to the Inter-AS VPN services [RFC4364]. In the overlay, the Option C
mode of inter-AS VPN is preferred due to the simplicity in the
service endpoints provisioning. Using the Option A or Option B mode
of inter-domain VPN for multi-domain network slices is also possible,
although they are not the focus of this document. In the underlay,
the provisioning and distribution of the intra-domain NRP IDs in
different network domains may be done via network controllers or
distributed control plane. The allocation of the Multi-domain NRP-ID
Li, et al. Expires 14 September 2023 [Page 11]
Internet-Draft Composite IETF Network Slices March 2023
and the mapping relationship between the multi-domain NRP ID and the
intra-domain NRP IDs are usually performed by the IETF network slice
controller. For 5G end-to-end network slices, the IETF network slice
controller may also be responsible for the provisioning of the
mapping relationship between the S-NSSAI and the multi-domain NRP ID
at the domain edge nodes.
For hierarchical network slices, the control plane is used for the
distribution of the attributes and states of NRPs in different
hierarchy among network nodes in the NRP and also to the network
controller. With different modeling of the partitioned network
resources, the information may be advertised as either layer-3 or
layer-2 network information.
4. Management Considerations
For multi-domain network slices, some coordination in management
plane among different network domains would be needed. That includes
but not limited to the planning of intra-domain NRPs to meet the same
or similar set of SLO and SLEs, the allocation and mapping of intra-
domain NRP IDs with the multi-domain NRP IDs.
For the 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 the management of 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 of management plane
requirements is for future study.
5. IANA Considerations
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
6. Security Considerations
Several broad security considerations exist, and Section 6 of
[I-D.ietf-teas-ietf-network-slices] highlights several important
security aspects for network slice deployment and operation. These
security considerations will apply to the architecture and techniques
outlined in this document and multi-domain NRPs for end-to-end
network slices.
Li, et al. Expires 14 September 2023 [Page 12]
Internet-Draft Composite IETF Network Slices March 2023
Ensuring that only authorised customers have access to end-to-end
network slices is important. In addition, malicious intent to
access, delete or modify the end-to-end service should also be
mitigated or negated.
The control plane may distribute attributes of different levels of
hierarchical NRPs among network nodes, including communicating this
information to the controller. Therefore, secure methods will be
required to disseminate, control, and store NRP related information.
Multiple data plane methods are applicable for instantiating the end-
to-end network slice services. However, these techniques have
security advantages and disadvantages and must be considered when
deploying multi-domain and hierarchical network slices. In addition,
some encapsulation methods will have stronger security or encryption
capabilities that may be required for certain customer slice
applications where confidentiality or securing data being transmitted
across the end-to-end slice is needed.
Future versions of this document will expand the security discussion
and propose techniques to address the security concerns, and
highlight any missing requirements specific to this document.
7. Contributors
Zhibo Hu
Email: huzhibo@huawei.com
8. Acknowledgements
The authors would like to thank Daniel King for his review and
comments.
9. References
9.1. Normative References
[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+)",
Work in Progress, Internet-Draft, draft-ietf-teas-
enhanced-vpn-12, 23 January 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-teas-
enhanced-vpn-12>.
[I-D.ietf-teas-ietf-network-slices]
Farrel, A., Drake, J., Rokui, R., Homma, S., Makhijani,
K., Contreras, L. M., and J. Tantsura, "A Framework for
Li, et al. Expires 14 September 2023 [Page 13]
Internet-Draft Composite IETF Network Slices March 2023
IETF Network Slices", Work in Progress, Internet-Draft,
draft-ietf-teas-ietf-network-slices-19, 21 January 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-teas-
ietf-network-slices-19>.
9.2. Informative References
[I-D.ietf-teas-nrp-scalability]
Dong, J., Li, Z., Gong, L., Yang, G., Guichard, J.,
Mishra, G. S., Qin, F., Saad, T., and V. P. Beeram,
"Scalability Considerations for Network Resource
Partition", Work in Progress, Internet-Draft, draft-ietf-
teas-nrp-scalability-01, 24 October 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-teas-
nrp-scalability-01>.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
2006, <https://www.rfc-editor.org/info/rfc4364>.
Authors' Addresses
Zhenbin Li
Huawei Technologies
Huawei Campus, No. 156 Beiqing Road
Beijing
100095
China
Email: lizhenbin@huawei.com
Jie Dong
Huawei Technologies
Huawei Campus, No. 156 Beiqing Road
Beijing
100095
China
Email: jie.dong@huawei.com
Ran Pang
China Unicom
Email: pangran@chinaunicom.cn
Yongqing Zhu
China Telecom
Email: zhuyq8@chinatelecom.cn
Li, et al. Expires 14 September 2023 [Page 14]
Internet-Draft Composite IETF Network Slices March 2023
Luis M. Contreras
Telefonica
Email: luismiguel.contrerasmurillo@telefonica.com
Li, et al. Expires 14 September 2023 [Page 15]