idnits 2.17.00 (12 Aug 2021) /tmp/idnits24754/draft-contreras-nmrg-transport-slice-intent-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 3 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document date (January 11, 2022) is 123 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-06) exists of draft-contreras-teas-slice-nbi-05 == Outdated reference: A later version (-10) exists of draft-ietf-teas-ietf-network-slices-05 == Outdated reference: A later version (-09) exists of draft-irtf-nmrg-ibn-concepts-definitions-06 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NMRG LM. Contreras 3 Internet-Draft Telefonica 4 Intended status: Informational P. Demestichas 5 Expires: July 15, 2022 WINGS 6 J. Tantsura 7 Microsoft 8 January 11, 2022 10 IETF Network Slice Intent 11 draft-contreras-nmrg-transport-slice-intent-05 13 Abstract 15 Slicing at the transport network is expected to be offered as part of 16 end-to-end network slices, fostered by the introduction of new 17 services such as 5G. This document explores the usage of intent 18 technologies for requesting IETF network slices. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on July 15, 2022. 37 Copyright Notice 39 Copyright (c) 2022 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. IETF network slice intent . . . . . . . . . . . . . . . . . . 3 56 3. Foundation of IETF network slice intents . . . . . . . . . . 4 57 4. Mechanisms for translating IETF network slice intents . . . . 5 58 4.1. Translation approaches and interaction with the upper 59 systems . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 4.2. Intent-based system suite . . . . . . . . . . . . . . . . 6 61 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 63 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 68 1. Introduction 70 Network slicing is emerging as the future model for service offering 71 in telecom operator networks. Conceptually, network slicing provides 72 a customer with an apparent dedicated network built on top of logical 73 (i.e. virtual) and/or physical functions and resources supported by a 74 shared infrastructure, provided by one or more telecom operators. 76 The concept of network slicing has been largely fostered by the 77 advent of 5G services that are expected to be deployed on top of 78 different kind of slices, each built to support specific 79 characteristics (extreme low latency, high bandwidth, etc). 81 As part of an end-to-end network slice it is expected to have a 82 number of network slices at transport level (referred as IETF network 83 slices) providing the necessary connectivity to the rest of 84 components of the end-to-end slice, e.g., mobile packet core slice. 86 For a definition of an IETF network slice refer to 87 [I-D.ietf-teas-ietf-network-slices]. The following paragraph is 88 directly taken from it: "An IETF Network Slice Service enables 89 connectivity between a set of CEs with specific Service Level 90 Objectives (SLOs) and Service Level Expectations (SLEs) over a common 91 underlay network." 93 Intent is a high-level, declarative goal that operates at the level 94 of a network and services it provides, not individual devices. It is 95 used to define outcomes and high-level operational goals. 97 In consequence, it seems very convenient to apply the intent-based 98 mechanisms for the provision of IETF network slices, providing the 99 adequate level of abstraction towards the transport network control 100 and management planes. 102 This document leverages current industry trends in the definition of 103 end-to-end network slices. The final objective is to describe 104 intents that can be used to flexibly declare the operational aspects 105 and goals of an IETF network slice, meaning that the customer could 106 declare what kind of IETF network slice is needed (the outcome) and 107 not how to achieve the goals of the IETF network slice. 109 2. IETF network slice intent 111 As stated in [I-D.irtf-nmrg-ibn-concepts-definitions], "Intent is a 112 declaration of operational goals that a network is supposed to meet 113 and outcomes that the network is supposed to deliver, without 114 specifying how to achieve or how to implement them. Those goals and 115 outcomes are defined in a manner that is purely declarative - they 116 specify what to accomplish, not how to achieve it." 118 When applied to transport networks, this implies that an intent for 119 IETF network slices should provide the necessary abstraction with 120 respect to implementation details, including the final devices (or 121 resources) involved, and be focused on the characteristics and 122 performance expectations related to it. 124 With that aim it can be expected that the intent based system can 125 fulfill and assure the requested IETF network slice, triggering 126 initial configurations at the time of initial provisioning and 127 corrective actions during the IETF network slice lifetime. 129 Regarding the corrective actions it is possible to differentiate two 130 levels. First, corrective actions that could be performed by the 131 management and control capabilities of the network (i.e., by the IETF 132 Network Slice Controller) to maintain the Service level Objectives 133 (SLOs) as originally declared in the slice intent, so being these 134 internal actions to the management and control elements of the 135 network. Second, corrective actions that could be necessary to 136 perform due to incongruences between the SLOs expressed in the intent 137 and the observed monitoring information, then requiring some 138 adaptation to the intent itself in order to perform the corrective 139 action. 141 3. Foundation of IETF network slice intents 143 The industrial interest around 5G is accelerating network deployments 144 and operational changes. 146 With this respect, the GSMA has been developing a universal blueprint 147 that can be used by any vertical customer to request the deployment 148 of a network slice instance (NSI) based on a specific set of service 149 requirements. Such a blueprint is a network slice descriptor called 150 Generic Slice Template (GST) [GSMA]. The GST contains multiple 151 attributes that can be used to characterize a network slice. A 152 particular template filled with values generates a specific Network 153 Slice Type(NEST). 155 Such templates refer to the end-to-end network slice, including the 156 transport part. Despite the fact that some of the values would not 157 have applicability for the transport network, others do. An analysis 158 of the relevant attributes is performed in 159 [I-D.contreras-teas-slice-nbi]. 161 According to 3GPP propositions [TS28.541], an upper 3GPP Management 162 System interacts with the transport network for establishing the 163 necessary slices at the transport level. Such interaction can be 164 expected to happen using the IETF network slice intent, described to 165 an intent-based system (IBS) in the transport network part. Then, 166 according to the intent lifecycle in 167 [I-D.irtf-nmrg-ibn-concepts-definitions], the IBS, after recognizing 168 the intent, will proceed to translate it in order to interact with a 169 IETF network slice controller by using a NBI as proposed in 170 [I-D.contreras-teas-slice-nbi]. 172 Figure 1 captures the intent procedure for the fulfillment phase 173 (assurance phase will be detailed in future versions of this draft). 175 User Space : Translation / IBS : Network Ops 176 : Space : Space 177 : : 178 +----------+ : +----------+ +-----------+ : +-----------+ 179 Fulfill |recognize/|---> |translate/|-->| learn/ |-->| configure/| 180 |generate | | | | plan/ | | provision | 181 |intent |<--- | refine | | render | : | | 182 +----------+ : +----------+ +-----------+ : +-----------+ 183 : : 184 ......................................................................... 186 Slice Customer : Slice Provider 187 -------------- : -------------- 188 : 189 - Customized Slice : - Identification of IETF : - Slice request 190 Templates : network slice endpoints : to IETF NSC by 191 - Service SLOs as : and connectivity pattern : using slice 192 understood by : - Derivation of network SLOs : NBI YANG model 193 slice customer : and SLEs from high-level : 194 : Customer Service SLOs : 195 : : 197 Figure 1: Fulfillment phase of the Transport Slicing Intent 199 4. Mechanisms for translating IETF network slice intents 201 This section describes approaches for implementing mechanisms to 202 translate IETF network slice intents. As part of such translation it 203 could be necessary to translate the slice needs expressed by the 204 customer in terms of service-specific SLOs (e.g., high-resolution 205 real-time video quality) to network- or connectivity-specific SLOs 206 (e.g., a correspondent throughput and/or latency) which are the SLOs 207 an IETF Network Slice Controller understands. More on this can be 208 found in [TMV]. 210 4.1. Translation approaches and interaction with the upper systems 212 A suite of mechanisms will be required to allow instantiation of the 213 user's intent into a IETF network slice. In order to be able to 214 deliver an end2end Intent driven slice - a well defined set of 215 context aware attributes that allow unambiguous instantiation of the 216 intent should be agreed upon. A combination of a structured set of 217 attributes communicated between an IBN and an upper layer system with 218 user input would allow an IBN to have intent modeled and reason about 219 its completeness/validity. Translation approaches and interaction 220 with the upper systems might benefit from Natural Language Processing 221 (NLP) technics that are needed for enabling high level expression of 222 requirements found missing. The goal would be to identify and 223 classify the answers for as many fields as possible from the Generic 224 Slice Template (GST), based on the free text / speech provided by the 225 user. As it is highly unlikely that the minimum set of fields to 226 properly define an IETF network slice (geo-temporal characteristics, 227 performance characteristics, SLO and SLA properties) will be 228 fulfilled in this first step, a follow up two-step approach might 229 need to be implemented. 231 o The minimum missing fields from the GST have to be identified and 232 appropriate questions have to be generated (e.g. based on a pool 233 of available questions correlated with each field, or based on AI 234 approaches). 236 o An iterative interrogation phase will be initiated towards the 237 user using the previously generated questions, until the user 238 provides all the missing information, so the intent can be modeled 239 accordingly. 241 Interaction with the user and higher-up systems can potentially be 242 further improved by utilizing Machine Learning techniques. 244 4.2. Intent-based system suite 246 In order to consolidate on the set of devices, technologies and 247 resources to be used, a combination of deterministic or stochastic 248 computation approaches will be needed. Deterministic approaches will 249 rely on mathematical models and respective algorithms. Stochastic 250 approaches will rely on technologies like machine learning. Their 251 goal will be to learn from experience, so as to optimize future 252 decisions from the viewpoint of speed and reliability. The target of 253 learning will be related to the service behavior and to the 254 anticipated network status in the area and time period of the service 255 provision. 257 5. Security Considerations 259 To be done. 261 6. IANA Considerations 263 This draft does not include any IANA considerations 265 7. References 267 [GSMA] "Generic Network Slice Template, version 5.0", NG.116 , 268 June 2021. 270 [I-D.contreras-teas-slice-nbi] 271 Contreras, L. M., Homma, S., Ordonez-Lucena, J. A., 272 Tantsura, J., and K. Szarkowicz, "IETF Network Slice Use 273 Cases and Attributes for Northbound Interface of IETF 274 Network Slice Controllers", draft-contreras-teas-slice- 275 nbi-05 (work in progress), July 2021. 277 [I-D.ietf-teas-ietf-network-slices] 278 Farrel, A., Gray, E., Drake, J., Rokui, R., Homma, S., 279 Makhijani, K., Contreras, L. M., and J. Tantsura, 280 "Framework for IETF Network Slices", draft-ietf-teas-ietf- 281 network-slices-05 (work in progress), October 2021. 283 [I-D.irtf-nmrg-ibn-concepts-definitions] 284 Clemm, A., Ciavaglia, L., Granville, L. Z., and J. 285 Tantsura, "Intent-Based Networking - Concepts and 286 Definitions", draft-irtf-nmrg-ibn-concepts-definitions-06 287 (work in progress), December 2021. 289 [TMV] "Service performance measurement methods over 5G 290 experimental networks", 5G-PPP TMV , May 2021. 292 [TS28.541] 293 "TS 28.541 Management and orchestration; 5G Network 294 Resource Model (NRM); Stage 2 and stage 3 (Release 16) 295 V16.2.0.", 3GPP TS 28.541 V16.2.0 , September 2019. 297 Acknowledgments 299 This work has been partly funded by the European Commission through 300 the H2020 project 5G-EVE (Grant Agreement no. 815074). 302 Contributors 304 Kostas Tsagkaris, Kostas Trichias, Vassilis Foteinos, and Thanasis 305 Gkiolias (all from WINGS ICT Solutions) have also contributed to this 306 work. 308 Authors' Addresses 309 Luis M. Contreras 310 Telefonica 311 Ronda de la Comunicacion, s/n 312 Sur-3 building, 3rd floor 313 Madrid 28050 314 Spain 316 Email: luismiguel.contrerasmurillo@telefonica.com 317 URI: http://lmcontreras.com/ 319 Panagiotis Demestichas 320 WINGS ICT Solutions 321 Greece 323 Email: pdemest@wings-ict-solutions.eu 325 Jeff Tantsura 326 Microsoft 328 Email: jefftant.ietf@gmail.com