Framework for End-to-End IETF Network Slicing
draft-li-teas-e2e-ietf-network-slicing-01
The information below is for an old version of the document.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Zhenbin Li , Jie Dong , Ran Pang , Yongqing Zhu | ||
| Last updated | 2021-10-25 | ||
| Stream | (None) | ||
| Formats | plain text html xml htmlized pdfized bibtex | ||
| 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-e2e-ietf-network-slicing-01
Network Working Group Z. Li
Internet-Draft J. Dong
Intended status: Standards Track Huawei Technologies
Expires: 28 April 2022 R. Pang
China Unicom
Y. Zhu
China Telecom
25 October 2021
Framework for End-to-End IETF Network Slicing
draft-li-teas-e2e-ietf-network-slicing-01
Abstract
Network slicing can be used to meet the connectivity and performance
requirement of different services or customers in a shared network.
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 major types of network segments: Radio Access Network (RAN),
Transport Network (TN) and Core Network (CN). And in the transport
network, the IETF network slice may span multiple network domains.
In order to facilitate the mapping between network slices in
different network segments and network domains, it is beneficial to
carry the identifiers of the 5G end-to-end network slice, the multi-
domain IETF network slice together with the intra-domain network
slice identifier in the data packet.
This document describes the framework of end-to-end IETF network
slicing, and introduces the identifiers for 5G end-to-end network
slice and the multi-domain IETF network slice in the data packet.
The roles of the different identifiers in packet forwarding is also
described. The network slice identifiers can be instantiated with
different data planes.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
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 28 April 2022 [Page 1]
Internet-Draft E2E IETF Network Slicing October 2021
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 28 April 2022.
Copyright Notice
Copyright (c) 2021 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 Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Requirements on E2E IETF Network Slicing . . . . . . . . . . 5
3.1. Data Plane . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Management Plane/Control Plane . . . . . . . . . . . . . 5
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.1. Normative References . . . . . . . . . . . . . . . . . . 6
7.2. Informative References . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction
[I-D.ietf-teas-ietf-network-slices] introduce the concept and the
characteristics of IETF network slice, and describes a general
framework for IETF network slice management and operation.
Li, et al. Expires 28 April 2022 [Page 2]
Internet-Draft E2E IETF Network Slicing October 2021
[I-D.ietf-teas-enhanced-vpn] describes the framework and the
candidate component technologies for providing enhanced VPN (VPN+)
services based on existing VPN and Traffic Engineering (TE)
technologies with enhanced characteristics that specific services
require above traditional VPNs. It also introduces the concept of
Virtual Transport Network (VTN). A Virtual Transport Network (VTN)
is a virtual underlay network which consists of a set of dedicated or
shared network resources allocated from the physical underlay
network, and is associated with a customized logical 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.
Enhanced VPN (VPN+) and VTN can be used for the realization of IETF
network slices.
[I-D.dong-teas-enhanced-vpn-vtn-scalability] describes the
scalability considerations in the control plane and data plane to
enable VPN+ services, and proposed several suggestions to improve the
scalability of VTN. In the control plane, It proposes the approach
of decoupling the topology and resource attributes of VTN, so that
multiple VTNs may share the same topology and the result of topology
based path computation. In the data plane, it proposes to carry a
VTN-ID of a network domain in the data packet to determine the set of
resources reserved for the corresponding VTN.
An IETF network slice may span multiple network domains. Further in
the context of 5G, there can be end-to-end network slices which
consists of three major types of network segments: Radio Access
Network (RAN), Transport Network (TN) and Core Network (CN). In
order to facilitate the mapping between network slices in different
network segments and network domains, it may be beneficial to also
carry the identifiers of the 5G end-to-end network slice, the multi-
domain IETF network slice together with the intra-domain network
slice identifier in the data packet.
This document describes the scenarios of end-to-end network slicing,
and the framework of network slice mapping between different network
segments and network domains. Then multiple network slice related
identifiers are defined to covers different network scopes. These
network slice identifiers can be instantiated using different data
planes, such as MPLS and IPv6.
2. Framework
Li, et al. Expires 28 April 2022 [Page 3]
Internet-Draft E2E IETF Network Slicing October 2021
/----\ /----\ /----\ /----\ /----\
/ \ // \\ // \\ // \\ / \
| RAN |---| TN-1 |---| TN-2 |----| TN-3 |----| Core |
\ / \\ // \\ // \\ // \ /
\----/ \----/ \----/ \----/ \----/
S-NSSAI
o--------------------------------------------------------------------o
IETF Network Slice (VPN+)
o--------------------------------------------------o
Global VTN
o===========================================o
Local VTN-1 Local VTN-2 Local VTN-3
o************o o************o o***********o
Figure 1. 5G end-to-end network slicing scenario
One typical scenario of 5G end-to-end network slicing is shown in
figure 1. The 5G end-to-end network slice is identified by the
S-NSSAI (Single Network Slice Selection Assistance Information). In
the transport network segment, the 5G network slice is mapped to an
IETF network slice, which can be realized with a multi-domain VPN+
service. In the underlay network, the multi-domain VPN+ service is
supported by a multi-domain VTN, which is comprised by multiple
intra-domain VTNs in different domains. In each domain, a local VTN-
ID is carried in the packet to identify the set of network resource
reserved for the VTN in the corresponding domain.
In order to concatenate multiple local VTNs into a multi-domain VTN,
the global VTN-ID can be carried in the packet, which is used by the
network domain border routers to map to the local VTN-IDs in each
domain. And in order to facilitate the network slice mapping between
RAN, Core network and transport network, the S-NSSAI may be carried
in the packet sent to the transport network, which can be used by the
transport network to map the 5G end-to-end network slice to the
corresponding IETF network slice.
According to the above end-to-end network slicing scenario, there can
be three network slice related identifiers:
* Local VTN-ID: This is the VTN-ID as defined in
[I-D.dong-teas-enhanced-vpn-vtn-scalability]. It is used by the
network nodes in a network domain to determine the set of local
network resources reserved for a VTN. It SHOULD be processed by
each hop along the path in the domain.
Li, et al. Expires 28 April 2022 [Page 4]
Internet-Draft E2E IETF Network Slicing October 2021
* Global VTN-ID: This is the identifier which uniquely identifies a
multi-domain VTN. In each network domain, the domain edge node
maps the global VTN-ID to a local VTN-ID for packet forwarding.
* 5G end-to-end network slice ID (S-NSSAI): This is the identifier
of the 5G end-to-end network slice. When required, it may be used
by the network nodes to provide traffic monitoring at the end-to-
end network slice granularity.
For the above network slice identifiers, the local VTN-ID is
mandatory, the Global VTN-ID and the 5G S-NSSAI are optional. The
existence of the Global VTN-ID depends on whether the VTN spans
multiple network domains in the transport network. The existence of
the 5G S-NSSAI depends on whether an IETF network slice is used as
part of the 5G end-to-end network slice.
3. Requirements on E2E IETF Network Slicing
This section lists the requirements on E2E IETF network slicing.
3.1. Data Plane
To facilitate the mapping between 5G end-to-end network slice and
IETF network slice, and the mapping between multi-domain IETF network
slice and the intra-domain IETF network slice, different network
slice related identifiers (e.g. S-NSSAI, Global VTN-ID, local VTN-
ID) needs to be carried in the data packet.
3.2. Management Plane/Control Plane
For multi-domain IETF network slice, a centralized IETF network slice
controller is responsible for the allocation of the Global VTN-ID and
the Local VTN-ID, and the provisioning of the mapping relationship of
the Global VTN-ID and the Local VTN-IDs to the network edge nodes in
different network domains.
For 5G end-to-end network slice, the edge node of transport network
can derive the S-NSSAI from the packet sent by the RAN or Core
network, and encapsulate it an outer packet header or tunnel
information when traversing the transport network. The controller
needs to be responsible for creating the mapping relationship and
provisioning it to the edge nodes of the transport network.
4. IANA Considerations
This document makes no request of IANA.
Li, et al. Expires 28 April 2022 [Page 5]
Internet-Draft E2E IETF Network Slicing October 2021
Note to RFC Editor: this section may be removed on publication as an
RFC.
5. Security Considerations
TBD
6. Acknowledgements
TBD
7. References
7.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+)
Services", Work in Progress, Internet-Draft, draft-ietf-
teas-enhanced-vpn-08, 12 July 2021,
<https://www.ietf.org/archive/id/draft-ietf-teas-enhanced-
vpn-08.txt>.
[I-D.ietf-teas-ietf-network-slices]
Farrel, A., Gray, E., 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-04, 23
August 2021, <https://www.ietf.org/archive/id/draft-ietf-
teas-ietf-network-slices-04.txt>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
7.2. Informative References
[I-D.dong-teas-enhanced-vpn-vtn-scalability]
Dong, J., Li, Z., Gong, L., Yang, G., Guichard, J. N.,
Mishra, G., and F. Qin, "Scalability Considerations for
Enhanced VPN (VPN+)", Work in Progress, Internet-Draft,
draft-dong-teas-enhanced-vpn-vtn-scalability-03, 11 July
2021, <https://www.ietf.org/archive/id/draft-dong-teas-
enhanced-vpn-vtn-scalability-03.txt>.
Authors' Addresses
Li, et al. Expires 28 April 2022 [Page 6]
Internet-Draft E2E IETF Network Slicing October 2021
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 28 April 2022 [Page 7]