idnits 2.17.1 draft-king-teas-applicability-actn-slicing-10.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 == Line 621 has weird spacing: '...rovider v ...' -- The document date (March 31, 2021) is 1122 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-04) exists of draft-dong-teas-enhanced-vpn-vtn-scalability-01 == Outdated reference: A later version (-26) exists of draft-ietf-ccamp-l1csm-yang-13 == Outdated reference: A later version (-12) exists of draft-ietf-teas-actn-pm-telemetry-autonomics-04 == Outdated reference: A later version (-24) exists of draft-ietf-teas-actn-vn-yang-10 == Outdated reference: A later version (-17) exists of draft-ietf-teas-enhanced-vpn-06 == Outdated reference: A later version (-01) exists of draft-ietf-teas-ietf-network-slice-definition-00 == Outdated reference: A later version (-27) exists of draft-ietf-teas-rfc3272bis-10 == Outdated reference: A later version (-15) exists of draft-ietf-teas-te-service-mapping-yang-05 == Outdated reference: A later version (-36) exists of draft-ietf-teas-yang-te-25 Summary: 0 errors (**), 0 flaws (~~), 11 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TEAS Working Group D. King 3 Internet-Draft Old Dog Consulting 4 Intended status: Informational J. Drake 5 Expires: October 2, 2021 Juniper Networks 6 H. Zheng 7 Huawei Technologies 8 A. Farrel 9 Old Dog Consulting 10 March 31, 2021 12 Applicability of Abstraction and Control of Traffic Engineered Networks 13 (ACTN) to Network Slicing 14 draft-king-teas-applicability-actn-slicing-10 16 Abstract 18 Network abstraction is a technique that can be applied to a network 19 domain. It utilizes a set of policies to select network resources 20 and obtain a view of potential connectivity across the network. 22 Network slicing is an approach to network operations that builds on 23 the concept of network abstraction to provide programmability, 24 flexibility, and modularity. It may use techniques such as Software 25 Defined Networking (SDN) and Network Function Virtualization (NFV) to 26 create multiple logical or virtual networks, each tailored for a set 27 of services that share the same set of requirements. 29 Abstraction and Control of Traffic Engineered Networks (ACTN) is 30 described in RFC 8453. It defines an SDN-based architecture that 31 relies on the concept of network and service abstraction to detach 32 network and service control from the underlying data plane. 34 This document outlines the applicability of ACTN to network slicing 35 in a Traffic Engineering (TE) network that utilizes IETF technology. 36 It also identifies the features of network slicing not currently 37 within the scope of ACTN, and indicates where ACTN might be extended. 39 Status of This Memo 41 This Internet-Draft is submitted in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF). Note that other groups may also distribute 46 working documents as Internet-Drafts. The list of current Internet- 47 Drafts is at https://datatracker.ietf.org/drafts/current/. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 This Internet-Draft will expire on October 2, 2021. 56 Copyright Notice 58 Copyright (c) 2021 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents 63 (https://trustee.ietf.org/license-info) in effect on the date of 64 publication of this document. Please review these documents 65 carefully, as they describe your rights and restrictions with respect 66 to this document. Code Components extracted from this document must 67 include Simplified BSD License text as described in Section 4.e of 68 the Trust Legal Provisions and are provided without warranty as 69 described in the Simplified BSD License. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 74 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 75 2. Requirements for Network Slicing . . . . . . . . . . . . . . 5 76 2.1. Resource Slicing . . . . . . . . . . . . . . . . . . . . 6 77 2.2. Network Virtualization . . . . . . . . . . . . . . . . . 6 78 2.3. Service Isolation . . . . . . . . . . . . . . . . . . . . 6 79 2.4. Control and Orchestration . . . . . . . . . . . . . . . . 7 80 3. Abstraction and Control of Traffic Engineered (TE) Networks 81 (ACTN) . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 82 3.1. ACTN Virtual Network as a Network Slice . . . . . . . . . 8 83 3.2. ACTN Virtual Network for Network Slice Aggregation . . . 9 84 3.3. Management Components for ACTN and Network Slicing . . . 9 85 3.4. Examples of ACTN Delivering Types of Network Slices . . . 10 86 3.4.1. ACTN Used for Virtual Private Line . . . . . . . . . 10 87 3.4.2. ACTN Used for VPN Delivery Model . . . . . . . . . . 12 88 3.4.3. ACTN Used to Deliver a Virtual Consumer Network . . . 13 89 4. YANG Models . . . . . . . . . . . . . . . . . . . . . . . . . 15 90 4.1. Network Slice Service Mapping from TE to ACTN VN Models . 15 91 4.2. Interfaces and Yang Models . . . . . . . . . . . . . . . 16 92 4.3. ACTN VN Telemetry . . . . . . . . . . . . . . . . . . . . 17 93 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 94 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 95 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 96 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19 97 9. Informative References . . . . . . . . . . . . . . . . . . . 19 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 100 1. Introduction 102 The principles of network resource separation are not new. For 103 years, the concept of separated overlay and logical (virtual) 104 networking has existed, allowing multiple services to be deployed 105 over a single physical network comprised of single or multiple 106 layers. However, several key differences exist that differentiate 107 overlay and virtual networking from network slicing. 109 A network slice is a virtual (that is, logical) network with its own 110 network topology and a set of network resources that are used to 111 provide connectivity that conforms to a specific Service Level 112 Agreement (SLA) or set of Service Level Objectives (SLOs). The 113 network resources used to realize a network slice belong to the 114 network that is sliced. The resources may be assigned and dedicated 115 to an individual slice, or they may be shared with other slices 116 enabling different degrees of service guarantee and providing 117 different levels of isolation between the traffic in each slice. 119 [I-D.ietf-teas-ietf-network-slice-definition] provides a number of 120 useful definitions for network slicing in the context of IETF network 121 technologies. In particular, that document defines the term "IETF 122 network slice" to be the generic network slice concept applied to a 123 network that uses IETF technologies. An IETF network slice could 124 span multiple technologies (such as IP, MPLS, or optical) and 125 multiple administrative domains. The logical network that is an IETF 126 network slice may be kept separate from other concurrent logical 127 networks each with independent control and management: each can be 128 created or modified on demand. Since this document is focused 129 entirely on IETF technologies, it uses the term "network slice" as a 130 more concise expression. Further dicussion on the topic of IETF 131 network slices can be found in 132 [I-D.ietf-teas-ietf-network-slice-framework]. 134 At one end of the spectrum, a virtual private wire or a virtual 135 private network (VPN) may be used to build a network slice. In these 136 cases, the network slices do not require the service provider to 137 isolate network resources for the provision of the service - the 138 service is "virtual". 140 At the other end of the spectrum there may be a detailed description 141 of a complex service that will meet the needs of a set of 142 applications with connectivity and service function requirements that 143 may include compute resource, storage capability, and access to 144 content. Such a service may be requested dynamically (that is, 145 instantiated when an application needs it, and released when the 146 application no longer needs it), and modified as the needs of the 147 application change. This type of service is called an enhanced VPN 148 and is described in more detail in [I-D.ietf-teas-enhanced-vpn]. It 149 is often based on Traffic Engineering (TE) constructs in the underlay 150 network. 152 Abstraction and Control of TE Networks (ACTN) [RFC8453] is a 153 framework that facilitates the abstraction of underlying network 154 resources to higher-layer applications and that allows nework 155 operators to create virtual networks for their customers through the 156 abstraction of the operators' network resources. 158 As noted in [I-D.ietf-teas-ietf-network-slice-framework], ACTN is a 159 toolset capable of delivering network slice functionality. This 160 document outlines the application of ACTN and associated enabling 161 technologies to provide network slicing in a network that utilizes 162 IETF technologies such as IP, MPLS, or GMPLS. It describes how the 163 ACTN functional components can be used to support model-driven 164 partitioning of resources into variable-sized bandwidth units to 165 facilitate network sharing and virtualization. Furthermore, the use 166 of model-based interfaces to dynamically request the instantiation of 167 virtual networks can be extended to encompass requesting and 168 instantiation of specific service functions (which may be both 169 physical or virtual), and to partition network resources such as 170 compute resource, storage capability, and access to content. 171 Finally, this document highlights how the ACTN approach might be 172 extended to address the requirements of network slicing where the 173 underlying network is TE-capable. 175 1.1. Terminology 177 As far as is possible, this document re-uses terminology from 178 [I-D.ietf-teas-ietf-network-slice-definition], 179 [I-D.ietf-teas-enhanced-vpn] and 180 [I-D.ietf-teas-ietf-network-slice-framework]. The terms defined 181 below are give context and meaning for use in this document only and 182 do not force wider applicability. As other work matures, it is hoped 183 that the terminology will converge. 185 Service Provider: A server network or collection of server networks. 186 The persons or organization responsible for operating such 187 networks. 189 Consumer: As defined in 190 [I-D.ietf-teas-ietf-network-slice-definition], a consumer is the 191 component or entity that requests and uses a network slice. This 192 may be any application, client network, or customer of a service 193 provider. In the ACTN framework [RFC8453] the consumer of a 194 network service is termed a 'customer' because it will often be 195 the case that a VPN consumer is a customer of the operator of the 196 core network that delivers the service. In the context of a 197 network slice, the consumer may well be a customer, but might also 198 be a client network of the service provider (which could also be 199 an internal organization of the service provider), or an 200 application that engineers traffic in the network. 202 Service Functions (SFs): Components that provide specific functions 203 within a network. SFs are often combined in a specific sequence 204 called a service function chain to deliver services [RFC7665]. 206 Resource: Any feature including connectivity, bufferage, compute, 207 storage, and content delivery that forms part of or can be 208 accessed through a network. Resources may be shared between 209 users, applications, and clients, or they may be dedicated for use 210 by a unique consumer. 212 Infrastructure Resources: The hardware and software for hosting and 213 connecting SFs. These resources may include computing hardware, 214 storage capacity, network resources (e.g., links and switching/ 215 routing devices enabling network connectivity), and physical 216 assets for radio access. 218 Service Level Agreement (SLA): Per [I-D.ietf-teas-ietf-network-slice 219 -definition], an SLA is an explicit or implicit contract between 220 the consumer of a network slice and the provider of the slice. 221 The SLA is expressed in terms of a set of Service Level Objectives 222 (SLOs) and may include commercial terms as well as the 223 consequences of violating the SLOs. The SLA describes the quality 224 with which features and functions are to be delivered. It may 225 include measures of bandwidth, latency, and jitter; the types of 226 service (such as firewalls or billing) to be provided; the 227 location, nature, and quantities of services (such as the amount 228 and location of compute resources and the accelerators required). 230 Network Slice Service: An agreement between a consumer and a service 231 provider to deliver network resources according to a specific 232 service level agreement. 234 2. Requirements for Network Slicing 236 According to [I-D.ietf-teas-ietf-network-slice-framework] the 237 consumer expresses requirements for a particular IETF network slice 238 by specifying what is required rather than how the requirement is to 239 be fulfilled. That is, the IETF network slice consumer's view of a 240 IETF network slice is an abstract one. 242 The concept of network slicing is a key capability to serve consumers 243 with a wide variety of different service needs expressed as SLOs in 244 term of latency, reliability, capacity, and service function specific 245 capabilities. 247 This section outlines the key capabilities required to realize 248 network slicing in a TE-enabled IETF technology network. 250 2.1. Resource Slicing 252 Network resources need to be allocated and dedicated for use by a 253 specific network slice, or they may be shared among multiple slices. 254 This allows a flexible approach that can deliver a range of services 255 by partitioning (that is, slicing) the available network resources to 256 make them available to meet the consumer's SLA. 258 2.2. Network Virtualization 260 Network virtualization enables the creation of multiple virtual 261 networks that are operationally decoupled from the underlying 262 physical network, and are run on top of it. Slicing enables the 263 creation of virtual networks as consumer services. 265 2.3. Service Isolation 267 A consumer may request, through their SLA, that changes to the other 268 services delivered by the service provider do not have any negative 269 impact on the delivery of the service. This quality is refered to as 270 "isolation" [I-D.ietf-teas-ietf-network-slice-definition] 271 [I-D.ietf-teas-enhanced-vpn]. 273 Delivery of such service isolation may be achieved in the underlying 274 network by various forms of resource partitioning ranging from 275 dedicated allocation of resources for a specific slice, to sharing or 276 resources with safeguards. 278 Although multiple network slices may utilize resources from a single 279 underlying network, isolation should be understood in terms of the 280 following three categorisations. 282 o Performance isolation requires that service delivery for one 283 network slice does not adversely impact congestion or performance 284 levels of other slices. 286 o Security isolation means that attacks or faults occurring in one 287 slice do not impact on other slices. Moreover, the security 288 functions supporting each slice must operate independently so that 289 an attack or misconfiguration of security in one slice will not 290 prevent proper security function in the other slices. Further, 291 privacy concerns require that traffic from one slice is not 292 delivered to an end point in another slice, and that it should not 293 be possible to determine the nature or characteristics of a slice 294 from any external point. 296 o Management isolation means that each slice must be independently 297 viewed, utilized, and managed as a separate network. Furthermore, 298 it should be possible to prevent the operator of one slice from 299 being able to control, view, or detect any aspect of any other 300 network slice. 302 2.4. Control and Orchestration 304 Orchestration combines and coordinates multiple control methods to 305 provide a single mechanism to operate one or more networks to deliver 306 services. In a network slicing environment, an orchestrator is 307 needed to coordinate disparate processes and resources for creating, 308 managing, and deploying the network slicing service. Two aspects of 309 orchestration are required: 311 o Multi-domain Orchestration: Managing connectivity to set up a 312 network slice across multiple administrative domains. 314 o End-to-end Orchestration: Combining resources for an end-to-end 315 service (e.g., underlay connectivity with firewalling, and 316 guaranteed bandwidth with minimum delay). 318 3. Abstraction and Control of Traffic Engineered (TE) Networks (ACTN) 320 ACTN facilitates end-to-end connectivity and provide virtual 321 connectivity services (such as virtual links and virtual networks) to 322 the user. The ACTN framework [RFC8453] introduces three functional 323 components and two interfaces: 325 o Customer Network Controller (CNC) 327 o Multi-domain Service Coordinator (MDSC) 329 o Provisioning Network Controller (PNC) 331 o CNC-MDSC Interface (CMI) 333 o MDSC-PNC Interface (MPI) 335 RFC 8453 also highlights how: 337 o Abstraction of the underlying network resources is provided to 338 higher-layer applications and consumers. 340 o Virtualization is achieved by selecting resources according to 341 criteria derived from the details and requirements of the 342 consumer, application, or service. 344 o Creation of a virtualized environment is performed to allow 345 operators to view and control multi-domain networks as a single 346 virtualized network. 348 o A network is presented to a consumer as a single virtual network 349 via open and programmable interfaces. 351 The ACTN managed infrastructure consists of traffic engineered 352 network resources. The concept of traffic engineering is broad: it 353 describes the planning and operation of networks using a method of 354 reserving and partitioning of network resources in order to 355 facilitate traffic delivery across a network (see 356 [I-D.ietf-teas-rfc3272bis] for more details). In the context of 357 ACTN, traffic engineering network resources may include: 359 o Statistical packet bandwidth. 361 o Physical forwarding plane sources, such as wavelengths and time 362 slots. 364 o Forwarding and cross-connect capabilities. 366 The ACTN network is "sliced" with consumers each being given a 367 different partial and abstracted topology view of the physical 368 underlay network. 370 3.1. ACTN Virtual Network as a Network Slice 372 To support multiple consumers, each with its own view of and control 373 of a virtual network constructed using a server network, a service 374 provider needs to partition the server network resources to create 375 network slices assigned to each consumer. 377 An ACTN Virtual Network (VN) is a consumer view of a slice of the 378 ACTN-managed infrastructure. It is a network slice that is presented 379 to the consumer by the ACTN provider as a set of abstracted 380 resources. See [I-D.ietf-teas-actn-vn-yang] for a detailed 381 description of ACTN VNs and an overview of how various different 382 types of YANG model are applicable to the ACTN framework. 384 Depending on the agreement between consumer and provider, various VN 385 operations are possible: 387 o Network Slice Creation: A VN could be pre-configured and created 388 through static configuration or through dynamic request and 389 negotiation between consumer and service provider. The VN must 390 meet the network slice requirements specified in the SLA to 391 satisfy the consumer's objectives. 393 o Network Slice Operations: The VN may be modified and deleted based 394 on consumer requests. The consumer can further act upon the VN to 395 manage the consumer's traffic flows across the network slice. 397 o Network Slice View: The VN topology is viewed from the consumer's 398 perspective. This may be the entire VN topology or a collection 399 of tunnels that are expressed as consumer end points, access 400 links, intra domain paths and inter-domain links. 402 [RFC8454] describes a set of functional primitives that support these 403 different ACTN VN operations. 405 3.2. ACTN Virtual Network for Network Slice Aggregation 407 Scaling considerations for IETF network slicing are an important 408 consideration. If the service provider must manage and maintain 409 network state for every network slice then this will quickly limit 410 the number of customer services that can be supported. 412 The importance of network slice aggregation is discussed in 413 [I-D.ietf-teas-enhanced-vpn] and further in 414 [I-D.dong-teas-enhanced-vpn-vtn-scalability]. That work notes the 415 importance of aggregating network slices into groups of similar 416 slices before realizing those aggregates in the network. 418 The same consideration applies to ACTN VNs. But fortunately, ACTN 419 VNs may be arranged hierarchically by recursing the MDSCs so that one 420 VN is realised over another VN. This allows the VNs presented to the 421 customer to be aggregated before they are instantiated in the 422 physical network. 424 3.3. Management Components for ACTN and Network Slicing 426 The ACTN management components (CNC, MDSC, and PNC) and interfaces 427 (CMI and MPI) are introduced in Section 3 and described in detail in 428 [RFC8453]. The management components for network slicing are 429 described in [I-D.ietf-teas-ietf-network-slice-framework] and are 430 known as the consumer orchestration system, the IETF network slice 431 controller (NSC), and the network controller. The network slicing 432 management components are separated by the network slice controller 433 northbound interface (NSC NBI) and the network slice controller 434 southbound interface (NSC SBI). 436 [I-D.ietf-teas-ietf-network-slice-framework] describes the mapping 437 between network slicing management components and ACTN management 438 components. This is presented visually in Figure 1 and provides a 439 useful reference for understanding the material in Section 3.4 and 440 Section 4. 442 +--------------------------------------+ | +-----+ 443 | Consumer orchestration system | =====> | CNC | 444 +--------------------------------------+ | +-----+ 445 ^ ^ 446 | NSC NBI | | CMI 447 v v 448 +-------------------------------------+ | +------+ 449 | IETF Network Slice Controller (NSC) | =====> | MDSC | 450 +-------------------------------------+ | +------+ 451 ^ ^ 452 | NSC SBI | | MPI 453 v v 454 +-------------------------------------+ | +-----+ 455 | Network Controller | =====> | PNC | 456 +-------------------------------------+ | +-----+ 458 Figure 1: Mapping Between IETF Network Slice and ACTN Components 460 3.4. Examples of ACTN Delivering Types of Network Slices 462 The examples that follow build on the ACTN framework to provide 463 control, management, and orchestration for the network slice life- 464 cycle. These network slices utilize common physical infrastructure, 465 and meet specific service-level requirements. 467 Three examples are shown. Each uses ACTN to achieve a different 468 network slicing scenario. All three scenarios can be scaled up in 469 capacity or be subject to topology changes as well as changes of 470 consumer requirements. 472 3.4.1. ACTN Used for Virtual Private Line 474 In the example shown in Figure 2, ACTN provides virtual connections 475 between multiple consumer locations (sites accessed through Customer 476 Edge nodes - CEs). The service is requested by the consumer (via 477 CNC-A) and delivered as a Virtual Private Line (VPL) service. The 478 benefits of this model include: 480 o Automated: the service set-up and operation is managed by the 481 network provider. 483 o Virtual: the private line connectivity is provided from Site A to 484 Site C (VPL1) and from Site B to Site C (VPL2) across the ACTN- 485 managed physical network. 487 o Agile: on-demand adjustments to the connectivity and bandwidth are 488 available according to the consumer's requests. 490 (Consumer VPL Request) 491 : 492 ------- 493 | CNC-A | 494 Boundary ------- 495 Between . . . . . . . . .:. . . . . . . . . . . 496 Consumer & : 497 Network Provider ------ 498 | MDSC | 499 ------ 500 : 501 ----- 502 | PNC | 503 Site A ( ----- ) Site B 504 ----- ( ) ----- 505 | CE1 |========( Physical )========| CE2 | 506 -----\ ( Network ) /----- 507 \ (_______) / 508 \ || / 509 \ || / 510 VPL1 \ || / VPL2 511 \ || / 512 \ || / 513 \ || / 514 \-------------/ 515 | CE3 | 516 ------------- 517 Site C 519 Key: ... ACTN control connectivity 520 === Physical connectivity 521 --- Logical connectivity 523 Figure 2: Virtual Private Line Model 525 3.4.2. ACTN Used for VPN Delivery Model 527 In the example shown in Figure 3, ACTN provides VPN connectivity 528 between two sites across three physical networks. The requirements 529 for the VPN are expressed by the users of the two sites who are the 530 consumers. Their requests are directed to the CNC, and the CNC 531 interacts with the network provider's MDSC. The benefits of this 532 model include: 534 o Provides edge-to-edge VPN multi-access connectivity. 536 o Most of the function is managed by the network provider, with some 537 flexibility delegated to the consumer-managed CNC. 539 -------------- -------------- 540 | Site-A Users | | Site-B Users | 541 -------------- -------------- 542 : : 543 ------------- 544 | CNC | 545 Boundary ------------- 546 Between . . . . . . . . . . . : . . . . . . . . . . . 547 Consumer & : 548 Network Provider : 549 --------------------------------- 550 | MDSC | 551 --------------------------------- 552 : : : 553 : : : 554 ------- ------- ------- 555 | PNC | | PNC | | PNC | 556 ------- ------- ------- 557 : : : 558 : : : 559 ______ --------- --------- --------- ______ 560 < > ( ) ( ) ( ) < > 561 ==( Physical )==( Physical )==( Physical )== 562 < > ( Network ) ( Network ) ( Network ) < > 563 < > ( ) ( ) ( ) < > 564 < > ------- ------- ------- < > 565 < >-----------------------------------------------< > 566 <______> <______> 568 Key: ... ACTN control connectivity 569 === Physical connectivity 570 --- Logical connectivity 572 Figure 3: VPN Model 574 3.4.3. ACTN Used to Deliver a Virtual Consumer Network 576 In the example shown in Figure 4, ACTN provides a virtual network to 577 the consumer. This virtual network is managed by the consumer. The 578 figure shows two virtual networks (Network Slice 1 and Network Slice 579 2) each created for a different consumer under the care of a 580 different CNC. There are two physical networks controlled by 581 separate PNCs. Network Slice 2 is built using resources from just 582 one physical network, while Network Slice 1 is constructed from 583 resources from both physical networks. 585 The benefits of this model include: 587 o The MDSC provides the topology to the consumer so that the 588 consumer can control their network slice to fit their needs. 590 o Applications can interact with their assigned network slices 591 directly. The consumer may implement their own network control 592 methods and traffic prioritization, and manage their own 593 addressing schemes. 595 o Consumers may further slice their virtual networks so that this 596 becomes a recursive model. 598 o Service isolation can be provided through selection of physical 599 networking resources through a combination of efforts of the MSDC 600 and PNC. 602 o The network slice may include nodes with specific capabilities. 603 These can be delivered as Physical Network Functions (PNFs) or 604 Virtual Network Functions (VNFs). 606 ___________ 607 ------------- ( ) 608 | CNC |---------------->( Network ) 609 ------------- ( Slice 2 ) 610 ^ (___________) 611 | ___________ ^ 612 | ------------- ( ) : 613 | | CNC |-------->( Network ) : 614 | ------------- ( Slice 1 ) : 615 | ^ (___________) : 616 | | ^ ^ : 617 Boundary | | : : : 618 Between .|. . . .|. . . . . . . . . . . : . .:. . : . . . 619 Consumer & | | : : : 620 Network | | : : : 621 Provider v v : : : 622 ------------- : :....: 623 | MDSC | : : 624 ------------- : : 625 ^ ------^-- : 626 | ( ) : 627 v ( Physical ) : 628 ------- ( Network ) : 629 | PNC |<------------>( ) ---^----- 630 ------- | ------- ( ) 631 | PNC |- ( Physical ) 632 | |<-------------------------->( Network ) 633 ------- ( ) 634 ------- 636 Key: --- ACTN control connection 637 ... Virtualization/abstraction through slicing 639 Figure 4: Network Slicing 641 4. YANG Models 643 4.1. Network Slice Service Mapping from TE to ACTN VN Models 645 The role of the TE-service mapping model 646 [I-D.ietf-teas-te-service-mapping-yang] is to create a binding 647 relationship across a Layer 3 Service Model (L3SM) [RFC8299], Layer 2 648 Service Model (L2SM) [RFC8466], and TE Tunnel model 649 [I-D.ietf-teas-yang-te], via the generic ACTN Virtual Network (VN) 650 model [I-D.ietf-teas-actn-vn-yang]. 652 The ACTN VN model is a generic virtual network service model that 653 allows consumers to specify a VN (i.e., network slice) that meets the 654 consumer's service objectives with various constraints on how the 655 service is delivered. 657 The TE-service mapping model [I-D.ietf-teas-te-service-mapping-yang] 658 is used to bind the L3SM with TE-specific parameters. This binding 659 facilitates seamless service operation and enables visibility of the 660 underlay TE network. The TE-service model developed in that document 661 can also be extended to support other services including L2SM, and 662 the Layer 1 Connectivity Service Model (L1CSM) 663 [I-D.ietf-ccamp-l1csm-yang] L1CSM network service models. 665 Figure 5 shows the relationship between the models discussed above. 667 --------------- ----------- 668 | L3SM |<=========| | ----------- 669 --------------- augment | |...........>| ACTN VN | 670 --------------- | Augmented | reference ----------- 671 | L2SM |<=========| Service | 672 --------------- augment | Model | ----------- 673 --------------- | |...........>| TE-topo | 674 | L1CSM |<=========| | reference ----------- 675 --------------- augment | | 676 --------------- | | ----------- 677 | TE & Service |--------->| |...........>| TE-tunnel | 678 | Mapping Types | import ----------- reference ----------- 679 --------------- 681 Figure 5: TE-Service Mapping 683 4.2. Interfaces and Yang Models 685 Figure 6 shows the three ACTN components and two ACTN interfaces as 686 listed in Section 3. The figure also shows the Southbound Interface 687 (SBI) between the PNC and the devices in the physical network. That 688 interface might be used to install state on every device in the 689 network, or might instruct a "head-end" node if a control plane is 690 used within the physical network. In the context of [RFC8309], the 691 SBI uses one or more device configuration models. 693 The figure also shows the Network Slice Service Interface. This 694 interface allows a consumer of a service to make requests for 695 delivery of the service, and it facilitates the consumer modifying 696 and monitoring the service. In the context of [RFC8309], this 697 "northbound interface (NBI)" is a customer service interface and uses 698 a service model. 700 When an ACTN system is used to manage the delivery of network slices, 701 a network slice resource model is needed. This model will be used 702 for instantiation, operation, and monitoring of network and function 703 resource slices. The YANG model defined in 704 [I-D.wd-teas-transport-slice-yang] provides a suitable basis for 705 requesting, controlling, and deleting, network slices. 707 ---------- 708 | Consumer | 709 ---------- 710 .......:....... Network Slice Service Interface 711 : 712 ------------- 713 | CNC | 714 ------------- 715 .......:....... CMI 716 : 717 --------------- 718 | MDSC | 719 --------------- 720 .......:....... MPI 721 : 722 ------- 723 | PNC | 724 ------- 725 .......:....... SBI 726 : 727 ---------- 728 ( ) 729 ( Physical ) 730 ( Network ) 731 (________) 733 Figure 6: The Yang Interfaces in Context 735 4.3. ACTN VN Telemetry 737 The ACTN VN KPI telemetry model 738 [I-D.ietf-teas-actn-pm-telemetry-autonomics] provides a way for a 739 consumer to define performance monitoring relevant for its VN/network 740 slice via the NETCONF subscription mechanisms [RFC8639], [RFC8640], 741 or using the equivalent mechanisms in RESTCONF [RFC8641], [RFC8650]. 743 Key characteristics of [I-D.ietf-teas-actn-pm-telemetry-autonomics] 744 include: 746 o An ability to provide scalable VN-level telemetry aggregation 747 based on consumer subscription model for key performance 748 parameters defined by the consumer. 750 o An ability to facilitate proactive re-optimization and 751 reconfiguration of VNs/network slices based on network autonomic 752 traffic engineering scaling configuration mechanism. 754 5. IANA Considerations 756 This document makes no requests for action by IANA. 758 6. Security Considerations 760 Network slicing involves the control of network resources in order to 761 meet the service requirements of consumers. In some deployment 762 models, the consumer is able to directly request modification in the 763 behaviour of resources owned and operated by a service provider. 764 Such changes could significantly affect the service provider's 765 ability to provide services to other consumers. Furthermore, the 766 resources allocated for or consumed by a consumer will normally be 767 billable by the service provider. 769 Therefore, it is crucial that the mechanisms used in any network 770 slicing system allow for authentication of requests, security of 771 those requests, and tracking of resource allocations. 773 It should also be noted that while the partitioning or slicing of 774 resources is virtual, as mentioned in Section 2.3 the consumers 775 expect and require that there is no risk of leakage of data from one 776 slice to another, no transfer of knowledge of the structure or even 777 existence of other slices, and that changes to one slice (under the 778 control of one consumer) should not have detrimental effects on the 779 operation of other slices (whether under control of different or the 780 same consumers) beyond the limits allowed within the SLA. Thus, 781 slices are assumed to be private and to provide the appearance of 782 genuine physical connectivity. 784 Some service providers may offer secure network slices as a service. 785 Such services may claim to include edge-to-edge encryption for the 786 consumer's traffic. However, a consumer should take full 787 responsibility for the privacy and integrity of their traffic and 788 should carefully consider using their own edge-to-edge encryption. 790 ACTN operates using the NETCONF [RFC6241] or RESTCONF [RFC8040] 791 protocols and assumes the security characteristics of those 792 protocols. Deployment models for ACTN should fully explore the 793 authentication and other security aspects before networks start to 794 carry live traffic. 796 7. Acknowledgements 798 Thanks to Qin Wu, Andy Jones, Ramon Casellas, Gert Grammel, and Kiran 799 Makhijani for their insight and useful discussions about network 800 slicing. 802 8. Contributors 804 The following people contributed text to this document. 806 Young Lee 807 Email: younglee.tx@gmail.com 809 Mohamed Boucadair 810 Email: mohamed.boucadair@orange.com 812 Sergio Belotti 813 Email: sergio.belotti@nokia.com 815 Daniele Ceccarelli 816 Email: daniele.ceccarelli@ericsson.com 818 9. Informative References 820 [I-D.dong-teas-enhanced-vpn-vtn-scalability] 821 Dong, J., Li, Z., Qin, F., and G. Yang, "Scalability 822 Considerations for Enhanced VPN (VPN+)", draft-dong-teas- 823 enhanced-vpn-vtn-scalability-01 (work in progress), 824 November 2020. 826 [I-D.ietf-ccamp-l1csm-yang] 827 Lee, Y., Lee, K., Zheng, H., Dios, O., and D. Ceccarelli, 828 "A YANG Data Model for L1 Connectivity Service Model 829 (L1CSM)", draft-ietf-ccamp-l1csm-yang-13 (work in 830 progress), November 2020. 832 [I-D.ietf-teas-actn-pm-telemetry-autonomics] 833 Lee, Y., Dhody, D., Karunanithi, S., Vilata, R., King, D., 834 and D. Ceccarelli, "YANG models for VN/TE Performance 835 Monitoring Telemetry and Scaling Intent Autonomics", 836 draft-ietf-teas-actn-pm-telemetry-autonomics-04 (work in 837 progress), November 2020. 839 [I-D.ietf-teas-actn-vn-yang] 840 Lee, Y., Dhody, D., Ceccarelli, D., Bryskin, I., and B. 841 Yoon, "A YANG Data Model for VN Operation", draft-ietf- 842 teas-actn-vn-yang-10 (work in progress), November 2020. 844 [I-D.ietf-teas-enhanced-vpn] 845 Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A 846 Framework for Enhanced Virtual Private Networks (VPN+) 847 Service", draft-ietf-teas-enhanced-vpn-06 (work in 848 progress), July 2020. 850 [I-D.ietf-teas-ietf-network-slice-definition] 851 Rokui, R., Homma, S., Makhijani, K., Contreras, L., and J. 852 Tantsura, "Definition of IETF Network Slices", draft-ietf- 853 teas-ietf-network-slice-definition-00 (work in progress), 854 January 2021. 856 [I-D.ietf-teas-ietf-network-slice-framework] 857 Gray, E. and J. Drake, "Framework for IETF Network 858 Slices", draft-ietf-teas-ietf-network-slice-framework-00 859 (work in progress), March 2021. 861 [I-D.ietf-teas-rfc3272bis] 862 Farrel, A., "Overview and Principles of Internet Traffic 863 Engineering", draft-ietf-teas-rfc3272bis-10 (work in 864 progress), December 2020. 866 [I-D.ietf-teas-te-service-mapping-yang] 867 Lee, Y., Dhody, D., Fioccola, G., WU, Q., Ceccarelli, D., 868 and J. Tantsura, "Traffic Engineering (TE) and Service 869 Mapping Yang Model", draft-ietf-teas-te-service-mapping- 870 yang-05 (work in progress), November 2020. 872 [I-D.ietf-teas-yang-te] 873 Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin, 874 "A YANG Data Model for Traffic Engineering Tunnels, Label 875 Switched Paths and Interfaces", draft-ietf-teas-yang-te-25 876 (work in progress), July 2020. 878 [I-D.wd-teas-transport-slice-yang] 879 Bo, W., Dhody, D., Han, L., and R. Rokui, "A Yang Data 880 Model for Transport Slice NBI", draft-wd-teas-transport- 881 slice-yang-02 (work in progress), July 2020. 883 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 884 and A. Bierman, Ed., "Network Configuration Protocol 885 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 886 . 888 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 889 Chaining (SFC) Architecture", RFC 7665, 890 DOI 10.17487/RFC7665, October 2015, 891 . 893 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 894 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 895 . 897 [RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki, 898 "YANG Data Model for L3VPN Service Delivery", RFC 8299, 899 DOI 10.17487/RFC8299, January 2018, 900 . 902 [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models 903 Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, 904 . 906 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for 907 Abstraction and Control of TE Networks (ACTN)", RFC 8453, 908 DOI 10.17487/RFC8453, August 2018, 909 . 911 [RFC8454] Lee, Y., Belotti, S., Dhody, D., Ceccarelli, D., and B. 912 Yoon, "Information Model for Abstraction and Control of TE 913 Networks (ACTN)", RFC 8454, DOI 10.17487/RFC8454, 914 September 2018, . 916 [RFC8466] Wen, B., Fioccola, G., Ed., Xie, C., and L. Jalil, "A YANG 917 Data Model for Layer 2 Virtual Private Network (L2VPN) 918 Service Delivery", RFC 8466, DOI 10.17487/RFC8466, October 919 2018, . 921 [RFC8639] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, 922 E., and A. Tripathy, "Subscription to YANG Notifications", 923 RFC 8639, DOI 10.17487/RFC8639, September 2019, 924 . 926 [RFC8640] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, 927 E., and A. Tripathy, "Dynamic Subscription to YANG Events 928 and Datastores over NETCONF", RFC 8640, 929 DOI 10.17487/RFC8640, September 2019, 930 . 932 [RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications 933 for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641, 934 September 2019, . 936 [RFC8650] Voit, E., Rahman, R., Nilsen-Nygaard, E., Clemm, A., and 937 A. Bierman, "Dynamic Subscription to YANG Events and 938 Datastores over RESTCONF", RFC 8650, DOI 10.17487/RFC8650, 939 November 2019, . 941 Authors' Addresses 943 Daniel King 944 Old Dog Consulting 946 Email: daniel@olddog.co.uk 948 John Drake 949 Juniper Networks 951 Email: jdrake@juniper.net 953 Haomian Zheng 954 Huawei Technologies 956 Email: zhenghaomian@huawei.com 958 Adrian Farrel 959 Old Dog Consulting 961 Email: adrian@olddog.co.uk