idnits 2.17.1 draft-zheng-ccamp-yang-otn-slicing-03.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 : ---------------------------------------------------------------------------- ** There are 20 instances of too long lines in the document, the longest one being 12 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 444 has weird spacing: '...du-type ide...' == Line 672 has weird spacing: '...oint-id str...' == Line 675 has weird spacing: '...logy-id str...' == Line 697 has weird spacing: '...trix-id uin...' == Line 705 has weird spacing: '...w tp-id lea...' -- The document date (22 October 2021) is 916 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) == Outdated reference: A later version (-36) exists of draft-ietf-teas-yang-te-27 == Outdated reference: A later version (-25) exists of draft-ietf-teas-ietf-network-slices-04 Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CCAMP Working Group H. Zheng 3 Internet-Draft I. Busi 4 Intended status: Standards Track Huawei Technologies 5 Expires: 25 April 2022 A. Guo 6 Futurewei Technologies 7 L.M. Contreras 8 O.G.d. Dios 9 Telefonica 10 V. Lopez 11 S. Belotti 12 D. Beller 13 R. Rokui 14 Nokia 15 Y. Xu 16 CAICT 17 Y. Zhao 18 China Mobile 19 X. Liu 20 Volta Networks 21 22 October 2021 23 Framework and Data Model for OTN Network Slicing 24 draft-zheng-ccamp-yang-otn-slicing-03 26 Abstract 28 The requirement of slicing network resources with desired quality of 29 service is emerging at every network technology, including the 30 Optical Transport Networks (OTN). As a part of the transport 31 network, OTN can provide hard pipes with guaranteed data isolation 32 and deterministic low latency, which are highly demanded in the 33 Service Level Agreement (SLA). 35 This document describes a framework for OTN network slicing and a 36 YANG data model augmentation of the OTN topology model. Additional 37 YANG data model augmentations will be defined in a future version of 38 this draft. 40 Status of This Memo 42 This Internet-Draft is submitted in full conformance with the 43 provisions of BCP 78 and BCP 79. 45 Internet-Drafts are working documents of the Internet Engineering 46 Task Force (IETF). Note that other groups may also distribute 47 working documents as Internet-Drafts. The list of current Internet- 48 Drafts is at https://datatracker.ietf.org/drafts/current/. 50 Internet-Drafts are draft documents valid for a maximum of six months 51 and may be updated, replaced, or obsoleted by other documents at any 52 time. It is inappropriate to use Internet-Drafts as reference 53 material or to cite them other than as "work in progress." 55 This Internet-Draft will expire on 25 April 2022. 57 Copyright Notice 59 Copyright (c) 2021 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 64 license-info) in effect on the date of publication of this document. 65 Please review these documents carefully, as they describe your rights 66 and restrictions with respect to this document. Code Components 67 extracted from this document must include Simplified BSD License text 68 as described in Section 4.e of the Trust Legal Provisions and are 69 provided without warranty as described in the Simplified BSD License. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 74 1.1. Definition of OTN Slice . . . . . . . . . . . . . . . . . 3 75 2. Use Cases for OTN Network Slicing . . . . . . . . . . . . . . 4 76 2.1. Leased Line Services with OTN . . . . . . . . . . . . . . 4 77 2.2. Co-construction and Sharing . . . . . . . . . . . . . . . 5 78 2.3. Wholesale of optical resources . . . . . . . . . . . . . 5 79 2.4. Vertical dedicated network with OTN . . . . . . . . . . . 5 80 2.5. End-to-end network slicing . . . . . . . . . . . . . . . 6 81 3. Framework for OTN slicing . . . . . . . . . . . . . . . . . . 6 82 4. YANG Data Model for OTN Slicing Configuration . . . . . . . . 9 83 4.1. OTN Slicing YANG Model for MPI . . . . . . . . . . . . . 9 84 4.1.1. MPI YANG Model Overview . . . . . . . . . . . . . . . 9 85 4.1.2. MPI YANG Model Tree . . . . . . . . . . . . . . . . . 10 86 4.1.3. MPI YANG Code . . . . . . . . . . . . . . . . . . . . 10 87 4.2. OTN Slicing YANG Model for OTN-SC NBI . . . . . . . . . . 14 88 4.2.1. NBI YANG Model Overview . . . . . . . . . . . . . . . 14 89 4.2.2. NBI YANG Model Tree for Transport Network Slice . . . 14 90 4.2.3. NBI YANG Code for Transport Network Slice . . . . . . 15 91 4.2.4. NBI YANG Model Tree for OTN slice . . . . . . . . . . 26 92 4.2.5. NBI YANG Code for OTN Slice . . . . . . . . . . . . . 26 93 5. Manageability Considerations . . . . . . . . . . . . . . . . 26 94 6. Security Considerations . . . . . . . . . . . . . . . . . . . 26 95 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 96 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 97 8.1. Normative References . . . . . . . . . . . . . . . . . . 26 98 8.2. Informative References . . . . . . . . . . . . . . . . . 27 99 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 27 100 Contributors' Addresses . . . . . . . . . . . . . . . . . . . . . 27 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 103 1. Introduction 105 The requirement of slicing network resources with desired quality of 106 service is emerging at every network technology, including the 107 Optical Transport Networks (OTN). As a part of the transport 108 network, OTN can provide hard pipes with guaranteed data isolation 109 and deterministic low latency, which are highly demanded in the 110 Service Level Agreement (SLA). This document describes a framework 111 for OTN network slicing and a YANG data model augmentation of the OTN 112 topology model. Additional YANG data model augmentations will be 113 defined in a future version of this draft. 115 1.1. Definition of OTN Slice 117 An OTN slice is an OTN virtual network topology connecting a number 118 of OTN endpoints using a set of shared or dedicated OTN network 119 resources to satisfy specific service level objectives (SLOs). 121 An OTN slice is a technology-specific realization of an IETF network 122 slice [I-D.ietf-teas-ietf-network-slices] in the OTN domain, with the 123 capability of configuring slice resources in the term of OTN 124 technologies. Therefore, all the terms and definitions concerning 125 network slicing as defined in [I-D.ietf-teas-ietf-network-slices] 126 apply to OTN slicing. 128 An OTN slice can span multiple OTN administrative domains, 129 encompassing access links, intra-domain paths, and inter-domain 130 links. An OTN slice may include multiple endpoints, each associated 131 with a set of physical or logical resources, e.g. optical port or 132 time slots, at the termination point (TP) of an access link or inter- 133 domain link at an OTN provider edge (PE) equipment. 135 An end-to-end OTN slice may be composed of multiple OTN segment 136 slices in a hierarchical or sequential (or stitched) combination. 138 Figure 1 illustrates the scope of OTN slices in multi-domain 139 environment. 141 <------------------End-to-end OTN Slice----------------> 143 <- OTN Segment Slice 1 ---> <-- OTN Segment Slice 2 --> 145 +-------------------------+ +-----------------------+ 146 | +-----+ +-------+ | | +-------+ +-----+| 147 +----+ | | OTN | | OTN | | | | OTN | | OTN || +----+ 148 | CE +-+-o PE +-...--+ Borde o--+--+-o Borde +-...--+ PE o+--+ CE | 149 +----+ |/| | | Node |\ | | | Node | | || +----+ 150 |||+-----+ +-------+ ||| | +-------+ +-----+| | 151 ||| OTN Domain 1 ||| | OTN Domain 2 | | 152 |++-----------------------++| +-----------------------+ | 153 | | | | | 154 | +-----+ +------------+ | | 155 | | | | | 156 V V V V V 157 Access OTN Slice Inter-domain Access 158 Link Endpoint Link Link 160 Figure 1: OTN Slice 162 OTN slices may be pre-configured by the management plane and 163 presented to the customer via the northbound interface (NBI), or be 164 dynamically provisioned by a higher layer slice controller, e.g. an 165 IETF network slice controller (IETF NSC) through the NBI. The OTN 166 slice is provided by a service provider to a customer to be used as 167 though it was part of the customer's own networks. 169 2. Use Cases for OTN Network Slicing 171 2.1. Leased Line Services with OTN 173 For end business customers (like OTT or enterprises), leased lines 174 have the advantage of providing high-speed connections with low 175 costs. On the other hand, the traffic control of leased lines is 176 very challenging due to rapid changes in service demands. Carriers 177 are recommended to provide network-level slicing capabilities to meet 178 this demand. Based on such capabilities, private network users have 179 full control over the sliced resources which have been allocated to 180 them and which could be used to support their leased lines, when 181 needed. Users may formulate policies based on the demand for 182 services and time to schedule the resources from the entire network's 183 perspective flexibly. For example, the bandwidth between any two 184 points may be established or released based on the time or monitored 185 traffic characteristics. The routing and bandwidth may be adjusted 186 at a specific time interval to maximize network resource utilization 187 efficiency. 189 2.2. Co-construction and Sharing 191 Co-construction and sharing of a network are becoming a popular means 192 among service providers to reduce networking building CAPEX. For Co- 193 construction and sharing case, there are typically multiple co- 194 founders for the same network. For example, one founder may provide 195 optical fibres and another founder may provide OTN equipment, while 196 each occupies a certain percentage of the usage rights of the network 197 resources. In this scenario, the network O&M is performed by a 198 certain founder in each region, where the same founder usually 199 deploys an independent management and control system. The other 200 founders of the network use each other's management and control 201 system to provision services remotely. In this scenario, different 202 founders' network resources need to be automatically (associated) 203 divided, isolated, and visualized. All founders may share or have 204 independent O&M capabilities, and should be able to perform service- 205 level provisioning in their respective slices. 207 2.3. Wholesale of optical resources 209 In the optical resource wholesale market, smaller, local carriers and 210 wireless carriers may rent resources from larger carriers, or 211 infrastructure carriers instead of building their networks. 212 Likewise, international carriers may rent resources from respective 213 local carriers and local carriers may lease their owned networks to 214 each other to achieve better network utilization efficiency. From 215 the perspective of a resource provider, it is crucial that a network 216 slice is timely configured to meet traffic matrix requirements 217 requested by its tenants. The support for multi-tenancy within the 218 resource provider's network demands that the network slices are 219 qualitatively isolated from each other to meet the requirements for 220 transparency, non-interference, and security. Typically, a resource 221 purchaser expects to use the leased network resources flexibly, just 222 like they are self-constructed. Therefore, the purchaser is not only 223 provided with a network slice, but also the full set of 224 functionalities for operating and maintaining the network slice. The 225 purchaser also expects to, flexibly and independently, schedule and 226 maintain physical resources to support their own end-to-end 227 automation using both leased and self-constructed network resources. 229 2.4. Vertical dedicated network with OTN 231 Vertical industry slicing is an emerging category of network slicing 232 due to the high demand for private high-speed network interconnects 233 for industrial applications. In this scenario, the biggest challenge 234 is to implement differentiated optical network slices based on the 235 requirements from different industries. For example, in the 236 financial industry, to support high-frequency transactions, the slice 237 must ensure to provide the minimum latency along with the mechanism 238 for latency management. For the healthcare industry, online 239 diagnosis network and software capabilities to ensure the delivery of 240 HD video without frame loss. For bulk data migration in data 241 centers, the network needs to support on-demand, large-bandwidth 242 allocation. In each of the aforementioned vertical industry 243 scenarios, the bandwidth shall be adjusted as required to ensure 244 flexible and efficient network resource usage. 246 2.5. End-to-end network slicing 248 In an end-to-end network slicing scenario such as 5G network slicing 249 [TS.28.530-3GPP], an IETF network slice 250 [I-D.ietf-teas-ietf-network-slices] provides the required 251 connectivity between other different segments of an end-to-end 252 network slice, such as the Radio Access Network (RAN) and the Core 253 Network (CN) segments, with a specific performance commitment. An 254 IETF network slice could be composed of network slices from multiple 255 technological and administrative domains. An IETF network slice can 256 be realized by using or combining multiple underlying OTN slices with 257 OTN resources, e.g. ODU time slots or ODU containers, to achieve 258 end-to-end slicing across the transport domain. 260 3. Framework for OTN slicing 262 OTN slices may be abstracted differently depending on the requirement 263 contained in the configuration provided by the slice customer. 264 Whereas the customer requests an OTN slice to provide connectivities 265 between specified endpoints, an OTN slice can be abstracted as a set 266 of endpoint-to-endpoint links, with each link formed by an end-to-end 267 tunnel across the underlying OTN networks. The resources associated 268 with each link of the slice is reserved and commissioned in the 269 underlying physical network upon the completion of configuring the 270 OTN slice and all the links are active. 272 An OTN slice can also be abstracted as an abstract topology when the 273 customer requests the slice to share resources between multiple 274 endpoints and to use the resources on demand. The abstract topology 275 may consist of virtual nodes and virtual links, whose associated 276 resources are reserved but not commissioned across the underlying OTN 277 networks. The customer can later commission resources within the 278 slice dynamically using the NBI provided by the service provider. An 279 OTN slice could use abstract topology to connect endpoints with 280 shared resources to optimize the resource utilization, and 281 connections can be activated within the slice as needed. 283 It is worth noting that those means to abstract an OTN slice are 284 similar to the Virtual Network (VN) abstraction defined for higher- 285 level interfaces in [RFC8453], in which context a connectivity-based 286 slice corresponds to Type 1 VN and a resource-based slice corresponds 287 to Type 2 VN, respectively. 289 A particular resource in an OTN network, such as a port or link, may 290 be sliced with one of the two granularity levels: 292 * Link-based slicing, in which a link and its associated link 293 termination points (LTPs) are dedicatedly allocated to a 294 particular OTN slice. 296 * Tributary-slot based slicing, in which multiple OTN slices share 297 the same link by allocating different OTN tributary slots in 298 different granularities. 300 Furthermore, an OTN switch is typically fully non-blockable switching 301 at the lowest ODU container granularity, it is desirable to specify 302 just the total number of ODU containers in the lowest granularity 303 (e.g. ODU0), when configuring tributary-slot based slicing on links 304 and ports internal to an OTN network. In multi-domain OTN network 305 scenarios where separate OTN slices are created on each of the OTN 306 networks and are stitched at inter-domain OTN links, it is necessary 307 to specify matching tributary slots at the endpoints of the inter- 308 domain links. In some real network scenarios, OTN network resources 309 including tributary slots are managed explicitly by network operators 310 for network maintenance considerations. Therefore an OTN slice 311 controller shall support configuring an OTN slice with both options. 313 An OTN slice controller (OTN-SC) is a logical function responsible 314 for the life-cycle management of OTN slices instantiated within the 315 corresponding OTN network domains. The OTN-SC provides technology- 316 specific interfaces at its northbound (OTN-SC NBI) to allow a higher- 317 layer slice controller, such as an IETF network slice controller 318 (NSC), or an orchestrator, to request OTN slices with OTN-specific 319 requirements. The OTN-SC interfaces at the southbound using the 320 MDSC-to-PNC interface (MPI) with a Physical Network Controller (PNC) 321 or Multi-Domain Service Orchestrator (MDSC), as defined in the ACTN 322 control framework [RFC8453]. The logical function within the OTN-SC 323 is responsible for translating the OTN slice requests into concrete 324 slice realization which can be understood and provisioned at the 325 southbound by the PNC or MDSC. 327 When realizing OTN slices, the OTN-SC may translate a connectivity- 328 based OTN slice into a set of end-to-end tunnels using the Traffic- 329 engineering(TE) tunnel interface defined in [I-D.ietf-teas-yang-te]. 330 For a resource-based OTN slice, the OTN-SC may translate the abstract 331 topology representing the slice into a colored graph on an abstract 332 TE topology using the TE topology interface defined in [RFC8795]. 334 The OTN-SC NBI is technology-specific, while the IETF NSC-NBI is 335 technology- agnostic. An IETF NSC may translate its customer's 336 technology-agnostic slice request into an OTN slice request and 337 utilize the OTN-SC NBI to realize the IETF network slice. 338 Alternatively, the IETF NSC may translate the slicing request into 339 tunnel or topology configuration commands and communicate directly 340 with the underlying PNC or MDSC to provision the IETF network slice. 342 Figure 2 illustrates the OTN slicing control hierarchy and the 343 positioning of the OTN slicing interfaces. 345 +--------------------+ 346 | Provider's User | 347 +--------|-----------+ 348 | CMI 349 +-----------------------+----------------------------+ 350 | Orchestrator / E2E Slice Controller | 351 +------------+-----------------------------+---------+ 352 | | NSC-NBI 353 | +---------------------+---------+ 354 | | IETF Network Slice Controller | 355 | +-----+---------------+---------+ 356 | | | 357 | OTN-SC NBI |OTN-SC NBI | 358 +------------+-------------+--------+ | 359 | OTN-SC | | 360 +--------------------------+--------+ | 361 | MPI | MPI 362 +--------------------------+---------------+---------+ 363 | PNC | 364 +--------------------------+-------------------------+ 365 | SBI 366 +-----------+----------+ 367 |OTN Physical Network | 368 +----------------------+ 370 Figure 2: Positioning of OTN Slicing Interfaces 372 OTN-SC functionalities may be recursive such that a higher-level OTN- 373 SC may designate the creation of OTN slices to a lower-level OTN-SC 374 in a recursive manner. This scenario may apply to the creation of 375 OTN slices in multi-domain OTN networks, where multiple domain-wide 376 OTN slices provisioned by lower-layer OTN-SCs are stitched to support 377 a multi-domain OTN slice provisioned by the higher-level OTN-SC. 378 Alternatively, the OTN-SC may interface with an MDSC, which in turn 379 interfaces with multiple PNCs through the MPI to realize OTN slices 380 in multi-domain OTN networks without OTN-SC recursion. Figure 3 381 illustrates both options for OTN slicing in multi-domain. 383 +-------------------+ +-------------------+ 384 | OTN-SC | | OTN-SC | 385 +--------|----------+ +---|----------|----+ 386 |MPI |OTN-SC NBI| 387 +--------|----------+ +---|----+ +---|----+ 388 | MDSC | | OTN-SC | | OTN-SC | 389 +---|----------|----+ +---|----+ +---|----+ 390 |MPI |MPI |MPI |MPI 391 +---|----+ +---|----+ +---|----+ +---|----+ 392 | PNC | | PNC | | PNC | | PNC | 393 +--------+ +--------+ +--------+ +--------+ 394 Multi-domain Option 1 Multi-domain Option 2 396 Figure 3: OTN-SC for multi-domain 398 OTN-SC functionalities are logically independent and may be deployed 399 in different combinations to cater to the realization needs. In 400 reference with the ACTN control framework [RFC8453], an OTN-SC may be 401 deployed - as an independent network function; - together with a 402 Physical Network Controller (PNC) for single-domain or with a Multi- 403 Domain Service Orchestrator (MDSC)for multi-domain; - together with a 404 higher-level network slice controller to support end-to-end network 405 slicing; 407 4. YANG Data Model for OTN Slicing Configuration 409 4.1. OTN Slicing YANG Model for MPI 411 4.1.1. MPI YANG Model Overview 413 For the configuration of connectivity-based OTN slices, existing 414 models such as the TE tunnel interface [I-D.ietf-teas-yang-te] may be 415 used and no addition is needed. This model is addressing the case 416 for configuring resource-based OTN slices, where the model permits to 417 reserve resources exploiting the common knowledge of an underlying 418 virtual topology between the OTN-SC and the subtended network 419 controller (MDSC or PNC). The slice is configured by marking 420 corresponding link resources on the TE topology received from the 421 underlying MDSC or PNC with a slice identifier and OTN-specific 422 resource requirements, e.g. the number of ODU time slots or the type/ 423 number of ODU containers. The MDSC or PNC, based on the marked 424 resources by the OTN-SC, will update the underlying TE topology with 425 new TE link for each of the colored links to keep booked the reserved 426 OTN resources e.g. time slots or ODU containers. 428 4.1.2. MPI YANG Model Tree 430 module: ietf-otn-slice 432 augment /nw:networks/nw:network/nt:link/tet:te/tet:te-link-attributes: 433 +--rw (otn-slice-granularity)? 434 +--:(link) 435 | +--rw slice-id? uint32 436 +--:(link-resource) 437 +--rw slices* [slice-id] 438 +--rw slice-id uint32 439 +--rw (technology)? 440 | +--:(otn) 441 | +--rw (slice-bandwidth)? 442 | +--:(containers) 443 | | +--rw odulist* [odu-type] 444 | | +--rw odu-type identityref 445 | | +--rw number? uint16 446 | +--:(time-slots) 447 | +--rw otn-ts-num? uint32 448 +--ro sliced-link-ref? -> ../../../../../nt:link/link-id 450 Figure 4: OTN slicing tree diagram 452 4.1.3. MPI YANG Code 454 file "ietf-otn-slice@2021-10-22.yang" 455 module ietf-otn-slice { 456 yang-version 1.1; 457 namespace "urn:ietf:params:xml:ns:yang:ietf-otn-slice"; 458 prefix "otnslice"; 460 import ietf-network { 461 prefix "nw"; 462 reference "RFC 8345: A YANG Data Model for Network Topologies"; 463 } 465 import ietf-network-topology { 466 prefix "nt"; 467 reference "RFC 8345: A YANG Data Model for Network Topologies"; 468 } 470 import ietf-te-topology { 471 prefix "tet"; 472 reference 473 "RFC8795: YANG Data Model for Traffic Engineering 474 (TE) Topologies"; 475 } 477 import ietf-otn-topology { 478 prefix "otntopo"; 479 reference 480 "I-D.ietf-ccamp-otn-topo-yang: A YANG Data Model 481 for Optical Transport Network Topology"; 482 } 484 import ietf-layer1-types { 485 prefix "l1-types"; 486 reference 487 "I-D.ietf-ccamp-layer1-types: A YANG Data Model 488 for Layer 1 Types"; 489 } 491 organization 492 "IETF CCAMP Working Group"; 493 contact 494 "WG Web: 495 WG List: 497 Editor: Haomian Zheng 498 500 Editor: Italo Busi 501 503 Editor: Aihua Guo 504 506 Editor: Victor Lopez 507 "; 509 description 510 "This module defines a YANG data model to configure an OTN 511 network slice realization. 513 The model fully conforms to the Network Management Datastore 514 Architecture (NMDA). 516 Copyright (c) 2021 IETF Trust and the persons 517 identified as authors of the code. All rights reserved. 519 Redistribution and use in source and binary forms, with or 520 without modification, is permitted pursuant to, and subject 521 to the license terms contained in, the Simplified BSD License 522 set forth in Section 4.c of the IETF Trust's Legal Provisions 523 Relating to IETF Documents 524 (https://trustee.ietf.org/license-info). 525 This version of this YANG module is part of RFC XXXX; see 526 the RFC itself for full legal notices."; 528 revision "2021-10-22" { 529 description 530 "Latest revision of MPI YANG model for OTN slicing."; 531 reference 532 "draft-zheng-ccamp-yang-otn-slicing-03: Framework and Data 533 Model for OTN Network Slicing"; 534 } 536 /* 537 * Groupings 538 */ 540 grouping otn-link-slice-profile { 541 description 542 "Profile of an OTN link slice."; 543 choice otn-slice-granularity { 544 default "link"; 545 description 546 "Link slice granularity."; 547 case link { 548 leaf slice-id { 549 type uint32; 550 description 551 "Slice identifier"; 552 } 553 } 554 case link-resource { 555 list slices { 556 key slice-id; 557 description 558 "List of slices."; 559 leaf slice-id { 560 type uint32; 561 description 562 "Slice identifier"; 563 } 564 choice technology { 565 description 566 "Data plane technology types."; 568 case otn { 569 choice slice-bandwidth { 570 description 571 "Bandwidth specification for OTN slices."; 572 case containers { 573 uses l1-types:otn-link-bandwidth; 574 } 575 case time-slots { 576 leaf otn-ts-num { 577 type uint32; 578 description 579 "Number of OTN tributary slots allocated for the 580 slice."; 581 } 582 } 583 } 584 } 585 } 586 leaf sliced-link-ref { 587 type leafref { 588 path "../../../../../nt:link/nt:link-id"; 589 } 590 config false; 591 description 592 "Relative reference to virtual links generated from 593 this TE link."; 594 } 595 } 596 } 597 } 598 } 600 /* 601 * Augments 602 */ 603 augment "/nw:networks/nw:network/nt:link/tet:te/" 604 + "tet:te-link-attributes" { 605 when "../../../nw:network-types/tet:te-topology/" 606 + "otntopo:otn-topology" { 607 description 608 "Augmentation parameters apply only for networks with 609 OTN topology type."; 610 } 611 description 612 "Augment OTN TE link attributes with slicing profile."; 613 uses otn-link-slice-profile; 614 } 615 } 617 619 Figure 5: OTN slicing YANG model 621 4.2. OTN Slicing YANG Model for OTN-SC NBI 623 4.2.1. NBI YANG Model Overview 625 The YANG model for OTN-SC NBI is OTN-technology specific, but shares 626 many common constructs and attributes with generic network slicing 627 YANG models. Furthermore, the OTN-SC NBI YANG is expected to support 628 both connectivity-based and resource-based slice configuration, which 629 is likely a common requirement for supporting slicing at other 630 transport network layers, e.g. WDM or MPLS-TP. Therefore, the OTN- 631 SC NBI YANG model is designed into two models, a common base model 632 for transport network slicing, and an OTN slicing model which 633 augments the base model with OTN technology-specific constructs. 635 The base model defines a transport network slice (TNS) with the 636 following constructs and attributes: - Common attributes, which 637 include a set of common attributes like slice identifier, name, 638 description and names of customers who use the slice. - Endpoints, 639 which represent conceptual points of connection from a customer 640 device to the TNS. An endpoint is mapped to specific physical or 641 virtual resources of the customer and provider, and such mapping is 642 pre-negotiated and known to both the customer and provider prior to 643 the slice configuration. The mechanism for endpoint negotiation is 644 outside the scope of this draft. - Network topology, which represent 645 set of shared, reserved resources organized as a virtual topology 646 between all of the endpoints. A customer could use such network 647 topology to define detailed connecvitiy path traversing the topology, 648 and allow sharing of resources between its multiple endpoint pairs. 649 - Connectivity matrix, which represent the intended virtual 650 connections between the endpoints within a TNS. A connctivity matrix 651 entry could be associated with an explicit path over the above 652 network topology. - Service-level objectives (SLOs) associated with 653 different objects, including the TNS, node, link, termination point, 654 and explicit path, within a TNS. 656 4.2.2. NBI YANG Model Tree for Transport Network Slice 658 module: ietf-transport-network-slice 659 +--rw network-slices 660 +--rw network-slice* [ns-id] 661 +--rw ns-id string 662 +--rw ns-name? string 663 +--rw ns-description? string 664 +--rw customer-name* string 665 +--rw slo 666 | +--rw optimization-criterion? identityref 667 | +--rw delay-tolerance? boolean 668 | +--rw periodicity* uint64 669 | +--rw isolation-level? identityref 670 +--rw endpoints 671 | +--rw endpoint* [endpoint-id] 672 | +--rw endpoint-id string 673 +--rw network-topologies 674 | +--rw network-topology* [topology-id] 675 | +--rw topology-id string 676 | +--rw node* [node-id] 677 | | +--rw node-id inet:uri 678 | | +--rw slo 679 | | | +--rw isolation-level? identityref 680 | | +--rw termination-point* [tp-id] 681 | | +--rw tp-id inet:uri 682 | | +--rw endpoint-id? leafref 683 | +--rw link* [link-id] 684 | +--rw link-id inet:uri 685 | +--rw slo 686 | | +--rw delay-tolerance? boolean 687 | | +--rw periodicity* uint64 688 | | +--rw isolation-level? identityref 689 | +--rw source 690 | | +--rw source-node? -> ../../../node/node-id 691 | | +--rw source-tp? leafref 692 | +--rw destination 693 | +--rw dest-node? -> ../../../node/node-id 694 | +--rw dest-tp? leafref 695 +--rw connectivity-matrices 696 +--rw connectivity-matrix* [connectivity-matrix-id] 697 +--rw connectivity-matrix-id uint32 698 +--rw topology-id? leafref 699 +--rw src-endpoint? 700 | -> ../../../endpoints/endpoint/endpoint-id 701 +--rw dst-endpoint? 702 | -> ../../../endpoints/endpoint/endpoint-id 703 +--rw slo 704 +--rw explicit-path* [tp-id] 705 +--rw tp-id leafref 707 Figure 6: Tree diagram for transport network slice 709 4.2.3. NBI YANG Code for Transport Network Slice 710 file "ietf-transport-network-slice@2021-10-22.yang" 711 module ietf-transport-network-slice { 712 yang-version 1.1; 713 namespace "urn:ietf:params:xml:ns:yang:ietf-transport-network-slice"; 714 prefix "tns"; 716 import ietf-inet-types { 717 prefix inet; 718 reference "RFC 6991"; 719 } 721 import ietf-te-types { 722 prefix "te-types"; 723 reference 724 "RFC 8776: Traffic Engineering Common YANG Types"; 725 } 727 organization 728 "IETF CCAMP Working Group"; 729 contact 730 "WG Web: 731 WG List: 733 Editor: Haomian Zheng 734 736 Editor: Italo Busi 737 739 Editor: Aihua Guo 740 742 Editor: Victor Lopez 743 "; 745 description 746 "This module defines a YANG data model to configure an OTN 747 network slice realization. 749 The model fully conforms to the Network Management Datastore 750 Architecture (NMDA). 752 Copyright (c) 2021 IETF Trust and the persons 753 identified as authors of the code. All rights reserved. 755 Redistribution and use in source and binary forms, with or 756 without modification, is permitted pursuant to, and subject 757 to the license terms contained in, the Simplified BSD License 758 set forth in Section 4.c of the IETF Trust's Legal Provisions 759 Relating to IETF Documents 760 (https://trustee.ietf.org/license-info). 761 This version of this YANG module is part of RFC XXXX; see 762 the RFC itself for full legal notices."; 764 revision "2021-10-22" { 765 description 766 "Latest revision of NBI YANG model for OTN slicing."; 767 reference 768 "draft-zheng-ccamp-yang-otn-slicing-03: Framework and Data 769 Model for OTN Network Slicing"; 770 } 772 /* 773 * Identities 774 */ 775 identity isolation-level { 776 description 777 "Base identity for the isolation-level."; 778 reference 779 "GSMA-NS-Template: Generic Network Slice Template, 780 Version 3.0."; 781 } 782 identity no-isolation { 783 base isolation-level; 784 description 785 "Network slices are not separated."; 786 } 787 identity physical-isolation { 788 base isolation-level; 789 description 790 "Network slices are physically separated (e.g. different rack, 791 different hardware, different location, etc.)."; 792 } 793 identity logical-isolation { 794 base isolation-level; 795 description 796 "Network slices are logically separated."; 797 } 798 identity process-isolation { 799 base physical-isolation; 800 description 801 "Process and threads isolation."; 802 } 803 identity physical-memory-isolation { 804 base physical-isolation; 805 description 806 "Process and threads isolation."; 807 } 808 identity physical-network-isolation { 809 base physical-isolation; 810 description 811 "Process and threads isolation."; 812 } 813 identity virtual-resource-isolation { 814 base logical-isolation; 815 description 816 "A network slice has access to specific range of resources 817 that do not overlap with other network slices 818 (e.g. VM isolation)."; 819 } 820 identity network-functions-isolation { 821 base logical-isolation; 822 description 823 "NF (Network Function) is dedicated to the network slice, but 824 virtual resources are shared."; 825 } 826 identity service-isolation { 827 base logical-isolation; 828 description 829 "NSC data are isolated from other NSCs, but virtual 830 resources and NFs are shared."; 831 } 833 /* 834 * Groupings 835 */ 837 grouping ns-generic-info { 838 description 839 "Generic configuration of a network slice"; 840 leaf ns-name { 841 type string; 842 description 843 "Name of the specific network slice"; 844 } 845 leaf ns-description { 846 type string; 847 description 848 "Description regarding the specific network slice"; 849 } 850 leaf-list customer-name { 851 type string; 852 description 853 "List of customers using the slice"; 855 } 856 } 858 grouping ns-slo { 859 description 860 "SLO configuration of a network slice"; 862 container slo { 863 description 864 "SLO configuration of a network slice"; 866 leaf optimization-criterion { 867 type identityref { 868 base te-types:objective-function-type; 869 } 870 description 871 "Optimization criterion applied to this topology."; 872 } 873 leaf delay-tolerance { 874 type boolean; 875 description 876 "'true' if is not too critical how long it takes to deliver 877 the amount of data."; 878 reference 879 "GSMA-NS-Template: Generic Network Slice Template, 880 Version 3.0."; 881 } 882 leaf-list periodicity { 883 type uint64; 884 units seconds; 885 description 886 "A list of periodicities supported by the network slice."; 887 reference 888 "GSMA-NS-Template: Generic Network Slice Template, 889 Version 3.0."; 890 } 891 leaf isolation-level { 892 type identityref { 893 base isolation-level; 894 } 895 description 896 "A network slice instance may be fully or partly, logically 897 and/or physically, isolated from another network slice 898 instance. This attribute describes different types of 899 isolation:"; 900 } 901 } 902 } 903 grouping node-slo { 904 description 905 "Node SLO"; 906 container slo { 907 description 908 "SLO configuration of a node"; 909 leaf isolation-level { 910 type identityref { 911 base isolation-level; 912 } 913 description 914 "A network slice instance may be fully or partly, logically 915 and/or physically, isolated from another network slice 916 instance. This attribute describes different types of 917 isolation:"; 918 } 919 } 920 } 922 grouping link-slo { 923 description 924 "Link SLO"; 925 container slo { 926 description 927 "SLO configuration of a link"; 928 leaf delay-tolerance { 929 type boolean; 930 description 931 "'true' if is not too critical how long it takes to deliver 932 the amount of data."; 933 reference 934 "GSMA-NS-Template: Generic Network Slice Template, 935 Version 3.0."; 936 } 937 leaf-list periodicity { 938 type uint64; 939 units seconds; 940 description 941 "A list of periodicities supported by the network slice."; 942 reference 943 "GSMA-NS-Template: Generic Network Slice Template, 944 Version 3.0."; 945 } 946 leaf isolation-level { 947 type identityref { 948 base isolation-level; 949 } 950 description 951 "A network slice instance may be fully or partly, logically 952 and/or physically, isolated from another network slice 953 instance. This attribute describes different types of 954 isolation:"; 955 } 956 } 957 } 959 grouping connectivity-matrix-slo { 960 description 961 "SLO configuration of a path within a network slice"; 963 container slo { 964 description 965 "Path SLO configuration"; 966 } 967 leaf delay-tolerance { 968 type boolean; 969 description 970 "'true' if is not too critical how long it takes to deliver 971 the amount of data."; 972 reference 973 "GSMA-NS-Template: Generic Network Slice Template, 974 Version 3.0."; 975 } 976 leaf-list periodicity { 977 type uint64; 978 units seconds; 979 description 980 "A list of periodicities supported by the network slice."; 981 reference 982 "GSMA-NS-Template: Generic Network Slice Template, 983 Version 3.0."; 984 } 985 leaf isolation-level { 986 type identityref { 987 base isolation-level; 988 } 989 description 990 "A network slice instance may be fully or partly, logically 991 and/or physically, isolated from another network slice 992 instance. This attribute describes different types of 993 isolation:"; 994 } 995 } 997 grouping connectivity-matrix-entry-slo { 998 description 999 "SLO configuration of a connectivity matrix entry within a 1000 network slice"; 1002 container slo { 1003 description 1004 "SLO configuration of a connectivity matrix entry"; 1005 } 1006 } 1008 grouping explicit-path { 1009 description 1010 "Explicit path for a connectivity matrix entry"; 1012 list explicit-path { 1013 key "tp-id"; 1014 description 1015 "List of TPs within a network topology that form a path."; 1016 leaf tp-id { 1017 type leafref { 1018 path "/network-slices/network-slice[ns-id=current()"+ 1019 "/../../../../ns-id]/network-topologies"+ 1020 "/network-topology[topology-id=current()"+ 1021 "/../../topology-id]/node/termination-point/tp-id"; 1022 } 1023 description 1024 "Relative reference to TP id."; 1025 } 1026 } 1027 } 1029 grouping network-topology-def { 1030 description 1031 "Network topology definition"; 1032 list node { 1033 key "node-id"; 1034 description 1035 "The inventory of nodes of this topology."; 1036 leaf node-id { 1037 type inet:uri; 1038 description 1039 "Node identifier."; 1040 } 1041 uses node-slo; 1042 list termination-point { 1043 key "tp-id"; 1044 description 1045 "TP identifier"; 1046 leaf tp-id { 1047 type inet:uri; 1048 description 1049 "Termination point identifier."; 1050 } 1051 leaf endpoint-id { 1052 type leafref { 1053 path "/network-slices/network-slice[ns-id=current()"+ 1054 "/../../../../../ns-id]/endpoints/endpoint/"+ 1055 "endpoint-id"; 1056 } 1057 description 1058 "Relative reference to TP id."; 1059 } 1060 } 1061 } 1062 list link { 1063 key "link-id"; 1064 description 1065 "Link identifier."; 1066 leaf link-id { 1067 type inet:uri; 1068 description 1069 "Link identifier."; 1070 } 1071 uses link-slo; 1072 container source { 1073 description 1074 "Link source node"; 1075 leaf source-node { 1076 type leafref { 1077 path "../../../node/node-id"; 1078 } 1079 description 1080 "Source node identifier, must be in same topology."; 1081 } 1082 leaf source-tp { 1083 type leafref { 1084 path "../../../node[node-id=current()/../"+ 1085 "source-node]/termination-point/tp-id"; 1086 } 1087 description 1088 "Termination point within source node that terminates 1089 the link."; 1090 } 1091 } 1092 container destination { 1093 description 1094 "Link destination node"; 1096 leaf dest-node { 1097 type leafref { 1098 path "../../../node/node-id"; 1099 } 1100 description 1101 "Destination node identifier, must be in same topology."; 1102 } 1103 leaf dest-tp { 1104 type leafref { 1105 path "../../../node[node-id=current()/../"+ 1106 "dest-node]/termination-point/tp-id"; 1107 } 1108 description 1109 "Termination point within destination node that terminates 1110 the link."; 1111 } 1112 } 1113 } 1114 } 1116 /* 1117 * Configuration data nodes 1118 */ 1119 container network-slices { 1120 description 1121 "Generic network slice configurations"; 1122 list network-slice { 1123 key "ns-id"; 1124 description 1125 "Network slice identifier"; 1126 leaf ns-id { 1127 type string; 1128 description 1129 "A unique network slice identifier across a slice controller"; 1130 } 1131 uses ns-generic-info; 1132 uses ns-slo; 1134 container endpoints { 1135 description 1136 "Endpoints of a network slice"; 1138 list endpoint { 1139 key "endpoint-id"; 1140 description 1141 "List of endpoints"; 1142 leaf endpoint-id { 1143 type string; 1144 description 1145 "Endpoint identifier"; 1146 } 1147 } 1148 } 1149 container network-topologies { 1150 description 1151 "A network slice is described as a network topology"; 1153 list network-topology { 1154 key "topology-id"; 1155 description 1156 "List of network topologies"; 1157 leaf topology-id { 1158 type string; 1159 description 1160 "Topology identifier"; 1161 } 1162 uses network-topology-def; 1163 } 1164 } 1165 container connectivity-matrices { 1166 description 1167 "Connectivity matrices"; 1169 list connectivity-matrix { 1170 key "connectivity-matrix-id"; 1171 description 1172 "List of connectivity matrix entities"; 1173 leaf connectivity-matrix-id { 1174 type uint32; 1175 description 1176 "Connectivity matrix identifier"; 1177 } 1178 leaf topology-id { 1179 type leafref { 1180 path "../../../network-topologies/network-topology/topology-id"; 1181 } 1182 description 1183 "Relative reference to network topology id."; 1184 } 1185 leaf src-endpoint { 1186 type leafref { 1187 path "../../../endpoints/endpoint/endpoint-id"; 1188 } 1189 description 1190 "Relative reference to endpoint id."; 1191 } 1192 leaf dst-endpoint { 1193 type leafref { 1194 path "../../../endpoints/endpoint/endpoint-id"; 1195 } 1196 description 1197 "Relative reference to endpoint id."; 1198 } 1199 uses connectivity-matrix-entry-slo; 1200 uses explicit-path; 1201 } //connectivity-matrix 1202 } //connectivity-matrices 1203 } //network-slice 1204 } //network slices 1205 } 1206 1208 Figure 7: YANG model for transport network slice 1210 4.2.4. NBI YANG Model Tree for OTN slice 1212 TBD. 1214 4.2.5. NBI YANG Code for OTN Slice 1216 TBD. 1218 5. Manageability Considerations 1220 To ensure the security and controllability of physical resource 1221 isolation, slice-based independent operation and management are 1222 required to achieve management isolation. Each optical slice 1223 typically requires dedicated accounts, permissions, and resources for 1224 independent access and O&M. This mechanism is to guarantee the 1225 information isolation among slice tenants and to avoid resource 1226 conflicts. The access to slice management functions will only be 1227 permitted after successful security checks. 1229 6. Security Considerations 1231 1233 7. IANA Considerations 1235 1237 8. References 1239 8.1. Normative References 1241 [I-D.ietf-teas-yang-te] 1242 Saad, T., Gandhi, R., Liu, X., Beeram, V. P., Bryskin, I., 1243 and O. G. D. Dios, "A YANG Data Model for Traffic 1244 Engineering Tunnels, Label Switched Paths and Interfaces", 1245 Work in Progress, Internet-Draft, draft-ietf-teas-yang-te- 1246 27, 8 July 2021, . 1249 [RFC8795] Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and 1250 O. Gonzalez de Dios, "YANG Data Model for Traffic 1251 Engineering (TE) Topologies", RFC 8795, 1252 DOI 10.17487/RFC8795, August 2020, 1253 . 1255 [TS.28.530-3GPP] 1256 3rd Generation Partnership Project (3GPP), "3GPP TS 28.530 1257 V15.1.0 Technical Specification Group Services and System 1258 Aspects; Management and orchestration; Concepts, use cases 1259 and requirements (Release 15)", 3GPP TS 28.530 , December 1260 2018, . 1263 8.2. Informative References 1265 [I-D.ietf-teas-ietf-network-slices] 1266 Farrel, A., Gray, E., Drake, J., Rokui, R., Homma, S., 1267 Makhijani, K., Contreras, L. M., and J. Tantsura, 1268 "Framework for IETF Network Slices", Work in Progress, 1269 Internet-Draft, draft-ietf-teas-ietf-network-slices-04, 23 1270 August 2021, . 1273 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for 1274 Abstraction and Control of TE Networks (ACTN)", RFC 8453, 1275 DOI 10.17487/RFC8453, August 2018, 1276 . 1278 Acknowledgments 1280 This document was prepared using kramdown. 1282 Previous versions of this document were prepared using 2-Word- 1283 v2.0.template.dot. 1285 Contributors' Addresses 1286 Henry Yu 1287 Huawei Technologies Canada 1289 Email: henry.yu@huawei.com 1291 Jiang Sun 1292 China Mobile 1294 Email: sunjiang@chinamobile.com 1296 Authors' Addresses 1298 Haomian Zheng 1299 Huawei Technologies 1300 H1, Xiliu Beipo Village, Songshan Lake 1301 Dongguan 1302 China 1304 Email: zhenghaomian@huawei.com 1306 Italo Busi 1307 Huawei Technologies 1309 Email: italo.busi@huawei.com 1311 Aihua Guo 1312 Futurewei Technologies 1314 Email: aihuaguo.ietf@gmail.com 1316 Luis M. Contreras 1317 Telefonica 1319 Email: luismiguel.contrerasmurillo@telefonica.com 1321 Oscar Gonzalez de Dios 1322 Telefonica 1324 Email: oscar.gonzalezdedios@telefonica.com 1326 Victor Lopez 1327 Nokia 1328 Email: victor.lopez@nokia.com 1330 Sergio Belotti 1331 Nokia 1333 Email: Sergio.belotti@nokia.com 1335 Dieter Beller 1336 Nokia 1338 Email: Dieter.Beller@nokia.com 1340 Reza Rokui 1341 Nokia 1343 Email: reza.rokui@nokia.com 1345 Yunbin Xu 1346 CAICT 1348 Email: xuyunbin@caict.ca.cn 1350 Yang Zhao 1351 China Mobile 1353 Email: zhaoyangyjy@chinamobile.com 1355 Xufeng Liu 1356 Volta Networks 1358 Email: xufeng.liu.ietf@gmail.com