idnits 2.17.1 draft-zheng-ccamp-yang-otn-slicing-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 : ---------------------------------------------------------------------------- No issues found here. 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 1157 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 8453 == Outdated reference: A later version (-36) exists of draft-ietf-teas-yang-te-22 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 CCAMP Working Group Haomian Zheng 2 Internet Draft Italo Busi 3 Intended status: Standard Track Huawei Technologies 4 Aihua Guo 5 Futurewei Technologies 6 Victor Lopez 7 Telefonica I+D/GCTO 9 Expires: August 2021 February 22, 2021 11 Framework and Data Model for OTN Network Slicing 12 draft-zheng-ccamp-yang-otn-slicing-01 14 Abstract 16 The requirement of slicing network resource with desired quality of 17 service is emerging at every network technology, including the 18 Optical Transport Networks (OTN). As a part of the transport network, 19 OTN can provide hard pipes with guaranteed data isolation and 20 deterministic low latency, which are highly demanded in the Service 21 Level Agreement (SLA). 23 This document describes a framework for OTN network slicing and a 24 YANG data model augmentation of the OTN topology model. Additional 25 YANG data model augmentations will be defined in a future version of 26 this draft. 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), its areas, and its working groups. Note that 35 other groups may also distribute working documents as Internet- 36 Drafts. 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 The list of current Internet-Drafts can be accessed at 44 http://www.ietf.org/ietf/1id-abstracts.txt 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html 48 This Internet-Draft will expire on August 22, 2021. 50 Copyright Notice 52 Copyright (c) 2021 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction...................................................3 68 2. Use Cases for OTN Network Slicing..............................3 69 2.1. Leased Line Services with OTN.............................3 70 2.2. Co-construction and Sharing...............................3 71 2.3. Wholesale of optical resources............................4 72 2.4. Vertical dedicated network with OTN.......................4 73 3. Framework for OTN slicing......................................5 74 4. YANG Data Model for OTN Slicing Configuration..................7 75 4.1. OTN Slicing YANG Model for MPI............................7 76 4.1.1. MPI YANG Model Overview..............................7 77 4.1.2. MPI YANG Model Tree..................................7 78 4.1.3. MPI YANG Code........................................7 79 4.2. OTN Slicing YANG Model for OTN-SC NBI....................11 80 5. Manageability Considerations..................................11 81 6. Security Considerations.......................................11 82 7. IANA Considerations...........................................11 83 8. References....................................................12 84 8.1. Normative References.....................................12 85 8.2. Informative References...................................12 86 Acknowledgments..................................................12 87 Contributors' Addresses..........................................12 88 Authors' Addresses...............................................13 90 1. Introduction 92 The requirement of slicing network resource with desired quality of 93 service is emerging at every network technology, including the 94 Optical Transport Networks (OTN). As a part of the transport network, 95 OTN can provide hard pipes with guaranteed data isolation and 96 deterministic low latency, which are highly demanded in the Service 97 Level Agreement (SLA). 99 This document describes a framework for OTN network slicing and a 100 YANG data model augmentation of the OTN topology model. Additional 101 YANG data model augmentations will be defined in a future version of 102 this draft. 104 2. Use Cases for OTN Network Slicing 106 2.1. Leased Line Services with OTN 108 For end business customers (like OTT or enterprises), leased lines 109 have the advantage of providing high-speed connections with low 110 costs. On the other hand, the traffic control of leased lines is very 111 challenging due to rapid changes in service demands. Carriers are 112 recommended to provide network-level slicing capabilities to meet 113 this demand. Based on such capabilities, private network users have 114 full control over the sliced resources which have allocated to them 115 and which could be used to support their leased lines, when needed. 116 Users may formulate policies based on the demand for services and 117 time to schedule the resources from the entire network's perspective 118 flexibly. For example, the bandwidth between any two points may be 119 established or released based on the time or monitored traffic 120 characteristics. The routing and bandwidth may be adjusted at a 121 specific time interval to maximize network resource utilization 122 efficiency. 124 2.2. Co-construction and Sharing 126 Co-construction and sharing of a network are becoming a popular means 127 among service providers to reduce networking building CAPEX. For Co- 128 construction and sharing case, there are typically multiple co- 129 founders for the same network. For example, one founder may provide 130 optical fibres and another founder may provide OTN equipment, while 131 each occupies a certain percentage of the usage rights of the network 132 resources. In this scenario, the network O&M is performed by a 133 certain founder in each region, where the same founder usually 134 deploys an independent management and control system. The other 135 founders of the network use each other's management and control 136 system to provision services remotely. In this scenario, different 137 founders' network resources need to be automatically (associated) 138 divided, isolated, and visualized. In addition, all founders have 139 independent O&M capabilities, and should be able to perform service- 140 level provisioning in their respective slices. 142 2.3. Wholesale of optical resources 144 In the optical resource wholesale market, smaller, local carriers and 145 wireless carriers may rent resources from larger carriers, or 146 infrastructure carriers instead of building their networks. Likewise, 147 international carriers may rent resources from respective local 148 carriers and local carriers may lease their owned networks to each 149 other to achieve better network utilization efficiency. 151 From the perspective of a resource provider, it is crucial that a 152 network slice is timely configured to meet traffic matrix 153 requirements requested by its tenants. The support for multi-tenancy 154 within the resource provider's network demands that the network 155 slices are qualitatively isolated from each other to meet the 156 requirements for transparency, non-interference, and security. 158 Typically, a resource purchaser expects to use the leased network 159 resources flexibly, just like they are self-constructed. Therefore, 160 the purchaser is not only provided with a network slice, but also the 161 full set of functionalities for operating and maintaining the network 162 slice. The purchaser also expects to, in a flexible and independent 163 manner, schedule and maintain physical resources to support their own 164 end-to-end automation using both leased and self-constructed network 165 resources. 167 2.4. Vertical dedicated network with OTN 169 Vertical industry slicing is an emerging category of network slicing 170 due to the high demand for private high-speed network interconnects 171 for industrial applications. 173 In this scenario, the biggest challenge is to implement 174 differentiated optical network slices based on the requirements from 175 different industries. For example, in the financial industry, to 176 support high-frequency transactions, the slice must ensure to provide 177 the minimum latency along with the mechanism for latency management. 178 For the healthcare industry, online diagnosis network and software 179 capabilities to ensure the delivery of HD video without frame loss. 180 For bulk data migration in data centers, the network needs to support 181 on-demand, large-bandwidth allocation. In each of the aforementioned 182 vertical industry scenarios, the bandwidth shall be adjusted as 183 required to ensure flexible and efficient network resource usage. 185 3. Framework for OTN slicing 187 An OTN slice is a collection of OTN network resources that are used 188 to establish a logically dedicated OTN virtual network over one or 189 more OTN networks. For example, the bandwidth of an OTN slice is 190 described in terms of the number/type of OTN time slots; the labels 191 may be specified as OTN tributary slots and/or tributary ports to 192 allow slice users to interconnect devices with matching 193 specifications. 195 The relationship between an OTN slice and an IETF network slice [I-D. 196 teas-transport-network-slice-yang] is for further discussions. 198 To support the configuration of OTN slices, an OTN slice controller 199 (OTN-SC) can be deployed either outside or within the SDN controller. 201 In the former case, the OTN-SC translates an OTN slice configuration 202 request into a TE topology configuration or a set of TE tunnel 203 configurations, and instantiate it by using the TE topology [RFC8795] 204 or TE tunnel [I-D.ietf-teas-yang-te] interfaces at the MPI (MDSC-to- 205 PNC Interface), as defined in the ACTN framework [RFC8453]. 207 In the latter case, an Orchestrator or an end-to-end slice controller 208 may request OTN slices directly through the OTN slicing interface 209 provided by the OTN-SC. A higher-level OTN-SC may also designate the 210 creation of OTN slices to a lower-level OTN-SC in a recursive manner. 212 Figure 1 illustrates the OTN slicing control hierarchy and the 213 positioning of the OTN slicing interfaces. 215 +--------------------+ 216 | Provider's User | 217 +--------|-----------+ 218 |CMI 219 +----------------------+---------------------------+ 220 | Orchestrator / E2E Slice Controller | 221 +-----------+------------------------------+-------+ 222 |OTN-SC NBI | 223 | | 224 +-----------+---------+ OTN-SC NBI |OTN-SC NBI 225 | OTN-SC +---------------+ | 226 +-----------+---------+ | | 227 |MPI | | 228 +------------|-------------------------|----|--------+ 229 | SDN | +-------+----+-------+| 230 | Controller | | OTN-SC || 231 | | +-------+------------+| 232 | | |Internal API | 233 |+-----------+-------------------------+------------+| 234 || PNC/MDSC || 235 |+-----------------------+--------------------------+| 236 +------------------------|---------------------------+ 237 |SBI 238 +-----------+----------+ 239 |OTN Physical Network | 240 +----------------------+ 242 Figure 1 - Positioning of OTN Slicing Interfaces 244 A particular OTN network resource, such as a port or link, may be 245 sliced in two modes: 247 o Link-based slicing, where a link and its associated link 248 termination points (LTPs) are dedicatedly allocated to a 249 particular OTN network slice. 251 o Tributary-slot based slicing, where multiple OTN network slices 252 share the same link by allocating different OTN tributary slots in 253 different granularities. 255 Additionally, since OTN tributary slots are usually switched 256 unconstrained at every node within an OTN network, it is unimportant 257 to which exact tributary slot(s) an OTN slice is allocated, but 258 rather mattered is the number and type of the tributary slots. 260 4. YANG Data Model for OTN Slicing Configuration 262 4.1. OTN Slicing YANG Model for MPI 264 4.1.1. MPI YANG Model Overview 266 An SDN controller (PNC or MDSC) exposes to the OTN-SC set of 267 available resources for OTN slicing in the form of an abstract TE 268 topology. When the OTN-SC receives slice configuration from the NBI, 269 it translates the configuration into a coloring scheme on the 270 abstract TE topology, by marking corresponding link resources on the 271 TE topology received from the SDN controller with a slice identifier 272 and OTN-specific resource requirements, e.g. the number of ODU time 273 slots. When the SDN controller receives the slice configuration, it 274 shall create a new virtual TE link for each of the colored links to 275 hold the reserved OTN time slots for time slot-based slicing. These 276 resultant virtual links are then included in the TE topology 277 advertisement to the OTN-SC. 279 4.1.2. MPI YANG Model Tree 281 module: ietf-otn-slice 282 augment /nw:networks/nw:network/nt:link/tet:te/tet:te-link- 283 attributes: 284 +--rw (otn-slice-granularity)? 285 +--:(link) 286 | +--rw slice-id? uint32 287 +--:(link-resource) 288 +--rw slices* [slice-id] 289 +--rw slice-id uint32 290 +--rw (technology)? 291 | +--:(otn) 292 | +--rw otn-ts-num? uint32 293 +--ro sliced-link-ref? -> 294 ../../../../../nt:link/link-id 296 Figure 2 - OTN network slicing tree diagram 298 4.1.3. MPI YANG Code 300 file "ietf-otn-slice@2021-02-22.yang" 301 module ietf-otn-slice { 302 yang-version 1.1; 303 namespace "urn:ietf:params:xml:ns:yang:ietf-otn-slice"; 304 prefix "otnslice"; 306 import ietf-network { 307 prefix "nw"; 308 reference "RFC 8345: A YANG Data Model for Network Topologies"; 309 } 311 import ietf-network-topology { 312 prefix "nt"; 313 reference "RFC 8345: A YANG Data Model for Network Topologies"; 314 } 316 import ietf-te-topology { 317 prefix "tet"; 318 reference 319 "RFC8795: YANG Data Model for Traffic Engineering 320 (TE) Topologies"; 321 } 323 import ietf-otn-topology { 324 prefix "otntopo"; 325 reference 326 "I-D.ietf-ccamp-otn-topo-yang: A YANG Data Model 327 for Optical Transport Network Topology"; 328 } 330 organization 331 "IETF CCAMP Working Group"; 332 contact 333 "WG Web: 334 WG List: 336 Editor: Haomian Zheng 337 339 Editor: Italo Busi 340 342 Editor: Aihua Guo 343 345 Editor: Victor Lopez 346 "; 348 description 349 "This module defines a YANG data model to configure an OTN 350 network slice realization. 352 The model fully conforms to the Network Management Datastore 353 Architecture (NMDA). 355 Copyright (c) 2021 IETF Trust and the persons 356 identified as authors of the code. All rights reserved. 358 Redistribution and use in source and binary forms, with or 359 without modification, is permitted pursuant to, and subject 360 to the license terms contained in, the Simplified BSD License 361 set forth in Section 4.c of the IETF Trust's Legal Provisions 362 Relating to IETF Documents 363 (https://trustee.ietf.org/license-info). 364 This version of this YANG module is part of RFC XXXX; see 365 the RFC itself for full legal notices."; 367 revision "2021-02-22" { 368 description 369 "Initial Version"; 370 reference 371 "draft-zheng-ccamp-yang-otn-slicing-01: Framework and Data 372 Model for OTN Network Slicing"; 373 } 375 /* 376 * Groupings 377 */ 379 grouping otn-link-slice-profile { 380 choice otn-slice-granularity { 381 default link; 382 case link { 383 leaf slice-id { 384 type uint32; 385 description 386 "Slice identifier"; 387 } 388 } 389 case link-resource { 390 list slices { 391 key slice-id; 392 description 393 "List of slices."; 394 leaf slice-id { 395 type uint32; 396 description 397 "Slice identifier"; 398 } 399 choice technology { 400 case otn { 401 leaf otn-ts-num { 402 type uint32; 403 description 404 "Number of OTN tributary slots allocated for the 405 slice."; 406 } 407 } 408 } 409 leaf sliced-link-ref { 410 config false; 411 type leafref { 412 path "../../../../../nt:link/nt:link-id"; 413 } 414 description 415 "Relative reference to virtual links generated from 416 this TE link."; 417 } 418 } 419 } 420 } 421 } 423 /* 424 * Augments 425 */ 427 augment "/nw:networks/nw:network/nt:link/tet:te/" 428 + "tet:te-link-attributes" { 429 when "../../../nw:network-types/tet:te-topology/" 430 + "otntopo:otn-topology" { 431 description 432 "Augmentation parameters apply only for networks with 433 OTN topology type."; 434 } 435 description 436 "Augment OTN TE link attributes with slicing profile."; 437 uses otn-link-slice-profile; 438 } 439 } 440 442 Figure 3 - OTN network slicing YANG model 444 4.2. OTN Slicing YANG Model for OTN-SC NBI 446 TBD. 448 5. Manageability Considerations 450 To ensure the security and controllability of physical resource 451 isolation, slice-based independent operation and management are 452 required to achieve management isolation. 454 Each optical slice typically requires dedicated accounts, 455 permissions, and resources for independent access and O&M. This 456 mechanism is to guarantee the information isolation among slice 457 tenants and to avoid resource conflicts. The access to slice 458 management functions will only be permitted after successful security 459 checks. 461 6. Security Considerations 463 465 7. IANA Considerations 467 469 8. References 471 8.1. Normative References 473 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for 474 Abstraction and Control of TE Networks (ACTN)", RFC 8453, 475 DOI 10.17487/RFC8453, August 2018 . 478 [RFC8795] Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and 479 O. Gonzalez de Dios, "YANG Data Model for Traffic 480 Engineering (TE) Topologies", RFC 8795, DOI 481 10.17487/RFC8795, August 2020, . 484 [I-D. teas-transport-network-slice-yang] Liu, X., Tantsura J., 485 Bryskin I., Contreras L., Wu Q., Belotti S., and Rokui R., 486 "Transport Network Slice YANG Data Model", draft-liu-teas- 487 transport-network-slice-yang-01 (work in progress), July 488 2020. 490 [I-D.ietf-teas-yang-te] Saad, T., Gandhi, R., Liu, X., Beeram, V., 491 and I. Bryskin, "A YANG Data Model for Traffic Engineering 492 Tunnels and Interfaces", draft-ietf-teas-yang-te-22 (work 493 in progress), November 2019. 495 8.2. Informative References 497 TBD 499 Acknowledgments 501 This document was prepared using 2-Word-v2.0.template.dot. 503 Contributors' Addresses 505 Henry Yu 506 Huawei Technologies Canada 508 Email: henry.yu@huawei.com 510 Authors' Addresses 512 Haomian Zheng 513 Huawei Technologies 514 H1, Xiliu Beipo Village, Songshan Lake, 515 Dongguan, 516 China 518 Email: zhenghaomian@huawei.com 520 Italo Busi 521 Huawei Technologies 523 Email: italo.busi@huawei.com 525 Aihua Guo 526 Futurewei Technologies 528 Email: aihuaguo.ietf@gmail.com 530 Victor Lopez 531 Telefonica I+D/GCTO 532 Distrito Telefonica 533 E-28050 Madrid, Spain 535 Email: victor.lopezalvarez@telefonica.com