Internet DRAFT - draft-li-teas-generalized-ietf-network-slicing
draft-li-teas-generalized-ietf-network-slicing
Network Working Group Z. Li
Internet-Draft J. Dong
Intended status: Informational Huawei Technologies
Expires: 22 April 2024 J. Gao
China Academy of Information and Communications Technology
20 October 2023
Considerations about Generalized IETF Network Slicing
draft-li-teas-generalized-ietf-network-slicing-01
Abstract
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.
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/.
Li, et al. Expires 22 April 2024 [Page 1]
Internet-Draft Generalized IETF Network Slicing October 2023
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 22 April 2024.
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Acronyms and Terminology . . . . . . . . . . . . . . . . . . 3
3. NRP and Topology . . . . . . . . . . . . . . . . . . . . . . 3
4. NRP with Various Types of Resources . . . . . . . . . . . . . 4
5. NRP for Multiple Connectivity Constructs . . . . . . . . . . 5
6. IETF Network Slices for More Application Scenarios . . . . . 5
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
8. Security Considerations . . . . . . . . . . . . . . . . . . . 6
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
10.1. Normative References . . . . . . . . . . . . . . . . . . 6
10.2. Informative References . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
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
Li, et al. Expires 22 April 2024 [Page 2]
Internet-Draft Generalized IETF Network Slicing October 2023
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.
2. Acronyms and Terminology
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].
3. NRP and Topology
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.
Li, et al. Expires 22 April 2024 [Page 3]
Internet-Draft Generalized IETF Network Slicing October 2023
[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 [RFC9350], 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.
4. NRP with Various Types of Resources
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.
Li, et al. Expires 22 April 2024 [Page 4]
Internet-Draft Generalized IETF Network Slicing October 2023
5. NRP for Multiple Connectivity Constructs
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.
6. IETF Network Slices for More Application Scenarios
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.
Li, et al. Expires 22 April 2024 [Page 5]
Internet-Draft Generalized IETF Network Slicing October 2023
7. IANA Considerations
This document makes no request of IANA.
8. Security Considerations
TBD
9. Acknowledgements
TBD
10. References
10.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-14, 28 July 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-teas-
enhanced-vpn-14>.
[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
Network Slices in Networks Built from IETF Technologies",
Work in Progress, Internet-Draft, draft-ietf-teas-ietf-
network-slices-25, 14 September 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-teas-
ietf-network-slices-25>.
[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>.
10.2. Informative References
[I-D.ietf-6man-enhanced-vpn-vtn-id]
Dong, J., Li, Z., Xie, C., Ma, C., and G. S. Mishra,
"Carrying Virtual Transport Network (VTN) Information in
IPv6 Extension Header", Work in Progress, Internet-Draft,
draft-ietf-6man-enhanced-vpn-vtn-id-05, 6 July 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-6man-
enhanced-vpn-vtn-id-05>.
Li, et al. Expires 22 April 2024 [Page 6]
Internet-Draft Generalized IETF Network Slicing October 2023
[I-D.ietf-spring-resource-aware-segments]
Dong, J., Bryant, S., Miyasaka, T., Zhu, Y., Qin, F., Li,
Z., and F. Clad, "Introducing Resource Awareness to SR
Segments", Work in Progress, Internet-Draft, draft-ietf-
spring-resource-aware-segments-07, 31 May 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-spring-
resource-aware-segments-07>.
[I-D.li-6man-topology-id]
Li, Z., Hu, Z., and J. Dong, "Topology Identifier in IPv6
Extension Header", Work in Progress, Internet-Draft,
draft-li-6man-topology-id-00, 20 March 2022,
<https://datatracker.ietf.org/doc/html/draft-li-6man-
topology-id-00>.
[RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P.
Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF",
RFC 4915, DOI 10.17487/RFC4915, June 2007,
<https://www.rfc-editor.org/info/rfc4915>.
[RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi
Topology (MT) Routing in Intermediate System to
Intermediate Systems (IS-ISs)", RFC 5120,
DOI 10.17487/RFC5120, February 2008,
<https://www.rfc-editor.org/info/rfc5120>.
[RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
L., Sridhar, T., Bursell, M., and C. Wright, "Virtual
eXtensible Local Area Network (VXLAN): A Framework for
Overlaying Virtualized Layer 2 Networks over Layer 3
Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014,
<https://www.rfc-editor.org/info/rfc7348>.
[RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas,
"Deterministic Networking Architecture", RFC 8655,
DOI 10.17487/RFC8655, October 2019,
<https://www.rfc-editor.org/info/rfc8655>.
[RFC9350] Psenak, P., Ed., Hegde, S., Filsfils, C., Talaulikar, K.,
and A. Gulko, "IGP Flexible Algorithm", RFC 9350,
DOI 10.17487/RFC9350, February 2023,
<https://www.rfc-editor.org/info/rfc9350>.
Authors' Addresses
Zhenbin Li
Huawei Technologies
Huawei Campus, No. 156 Beiqing Road
Li, et al. Expires 22 April 2024 [Page 7]
Internet-Draft Generalized IETF Network Slicing October 2023
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
Jing Gao
China Academy of Information and Communications Technology
China
Email: gaojing1@caict.ac.cn
Li, et al. Expires 22 April 2024 [Page 8]
