idnits 2.17.1 draft-contreras-teas-slice-controller-models-02.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 (March 6, 2022) is 780 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-06) exists of draft-ietf-ccamp-yang-otn-slicing-01 == Outdated reference: A later version (-11) exists of draft-ietf-teas-actn-yang-08 == Outdated reference: A later version (-09) exists of draft-liu-teas-transport-network-slice-yang-04 Summary: 1 error (**), 0 flaws (~~), 4 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: September 7, 2022 Ciena 6 J. Tantsura 7 Microsoft 8 B. Wu 9 Huawei 10 X. Liu 11 IBM Corporation 12 D. Dhody 13 Huawei 14 S. Belloti 15 Nokia 16 March 6, 2022 18 IETF Network Slice Controller and its associated data models 19 draft-contreras-teas-slice-controller-models-02 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 September 7, 2022. 45 Copyright Notice 47 Copyright (c) 2022 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, including more detailed but yet 209 technology-agnostic resource view as e.g. 210 [I-D.liu-teas-transport-network-slice-yang], and/or alternative 211 technology-specific augmentations as e.g. 212 [I-D.ietf-ccamp-yang-otn-slicing]. 214 o (c) -> models per network controller, out of scope of this 215 document 216 Higher Level System 217 | 218 | 219 --------------------------- 220 | NSC | (a) | 221 | v | 222 | ------------------- | 223 | | | | 224 | | NS Mapper | | 225 | | | | 226 | ------------------- | 227 | | (b) | 228 | v | 229 | ------------------- | 230 | | | | 231 | | NS Realizer | | 232 | | | | 233 | ------------------- | 234 | | (c) | 235 --------------------------- 236 | 237 v 238 Network Controllers 240 Figure 2: IETF Network Slice Controller structure and asspociated 241 data models 243 IETF Network Slices with different level of detail could be 244 requested: 246 o The IETF network slice can be abstracted as a set of edge-to-edge 247 links (Type 1). 249 o The IETF network slice can be abstracted as a topology of virtual 250 nodes and virtual links (Type 2) which represent the partitioning 251 of underlay network resources for use by network slice 252 connectivity. 254 The use cases of these two types of networks are further described by 255 [RFC8453]. [I-D.wd-teas-ietf-network-slice-nbi-yang] models the Type 256 1 service, while [I-D.liu-teas-transport-network-slice-yang] models 257 the Type 2 service. When a customer intends to request a Type 2 258 service, [I-D.liu-teas-transport-network-slice-yang] can also be used 259 at the point (a) in Figure 2. As an example, when ACTN is used to 260 realize an IETF network slice, model mappings are described in more 261 details in [I-D.ietf-teas-actn-yang]. 263 3.1. NS Mapper 265 The Mapper will receive the IETF Network Slice request from the 266 customer. It will process it obtaining an overall view of how this 267 new request complements or fits with the rest of IETF Network Slices, 268 if any, as provisioned in the network. As part of that processing, a 269 single customer IETF Network Slice request could result in the need 270 of actually provisioning different IETF Network Slices in the 271 network. The Mapper will maintain the relationship among customer 272 IETF Network Slice request and provisioned IETF Network Slices. 274 3.2. NS Realizer 276 The Realizer will receive from the Mapper one or more requests for 277 provision of IETF Network Slices, potentially including some 278 technology-specific information. With that information, the Realizer 279 will determine the realization of each particular IETF Network Slice 280 interacting with technology-specific Network Controllers. 282 4. Model types in IETF Network Slice Controller interfaces 284 Both [RFC8309] and [RFC8969] offer a complete view of customer, 285 service and network model types. In this sense a potential mapping 286 of models to IETF Network Slcie Controller interfaces is as follows: 288 o NBI of the IETF NSC (interface (a) in Figure 2) -> Customer 289 service model. According to [RFC8309] "a customer's service 290 request is (or should be) technology agnostic. That is, a 291 customer is unaware of the technology that the network operator 292 has available to deliver the service, so the customer does not 293 make requests specific to the underlying technology but is limited 294 to making requests specific to the service that is to be 295 delivered". This definition matches the expected behavior of the 296 IETF NSC NBI as considered in in 297 [I-D.nsdt-teas-ietf-network-slice-definition] and 298 [I-D.nsdt-teas-ns-framework]. 300 o Interface between NS Mapper and NS Realizer (interface (b) in 301 Figure 2) -> Service Delivery model. According to [RFC8309] "a 302 service delivery module is expressed as a core set of parameters 303 that are common across a network type and technology [...] Service 304 delivery modules include technology-specific modules.". 305 Furthermore, [RFC8969] (in its Figures 3 and 5) considers L3SM or 306 VN Service models to be later on fed into a controller. 308 o SBI of the IETF NSC (interface (c) in Figure 2) -> Network 309 Configuration model. According to [RFC8309] "the orchestrator 310 must map the service request to its view, and this mapping may 311 include a choice of which networks and technologies to use 312 depending on which service features have been requested". This is 313 coincideent with the expected behavior of the IETF NSC SBI as 314 considered in in [I-D.nsdt-teas-ietf-network-slice-definition] and 315 [I-D.nsdt-teas-ns-framework]. 317 5. Security Considerations 319 To be done. 321 6. IANA Considerations 323 This draft does not include any IANA considerations 325 7. References 327 [I-D.ietf-ccamp-yang-otn-slicing] 328 Guo, A., Contreras, L. M., Belotti, S., Rokui, R., Xu, Y., 329 Zhao, Y., and X. Liu, "Framework and Data Model for OTN 330 Network Slicing", draft-ietf-ccamp-yang-otn-slicing-01 331 (work in progress), March 2022. 333 [I-D.ietf-teas-actn-yang] 334 Lee, Y., Zheng, H., Ceccarelli, D., Yoon, B. Y., and S. 335 Belotti, "Applicability of YANG models for Abstraction and 336 Control of Traffic Engineered Networks", draft-ietf-teas- 337 actn-yang-08 (work in progress), September 2021. 339 [I-D.liu-teas-transport-network-slice-yang] 340 Liu, X., Tantsura, J., Bryskin, I., Contreras, L. M., Wu, 341 Q., Belotti, S., and R. Rokui, "IETF Network Slice YANG 342 Data Model", draft-liu-teas-transport-network-slice- 343 yang-04 (work in progress), July 2021. 345 [I-D.nsdt-teas-ietf-network-slice-definition] 346 Rokui, R., Homma, S., Makhijani, K., Contreras, L. M., and 347 J. Tantsura, "Definition of IETF Network Slices", draft- 348 nsdt-teas-ietf-network-slice-definition-02 (work in 349 progress), December 2020. 351 [I-D.nsdt-teas-ns-framework] 352 Gray, E. and J. Drake, "Framework for IETF Network 353 Slices", draft-nsdt-teas-ns-framework-05 (work in 354 progress), February 2021. 356 [I-D.wd-teas-ietf-network-slice-nbi-yang] 357 Wu, B., Dhody, D., Rokui, R., Saad, T., Han, L., and L. M. 358 Contreras, "IETF Network Slice Service YANG Model", draft- 359 wd-teas-ietf-network-slice-nbi-yang-05 (work in progress), 360 September 2021. 362 [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models 363 Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, 364 . 366 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for 367 Abstraction and Control of TE Networks (ACTN)", RFC 8453, 368 DOI 10.17487/RFC8453, August 2018, 369 . 371 [RFC8969] Wu, Q., Ed., Boucadair, M., Ed., Lopez, D., Xie, C., and 372 L. Geng, "A Framework for Automating Service and Network 373 Management with YANG", RFC 8969, DOI 10.17487/RFC8969, 374 January 2021, . 376 Authors' Addresses 378 Luis M. Contreras 379 Telefonica 380 Ronda de la Comunicacion, s/n 381 Sur-3 building, 3rd floor 382 Madrid 28050 383 Spain 385 Email: luismiguel.contrerasmurillo@telefonica.com 386 URI: http://lmcontreras.com/ 388 Reza Rokui 389 Ciena 390 Canada 392 Email: rrokui@ciena.com 394 Jeff Tantsura 395 Microsoft 396 USA 398 Email: jefftant.ietf@gmail.com 399 Bo Wu 400 Huawei Technologies 401 101 Software Avenue, Yuhua District 402 Nanjing, Jiangsu 210012 403 China 405 Email: lana.wubo@huawei.com 407 Xufeng Liu 408 IBM Corporation 410 Email: xufeng.liu.ietf@gmail.com 412 Dhruv Dhody 413 Huawei Technologies 414 Divyashree Techno Park 415 Bangalore, Karnataka 560066 416 India 418 Email: dhruv.ietf@gmail.com 420 Sergio Belloti 421 Nokia 423 Email: sergio.belotti@nokia.com