TEAS LM. Contreras Internet-Draft Telefonica Intended status: Informational R. Rokui Expires: 14 September 2023 Ciena J.T. Tantsura Microsoft B. Wu Huawei X. Liu IBM Corporation D. Dhody Huawei S. Belloti Nokia March 2023 IETF Network Slice Controller and its associated data models draft-contreras-teas-slice-controller-models-05 Abstract This document describes a potential division in major functional components of an IETF Network Slice Controller (NSC) as well as references the data models required for supporting the requests of IETF network slice services and their realization. This document describes a potential way of structuring the IETF Network Slice Controller as well as how to use different data models being defined for IETF Network Slice Service provision (and how they are related). It is not the purpose of this document to standardize or constrain the implementation the IETF Network Slice Controller. 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." Contreras, et al. Expires 14 September 2023 [Page 1] Internet-Draft Slice Controller and its data models March 2023 This Internet-Draft will expire on 2 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. IETF Network Slice data models . . . . . . . . . . . . . . . 4 3. Structure of the IETF Network Slice Controller (NSC) . . . . 5 3.1. NS Mapper . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. NS Realizer . . . . . . . . . . . . . . . . . . . . . . . 7 4. Model types in IETF Network Slice Controller interfaces . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. Points for further dicussion (TODO) . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction The generic idea of network slicing intends to provide tailored end- to-end network capabilities to customers in the way that they could be perceived as a dedicated network, despite the fact that it makes use of shared physical infrastructure facilities. Among the capabilities mentioned, connectivity of different parts of a network slice with particular performance characteristics play a central role. Thus, the concept of IETF Network Slice, realized by any of the IETF technologies, emerges as complementary but essential part of an end-to-end network slice. In order to facilitate the request, realization and lifecycle control and management of a transport slice, a new element named IETF Network Slice Controller (NSC) is being proposed in [I-D.ietf-teas-ietf-network-slices]. Contreras, et al. Expires 14 September 2023 [Page 2] Internet-Draft Slice Controller and its data models March 2023 The NSC from its North Bound Interface (NBI), i.e. the IETF Network Slice Service interface, exposes set of APIs that allow a higher level system to request an end-to-end transport slice. It receives the request of enablement of an IETF Network Slice by a customer (i.e. creation, modification or deletion). Upon receiving a request from its NBI, the NSC finds the resources needed for realization of the IETF Network Slice and in turn interfaces from its South Bound Interface (SBI) with one or more Network Controllers for the realization of the requested IETF Network Slice request and the management of its lifecycle. Figure 1 presents a high-level view of the IETF NSC [I-D.ietf-teas-ietf-network-slices]. +------------------------------------------+ | Customer higher level operation system | | (e.g E2E network slice orchestrator, | | customer network management system) | +------------------------------------------+ A | IETF Network Slice Service Interface V +------------------------------------------+ | IETF Network Slice Controller (NSC) | +------------------------------------------+ A | Network Configuration Interface V +------------------------------------------+ | Network Controllers | +------------------------------------------+ Figure 1: Interface of Transport Slice Controller This document describes the characteristics of the NSC as well as a detailed structure of the NSC and its major components. In addition, it describes the characteristics of the data models to identify the IETF Network Slice and its realization. Then the referred data models are mapped to the interfaces among components. It is important to remark that this document describes a potential way of structuring the IETF Network Slice Controller as well as how to use different data models being defined for IETF Network Slice Service provision (and how they are related). It is not the purpose of this document to standardizing or constraining the implementation the IETF Network Slice Controller. Contreras, et al. Expires 14 September 2023 [Page 3] Internet-Draft Slice Controller and its data models March 2023 2. IETF Network Slice data models At the time of provisioning and operating IETF Network Slices different views can be identified as necessary: * Customer's view, mostly focused on the individual IETF Network Slice request process, reflecting the needs of each particular customer, including SLOs and other characteristics of the slice relevant for it. This view is technology agnostic and describes the characteristics of the IETF Network Slice from a customer's point of view. It can include the slice topology, performance parameters, endpoints of the slice, traffic characteristics of the slice, and the KPIs to monitor the slice. * Provider's view, mostly focused on the provisioning and operation of IETF Network Slices in the underlay network, considering how a particular IETF Network Slice interplays with other IETF Network Slices maintained by the provider on a shared infrastructure. In other words, operator's view shows how an IETF Network Slice is realized in operator's network along with all the resources used during the its realization. Both views are complementary, each of them specialized for a given purpose. In consequence, it should be consistency between both in order to ensure alignment. Currently there are two different models proposed, one for each of the categories above. The model in [I-D.ietf-teas-ietf-network-slice-nbi-yang] fits into the customer view, while the model defined in [I-D.liu-teas-transport-network-slice-yang] fits in to the provider view. It should be noted that for the realization of an IETF Network Slice, the NSC interacts with one or more Network Controllers underneath. In that case, the data models to be used are particular for each Network Controller (e.g., technology dependent), as well as the mapping function from its NBI (i.e., IETF Network Slice Service interface) to SBI (i.e., Network Configuration Interface) and the details of this mapping function are both out of the scope of this document. Contreras, et al. Expires 14 September 2023 [Page 4] Internet-Draft Slice Controller and its data models March 2023 3. Structure of the IETF Network Slice Controller (NSC) The NSC should work with both data models. The NSC takes first the customer’s view by analyzing the needs of the customer, processing such requests taking into account the overall view of the network and the IETF Network Slices already instantiated, normalizing its instantiation across different technologies, and finally generates the provider view. Once the new request is processed and declared as feasible, the NSC triggers its realization by interacting with the Network Controllers underneath and communicates back to the higher level controller to start the billing cycle. In order to accommodate these procedures, the internal structure of the NSC can be divided into: * IETF Network Slice Mapper: this high-level component processes the customer request, putting it into the context of the overall IETF Network Slices in the network. * IETF Network Slice Realizer: this high-level component processes the complete view of transport slices including the one requested by the customer, decides the proper technologies for realizing the IETF Network Slice and triggers its realization. Figure 2 illustrates the components described and the associated models, as follows * (a) -> customer's view, e.g. [I-D.ietf-teas-ietf-network-slice-nbi-yang]. * (b) -> provider's view, including more detailed but yet technology-agnostic resource view as e.g. [I-D.liu-teas-transport-network-slice-yang], and/or alternative technology-specific augmentations as e.g. for OTN [I-D.ietf-ccamp-yang-otn-slicing] or for IP/MPLS NRP [I-D.wd-teas-nrp-yang]. * (c) -> models per network controller, out of scope of this document. An example of applicability of existing models is in [I-D.barguil-teas-network-slices-instantation]. Contreras, et al. Expires 14 September 2023 [Page 5] Internet-Draft Slice Controller and its data models March 2023 Higher Level System | | +-------------------------+ | NSC | (a) | | v | | +-----------------+ | | | | | | | NS Mapper | | | | | | | +-----------------+ | | | (b) | | v | | +-----------------+ | | | | | | | NS Realizer | | | | | | | +-----------------+ | | | (c) | +-------------------------+ | v Network Controllers Figure 2: IETF Network Slice Controller structure and asspociated data models IETF Network Slices with different level of detail could be requested: * The IETF network slice can be abstracted as a set of edge-to-edge links (Type 1). * The IETF network slice can be abstracted as a topology of virtual nodes and virtual links (Type 2) which represent the partitioning of underlay network resources for use by network slice connectivity. The use cases of these two types of networks are further described by [RFC8453]. Regarding IETF Network Slice service requests, it is possible to model the Type 1 service by means of [I-D.ietf-teas-ietf-network-slice-nbi-yang] , while it is possible to model the Type 2 service using [I-D.liu-teas-transport-network-slice-yang] . Moreover, when a customer intends to request a Type 2 service, [I-D.liu-teas-transport-network-slice-yang] can also be used at the Contreras, et al. Expires 14 September 2023 [Page 6] Internet-Draft Slice Controller and its data models March 2023 point (a) in Figure 2. It should be noted that according to [I-D.ietf-teas-ietf-network-slices], the customer might ask for some level of control of the IETF Network Slice, for instance to customize the service paths in a network slice. The abstract topology defined in [I-D.liu-teas-transport-network-slice-yang] could serve to enable this capability and optimize the resource utilization for network slice connections activated on top of the abstract topology. In respect to IETF Network Slice ealization, as an example, when ACTN is used to realize an IETF network slice, model mappings are described in more details in [I-D.ietf-teas-actn-yang]. 3.1. NS Mapper The Mapper will receive the IETF Network Slice request from the customer. It will process it obtaining an overall view of how this new request complements or fits with the rest of IETF Network Slices, if any, as provisioned in the network. As part of that processing, a single customer IETF Network Slice request could result in the need of actually provisioning different IETF Network Slices in the network. The Mapper will maintain the relationship among customer IETF Network Slice request and provisioned IETF Network Slices. The Mapper also will provide performance notifications in relation with the SLOs dictated in the slice request by the customer. The Mapper performs resource partitions of the filtered topologies provided by the Realizer component, generating specific Network Resource Partitions (NRPs). An NRP represents a collection of resources such as buffers, queues, etc, of the links of a filtered topology. The Mapper, when processing the slice request, will map the connectivity constructs to one or more NRPs, e.g., according to specific SLOs. As part of the performance monitoring of the IETF Network Slice service, the Mapper will aggregate performance information from the distinct NRPs used for mapping the connectivity constructs forming the slice. 3.2. NS Realizer The Realizer will receive from the Mapper one or more requests for provision of IETF Network Slices, potentially including some technology-specific information. With that information, the Realizer will determine the realization of each particular IETF Network Slice interacting with technology-specific Network Controllers. Contreras, et al. Expires 14 September 2023 [Page 7] Internet-Draft Slice Controller and its data models March 2023 The Realizer will be in charge of generating filtered topologies from the underlying (physical) network information provided by the Network Controllers. The handling of filtered topologies is optional, then if not filtering is applied, the Realizer could expose the physical network. The filtered topologies represent a selection of nodes and links from the underlying network(s), e.g. as result of applying certain policies. The Realizer will provide the telemetry information from the filtered topologies to the Mapper for further processing in support of the performance assurance of the IETF Network Slices. 4. Model types in IETF Network Slice Controller interfaces Both [RFC8309] and [RFC8969] offer a complete view of customer, service and network model types. In this sense a potential mapping of models to IETF Network Slcie Controller interfaces is as follows: * NBI of the IETF NSC, i.e. IETF Network Slice Service interface (interface (a) in Figure 2) -> Customer service model. According to [RFC8309] "a customer's service request is (or should be) technology agnostic. That is, a customer is unaware of the technology that the network operator has available to deliver the service, so the customer does not make requests specific to the underlying technology but is limited to making requests specific to the service that is to be delivered". This definition matches the expected behavior of the IETF NSC NBI as considered in [I-D.ietf-teas-ietf-network-slices]. * Interface between NS Mapper and NS Realizer (interface (b) in Figure 2) -> Service Delivery model. According to [RFC8309] "a service delivery module is expressed as a core set of parameters that are common across a network type and technology [...] Service delivery modules include technology-specific modules.". Furthermore, [RFC8969] (in its Figures 3 and 5) considers L3SM or VN Service models to be later on fed into a controller. * SBI of the IETF NSC, i.e. Network Configuration interface (interface (c) in Figure 2) -> Network Configuration model. According to [RFC8309] "the orchestrator must map the service request to its view, and this mapping may include a choice of which networks and technologies to use depending on which service features have been requested". This is coincideent with the expected behavior of the IETF NSC SBI as considered in in [I-D.ietf-teas-ietf-network-slices]. Contreras, et al. Expires 14 September 2023 [Page 8] Internet-Draft Slice Controller and its data models March 2023 5. Security Considerations This draft considers both the Mapper and the Realizer component as internal modules of the IETF Network Slice Controller. However, anything prevents that these modules could be separated components, communicating through standard protocols (i.e., not as an internal communication to the IETF NSC). In that case, some security requirements apply such as: * Authentication between Mapper and Realizer, to prevent malicious behaviors. * Privacy of the information shared between components. * Secure transport between components based on the kind of interface used in the communication (e.g., NETCONF, RESTCONF, etc). 6. Points for further dicussion (TODO) There are a number of open points that require more discussion among authors: * Alignment of the references to [I-D.liu-teas-transport-network-slice-yang] with respect the new scope of the draft in its latest version, which provides a topology view of slice request, that is, becoming topology-intent service from the customer (not related to realization). * Consideration of the funcationality enabled by the topological information included in [I-D.ietf-teas-ietf-network-slice-nbi-yang]. These open points will be covered in the next version of the draft. 7. IANA Considerations This draft does not include any IANA considerations 8. References Contreras, et al. Expires 14 September 2023 [Page 9] Internet-Draft Slice Controller and its data models March 2023 [I-D.barguil-teas-network-slices-instantation] Giraldo, S. B., Contreras, L. M., Lopez, V., Rokui, R., Dios, O. G. D., and D. King, "Instantiation of IETF Network Slices in Service Providers Network", Work in Progress, Internet-Draft, draft-barguil-teas-network- slices-instantation-06, 13 March 2023, . [I-D.ietf-ccamp-yang-otn-slicing] Guo, A., Contreras, L. M., Belotti, S., Rokui, R., Xu, Y., Zhao, Y., and X. Liu, "Framework and Data Model for OTN Network Slicing", Work in Progress, Internet-Draft, draft- ietf-ccamp-yang-otn-slicing-04, 13 March 2023, . [I-D.ietf-teas-actn-yang] Lee, Y., Zheng, H., Ceccarelli, D., Yoon, B. Y., and S. Belotti, "Applicability of YANG models for Abstraction and Control of Traffic Engineered Networks", Work in Progress, Internet-Draft, draft-ietf-teas-actn-yang-11, 7 March 2023, . [I-D.ietf-teas-ietf-network-slice-nbi-yang] Wu, B., Dhody, D., Rokui, R., Saad, T., Han, L., and J. Mullooly, "A YANG Data Model for the IETF Network Slice Service", Work in Progress, Internet-Draft, draft-ietf- teas-ietf-network-slice-nbi-yang-04, 13 March 2023, . [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 IETF Network Slices", Work in Progress, Internet-Draft, draft-ietf-teas-ietf-network-slices-19, 21 January 2023, . Contreras, et al. Expires 14 September 2023 [Page 10] Internet-Draft Slice Controller and its data models March 2023 [I-D.liu-teas-transport-network-slice-yang] Liu, X., Tantsura, J., Bryskin, I., Contreras, L. M., Wu, Q., Belotti, S., Rokui, R., Guo, A., and I. Busi, "IETF Network Slice Topology YANG Data Model", Work in Progress, Internet-Draft, draft-liu-teas-transport-network-slice- yang-06, 13 March 2023, . [I-D.wd-teas-nrp-yang] Wu, B., Dhody, D., Boucadair, M., Cheng, Y., and L. Gong, "A YANG Data Model for Network Resource Partitions (NRPs)", Work in Progress, Internet-Draft, draft-wd-teas- nrp-yang-02, 25 September 2022, . [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, . [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for Abstraction and Control of TE Networks (ACTN)", RFC 8453, DOI 10.17487/RFC8453, August 2018, . [RFC8969] Wu, Q., Ed., Boucadair, M., Ed., Lopez, D., Xie, C., and L. Geng, "A Framework for Automating Service and Network Management with YANG", RFC 8969, DOI 10.17487/RFC8969, January 2021, . Acknowledgments The authors would like to thank (in alphabetical order) to Aihua Guo and Joel Halpern for their valuable comments received. Authors' Addresses Luis M. Contreras Telefonica Ronda de la Comunicacion, s/n Sur-3 building, 3rd floor 28050 Madrid Spain Email: luismiguel.contrerasmurillo@telefonica.com URI: http://lmcontreras.com/ Contreras, et al. Expires 14 September 2023 [Page 11] Internet-Draft Slice Controller and its data models March 2023 Reza Rokui Ciena Canada Email: rrokui@ciena.com Jeff Tantsura Microsoft United States of America Email: jefftant.ietf@gmail.com Bo Wu Huawei Technologies 101 Software Avenue, Yuhua District Nanjing, Jiangsu 210012 China Email: lana.wubo@huawei.com Xufeng Liu IBM Corporation Email: xufeng.liu.ietf@gmail.com Dhruv Dhody Huawei Technologies Divyashree Techno Park Bangalore, Karnataka 560066 India Email: dhruv.ietf@gmail.com Sergio Belloti Nokia Email: sergio.belotti@nokia.com Contreras, et al. Expires 14 September 2023 [Page 12]