idnits 2.17.00 (12 Aug 2021) /tmp/idnits20389/draft-contreras-teas-slice-controller-models-01.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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 22, 2021) is 453 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-09) exists of draft-ietf-teas-actn-yang-06 == Outdated reference: A later version (-05) exists of draft-liu-teas-transport-network-slice-yang-02 == Outdated reference: A later version (-05) exists of draft-nsdt-teas-ns-framework-04 == Outdated reference: A later version (-05) exists of draft-wd-teas-ietf-network-slice-nbi-yang-01 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TEAS LM. Contreras 3 Internet-Draft Telefonica 4 Intended status: Informational R. Rokui 5 Expires: August 26, 2021 Nokia 6 J. Tantsura 7 Apstra 8 B. Wu 9 Huawei 10 X. Liu 11 Volta 12 D. Dhody 13 Huawei 14 S. Belloti 15 Nokia 16 February 22, 2021 18 IETF Network Slice Controller and its associated data models 19 draft-contreras-teas-slice-controller-models-01 21 Abstract 23 This document describes the major functional components of an IETF 24 Network Slice Controller (NSC) as well as references the data models 25 required for supporting the requests of IETF network slices and their 26 realization. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on August 26, 2021. 45 Copyright Notice 47 Copyright (c) 2021 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. IETF Network Slice data models . . . . . . . . . . . . . . . 3 64 3. Structure of the IETF Network Slice Controller (NSC) . . . . 4 65 3.1. NS Mapper . . . . . . . . . . . . . . . . . . . . . . . . 7 66 3.2. NS Realizer . . . . . . . . . . . . . . . . . . . . . . . 7 67 4. Model types in IETF Network Slice Controller interfaces . . . 7 68 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 69 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 70 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 73 1. Introduction 75 Editor's Note: the terminology in this draft will be aligned with the 76 final terminology selected for describing the notion of IETF Network 77 Slice when applied to IETF technologies, which is currently under 78 discussion. By now same terminology as used in 79 [I-D.nsdt-teas-ietf-network-slice-definition] and 80 [I-D.nsdt-teas-ns-framework] is primarily used here. Consensus to 81 use "IETF Network Slice" term has been reached. 83 The generic idea of network slicing intends to provide tailored end- 84 to-end network capabilities to customers in the way that they could 85 be perceived as a dedicated network, despite the fact that it makes 86 use of shared physical infrastructure facilities. 88 Among the capabilities mentioned, connectivity of different parts of 89 a network slice with particular characteristics play a central role. 90 Thus, the concept of IETF Network Slice, realized by any of the IETF 91 technologies, emerges as complementary but essential part of an end- 92 to-end network slice. 94 In order to facilitate the request, realization and lifecycle control 95 and management of a transport slice, a new element named IETF Network 96 Slice Controller (NSC) is being proposed in 97 [I-D.nsdt-teas-ietf-network-slice-definition] and 98 [I-D.nsdt-teas-ns-framework]. 100 The NSC from its North Bound Interface (NBI) exposes set of APIs that 101 allow a higher level system to request an end-to-end transport slice. 102 It receives the request of enablement of an IETF Network Slice by a 103 customer (i.e. creation, modification or deletion). Upon receiving a 104 request from its NBI, NSC finds the resources needed for realization 105 of the IETF Network Slice and in turn interfaces from its South Bound 106 Interface (SBI) with one or more Network Controllers for the 107 realization of the requested IETF Network Slice request and the 108 management of its lifecycle. Figure 1 presents a high-level view of 109 the TSC. 111 +------------------------------------------+ 112 | A higher level system | 113 | (e.g E2E network slice orchestrator) | 114 +------------------------------------------+ 115 A 116 | NSC NBI 117 V 118 +------------------------------------------+ 119 | IETF Network Slice Controller (NSC) | 120 +------------------------------------------+ 121 A 122 | NSC SBI 123 V 124 +------------------------------------------+ 125 | Network Controller(s) | 126 +------------------------------------------+ 128 Figure 1: Interface of Transport Slice Controller 130 This memo describes the characteristics of the NSC as well as a 131 detailed structure of the NSC and its major components. In addition, 132 it describes the characteristics of the data models to identify the 133 IETF Network Slice and its realization. Then the data models 134 referred are mapped to the interfaces among components. 136 2. IETF Network Slice data models 138 At the time of provisioning and operating IETF Network Slices 139 different views can be identified as necessary: 141 o Customer's view, mostly focused on the individual IETF Network 142 Slice request process, reflecting the needs of each particular 143 customer, including SLOs and other characteristics of the slice 144 relevant for it. This view is technology agnostics and describes 145 the characteristics of the IETF Network Slice from a customer's 146 point of view. It can include the slice topology, performance 147 parameters, endpoints of the slice, traffic characteristics of the 148 slice, and the KPIs to monitor the slice. 150 o Provider's view, mostly focused on the provisioning and operation 151 of the IETF Network Slices in the transport network, considering 152 how a particular IETF Network Slice interplays with other IETF 153 Network Slices maintained by the provider on a shared 154 infrastructure. In other words, operator's view shows how an IETF 155 Network Slice is realized in operator's network along with all the 156 resources used during the its realization. 158 Both views are complementary, each of them specialized for a given 159 purpose. In consequence, it should be consistency between both in 160 order to ensure alignment. 162 Currently there are two different models proposed, on for each of the 163 categories above. The model in 164 [I-D.wd-teas-ietf-network-slice-nbi-yang] fits into the customer 165 view, while the model defined in 166 [I-D.liu-teas-transport-network-slice-yang] fits in to the provider 167 view. 169 It should be noted that for the realization of a transport slice, the 170 NSC interacts with one or more Network Controllers. In that case, 171 the data models to be used are particular for each Network Controller 172 (e.g., technology dependent), as well as the mapping function from 173 its NBI to SBI and the details of this mapping function are both out 174 of the scope of this document. 176 3. Structure of the IETF Network Slice Controller (NSC) 178 The NSC should work with both data models. The NSC takes first the 179 customer's view by analyzing the needs of the customer, processing 180 such requests taking into account the overall view of the network and 181 the IETF Network Slices already instantiated, normalizing its 182 instantiation across different technologies, and finally generates 183 the provider view. 185 Once the new request is processed and declared as feasible, the NSC 186 triggers its realization by interacting with the Network Controllers 187 and communicates back to the higher level controller to start the 188 billing cycle. 190 In order to accommodate these procedures, the internal structure of 191 the NSC can be divided into: 193 o IETF Network Slice Mapper: this high-level component processes the 194 customer request, putting it into the context of the overall IETF 195 Network Slices in the network. 197 o IETF Network Slice Realizer: this high-level component processes 198 the complete view of transport slices including the one requested 199 by the customer, decides the proper technologies for realizing the 200 IETF Network Slice and triggers its realization. 202 Figure 2 illustrates the components described and the associated 203 models, as follows 205 o (a) -> customer's view, e.g. 206 [I-D.wd-teas-ietf-network-slice-nbi-yang]. 208 o (b) -> provider's view, e.g. 209 [I-D.liu-teas-transport-network-slice-yang]. 211 o (c) -> models per network controller, out of scope of this 212 document 213 Higher Level System 214 | 215 | 216 --------------------------- 217 | NSC | (a) | 218 | v | 219 | ------------------- | 220 | | | | 221 | | NS Mapper | | 222 | | | | 223 | ------------------- | 224 | | (b) | 225 | v | 226 | ------------------- | 227 | | | | 228 | | NS Realizer | | 229 | | | | 230 | ------------------- | 231 | | (c) | 232 --------------------------- 233 | 234 v 235 Network Controllers 237 Figure 2: IETF Network Slice Controller structure and asspociated 238 data models 240 IETF Network Slices with different level of detail could be 241 requested: 243 o The IETF network slice can be abstracted as a set of edge-to-edge 244 links (Type 1). 246 o The IETF network slice can be abstracted as a topology of virtual 247 nodes and virtual links (Type 2) which represent the partitioning 248 of underlay network resources for use by network slice 249 connectivity. 251 The use cases of these two types of networks are further described by 252 [RFC8453]. [I-D.wd-teas-ietf-network-slice-nbi-yang] models the Type 253 1 service, while [I-D.liu-teas-transport-network-slice-yang] models 254 the Type 2 service. When a customer intends to request a Type 2 255 service, [I-D.liu-teas-transport-network-slice-yang] can also be used 256 at the point (a) in Figure 2. As an example, when ACTN is used to 257 realize an IETF network slice, model mappings are described in more 258 details in [I-D.ietf-teas-actn-yang]. 260 3.1. NS Mapper 262 The Mapper will receive the IETF Network Slice request from the 263 customer. It will process it obtaining an overall view of how this 264 new request complements or fits with the rest of IETF Network Slices, 265 if any, as provisioned in the network. As part of that processing, a 266 single customer IETF Network Slice request could result in the need 267 of actually provisioning different IETF Network Slices in the 268 network. The Mapper will maintain the relationship among customer 269 IETF Network Slice request and provisioned IETF Network Slices. 271 3.2. NS Realizer 273 The Realizer will receive from the Mapper one or more requests for 274 provision of IETF Network Slices, potentially including some 275 technology-specific information. With that information, the Realizer 276 will determine the realization of each particular IETF Network Slice 277 interacting with technology-specific Network Controllers. 279 4. Model types in IETF Network Slice Controller interfaces 281 Both [RFC8309] and [RFC8969] offer a complete view of customer, 282 service and network model types. In this sense a potential mapping 283 of models to IETF Network Slcie Controller interfaces is as follows: 285 o NBI of the IETF NSC (interface (a) in Figure 2) -> Customer 286 service model. According to [RFC8309] "a customer's service 287 request is (or should be) technology agnostic. That is, a 288 customer is unaware of the technology that the network operator 289 has available to deliver the service, so the customer does not 290 make requests specific to the underlying technology but is limited 291 to making requests specific to the service that is to be 292 delivered". This definition matches the expected behavior of the 293 IETF NSC NBI as considered in in 294 [I-D.nsdt-teas-ietf-network-slice-definition] and 295 [I-D.nsdt-teas-ns-framework]. 297 o Interface between NS Mapper and NS Realizer (interface (b) in 298 Figure 2) -> Service Delivery model. According to [RFC8309] "a 299 service delivery module is expressed as a core set of parameters 300 that are common across a network type and technology [...] Service 301 delivery modules include technology-specific modules.". 302 Furthermore, [RFC8969] (in its Figures 3 and 5) considers L3SM or 303 VN Service models to be later on fed into a controller. 305 o SBI of the IETF NSC (interface (c) in Figure 2) -> Network 306 Configuration model. According to [RFC8309] "the orchestrator 307 must map the service request to its view, and this mapping may 308 include a choice of which networks and technologies to use 309 depending on which service features have been requested". This is 310 coincideent with the expected behavior of the IETF NSC SBI as 311 considered in in [I-D.nsdt-teas-ietf-network-slice-definition] and 312 [I-D.nsdt-teas-ns-framework]. 314 5. Security Considerations 316 To be done. 318 6. IANA Considerations 320 This draft does not include any IANA considerations 322 7. References 324 [I-D.ietf-teas-actn-yang] 325 Lee, Y., Zheng, H., Ceccarelli, D., Yoon, B., Dios, O., 326 Shin, J., and S. Belotti, "Applicability of YANG models 327 for Abstraction and Control of Traffic Engineered 328 Networks", draft-ietf-teas-actn-yang-06 (work in 329 progress), August 2020. 331 [I-D.liu-teas-transport-network-slice-yang] 332 Liu, X., Tantsura, J., Bryskin, I., Contreras, L., WU, Q., 333 Belotti, S., and R. Rokui, "IETF Network Slice YANG Data 334 Model", draft-liu-teas-transport-network-slice-yang-02 335 (work in progress), November 2020. 337 [I-D.nsdt-teas-ietf-network-slice-definition] 338 Rokui, R., Homma, S., Makhijani, K., Contreras, L., and J. 339 Tantsura, "Definition of IETF Network Slices", draft-nsdt- 340 teas-ietf-network-slice-definition-02 (work in progress), 341 December 2020. 343 [I-D.nsdt-teas-ns-framework] 344 Gray, E. and J. Drake, "Framework for Transport Network 345 Slices", draft-nsdt-teas-ns-framework-04 (work in 346 progress), July 2020. 348 [I-D.wd-teas-ietf-network-slice-nbi-yang] 349 Bo, W., Dhody, D., Han, L., and R. Rokui, "A Yang Data 350 Model for IETF Network Slice NBI", draft-wd-teas-ietf- 351 network-slice-nbi-yang-01 (work in progress), November 352 2020. 354 [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models 355 Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, 356 . 358 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for 359 Abstraction and Control of TE Networks (ACTN)", RFC 8453, 360 DOI 10.17487/RFC8453, August 2018, 361 . 363 [RFC8969] Wu, Q., Ed., Boucadair, M., Ed., Lopez, D., Xie, C., and 364 L. Geng, "A Framework for Automating Service and Network 365 Management with YANG", RFC 8969, DOI 10.17487/RFC8969, 366 January 2021, . 368 Authors' Addresses 370 Luis M. Contreras 371 Telefonica 372 Ronda de la Comunicacion, s/n 373 Sur-3 building, 3rd floor 374 Madrid 28050 375 Spain 377 Email: luismiguel.contrerasmurillo@telefonica.com 378 URI: http://lmcontreras.com/ 380 Reza Rokui 381 Nokia 382 Canada 384 Email: reza.rokui@nokia.com 386 Jeff Tantsura 387 Apstra 388 USA 390 Email: jefftant.ietf@gmail.com 392 Bo Wu 393 Huawei Technologies 394 101 Software Avenue, Yuhua District 395 Nanjing, Jiangsu 210012 396 China 398 Email: lana.wubo@huawei.com 399 Xufeng Liu 400 Volta Networks 402 Email: xufeng.liu.ietf@gmail.com 404 Dhruv Dhody 405 Huawei Technologies 406 Divyashree Techno Park 407 Bangalore, Karnataka 560066 408 India 410 Email: dhruv.ietf@gmail.com 412 Sergio Belloti 413 Nokia 415 Email: sergio.belotti@nokia.com