Skip to main content

Considerations about Generalized IETF Network Slicing
draft-li-teas-generalized-ietf-network-slicing-01

Document Type Active Internet-Draft (individual)
Authors Zhenbin Li , Jie Dong , Jing Gao
Last updated 2023-10-20
RFC stream (None)
Intended RFC status (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-generalized-ietf-network-slicing-01
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]