idnits 2.17.1 draft-ietf-teas-applicability-actn-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 == Line 617 has weird spacing: '...rovider v ...' -- The document date (7 March 2022) is 780 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-26) exists of draft-ietf-ccamp-l1csm-yang-16 == Outdated reference: A later version (-12) exists of draft-ietf-teas-actn-pm-telemetry-autonomics-08 == Outdated reference: A later version (-24) exists of draft-ietf-teas-actn-vn-yang-13 == Outdated reference: A later version (-17) exists of draft-ietf-teas-enhanced-vpn-09 == Outdated reference: A later version (-11) exists of draft-ietf-teas-ietf-network-slice-nbi-yang-01 == Outdated reference: A later version (-25) exists of draft-ietf-teas-ietf-network-slices-08 == Outdated reference: A later version (-27) exists of draft-ietf-teas-rfc3272bis-15 == Outdated reference: A later version (-15) exists of draft-ietf-teas-te-service-mapping-yang-09 == Outdated reference: A later version (-36) exists of draft-ietf-teas-yang-te-29 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: 8 September 2022 Juniper Networks 6 H. Zheng 7 Huawei Technologies 8 A. Farrel 9 Old Dog Consulting 10 7 March 2022 12 Applicability of Abstraction and Control of Traffic Engineered Networks 13 (ACTN) to Network Slicing 14 draft-ietf-teas-applicability-actn-slicing-01 16 Abstract 18 Network abstraction is a technique that can be applied to a network 19 domain to obtain a view of potential connectivity across the network 20 by utilizing a set of policies to select network resources. 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 8 September 2022. 56 Copyright Notice 58 Copyright (c) 2022 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 (https://trustee.ietf.org/ 63 license-info) in effect on the date of publication of this document. 64 Please review these documents carefully, as they describe your rights 65 and restrictions with respect to this document. Code Components 66 extracted from this document must include Revised BSD License text as 67 described in Section 4.e of the Trust Legal Provisions and are 68 provided without warranty as described in the Revised BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 73 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 74 2. Requirements for Network Slicing . . . . . . . . . . . . . . 5 75 2.1. Resource Slicing . . . . . . . . . . . . . . . . . . . . 5 76 2.2. Network Virtualization . . . . . . . . . . . . . . . . . 5 77 2.3. Service Isolation . . . . . . . . . . . . . . . . . . . . 6 78 2.4. Control and Orchestration . . . . . . . . . . . . . . . . 6 79 3. Abstraction and Control of Traffic Engineered (TE) Networks 80 (ACTN) . . . . . . . . . . . . . . . . . . . . . . . . . 7 81 3.1. ACTN Virtual Network as a Network Slice . . . . . . . . . 8 82 3.2. ACTN Virtual Network for and Scaling Network Slices . . . 9 83 3.3. Management Components for ACTN and Network Slicing . . . 9 84 3.4. Examples of ACTN Delivering Types of Network Slices . . . 10 85 3.4.1. ACTN Used for Virtual Private Line . . . . . . . . . 10 86 3.4.2. ACTN Used for VPN Delivery Model . . . . . . . . . . 12 87 3.4.3. ACTN Used to Deliver a Virtual Customer Network . . . 13 88 4. YANG Models . . . . . . . . . . . . . . . . . . . . . . . . . 15 89 4.1. Network Slice Service Mapping from TE to ACTN VN 90 Models . . . . . . . . . . . . . . . . . . . . . . . . . 15 91 4.2. Interfaces and Yang Models . . . . . . . . . . . . . . . 16 92 4.3. ACTN VN Telemetry . . . . . . . . . . . . . . . . . . . . 18 93 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 94 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 95 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 96 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19 97 9. Informative References . . . . . . . . . . . . . . . . . . . 20 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 100 1. Introduction 102 The principles of network resource separation are not new. For 103 years, the concepts of separated overlay and logical (virtual) 104 networking have 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-slices] provides a definitions for 120 network slicing in the context of IETF network technologies. In 121 particular, that document defines the term "IETF Network Slice" to be 122 the generic network slice concept applied to a network that uses IETF 123 technologies. An IETF Network Slice could span multiple technologies 124 (such as IP, MPLS, or optical) and multiple administrative domains. 125 The logical network that is an IETF Network Slice may be kept 126 separate from other concurrent logical networks each with independent 127 control and management: each can be created or modified on demand. 128 Since this document is focused entirely on IETF technologies, it uses 129 the term "network slice" as a more concise expression. Further 130 discussion on the topic of IETF Network Slices and details of how an 131 IETF Network Slice service may be requested and realized as an IETF 132 Network Slice can be found in [I-D.ietf-teas-ietf-network-slices]. 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 network 155 operators to create and supply virtual networks for their customers 156 through the abstraction of the operators' network resources. 158 ACTN is a toolset capable of delivering network slice functionality. 159 This document outlines the application of ACTN and associated 160 enabling technologies to provide network slicing in a network that 161 utilizes IETF TE-based technologies. It describes how the ACTN 162 functional components can be used to support model-driven 163 partitioning of resources into variable-sized bandwidth units to 164 facilitate network sharing and virtualization. Furthermore, the use 165 of model-based interfaces to dynamically request the instantiation of 166 virtual networks can be extended to encompass requesting and 167 instantiation of specific service functions (which may be both 168 physical or virtual), and to partition network resources such as 169 compute resource, storage capability, and access to content. 170 Finally, this document highlights how the ACTN approach might be 171 extended to address the requirements of network slicing where the 172 underlying network is TE-capable. 174 1.1. Terminology 176 As far as is possible, this document re-uses terminology from 177 [I-D.ietf-teas-ietf-network-slices] and [I-D.ietf-teas-enhanced-vpn]. 179 Service Provider: See "Provider" in 180 [I-D.ietf-teas-ietf-network-slices]. 182 Consumer: See [I-D.ietf-teas-ietf-network-slices]. 184 Service Functions (SFs): Components that provide specific functions 185 within a network. SFs are often combined in a specific sequence 186 called a service function chain to deliver services [RFC7665]. 188 Resource: Any feature including connectivity, bufferage, compute, 189 storage, and content delivery that forms part of or can be 190 accessed through a network. Resources may be shared between 191 users, applications, and clients, or they may be dedicated for use 192 by a unique customer. 194 Infrastructure Resources: The hardware and software for hosting and 195 connecting SFs. These resources may include computing hardware, 196 storage capacity, network resources (e.g., links and switching/ 197 routing devices enabling network connectivity), and physical 198 assets for radio access. 200 Service Level Agreement (SLA): See 201 [I-D.ietf-teas-ietf-network-slices]. 203 Service Level Expectation (SLE): See [I-D.ietf-teas-ietf-network-sli 204 ces]. 206 Service Level Objective (SLO): See 207 [I-D.ietf-teas-ietf-network-slices]. 209 IETF Network Slice Service: See [I-D.ietf-teas-ietf-network-slices]. 211 2. Requirements for Network Slicing 213 According to [I-D.ietf-teas-ietf-network-slices] the customer 214 expresses requirements for a particular network slice by specifying 215 what is required rather than how the requirement is to be fulfilled. 216 That is, the customer's view of a network slice is an abstract one 217 expressed as a network slice service request. 219 The concept of network slicing is a key capability to serve a 220 customer with a wide variety of different service needs expressed as 221 SLOs/SLEs in term of latency, reliability, capacity, and service 222 function specific capabilities. 224 This section outlines the key capabilities required to realize 225 network slicing in a TE-enabled IETF technology network. 227 2.1. Resource Slicing 229 Network resources need to be allocated and dedicated for use by a 230 specific network slice, or they may be shared among multiple slices. 231 This allows a flexible approach that can deliver a range of services 232 by partitioning (that is, slicing) the available network resources to 233 make them available to meet the customer's SLA. 235 2.2. Network Virtualization 237 Network virtualization enables the creation of multiple virtual 238 networks that are operationally decoupled from the underlying 239 physical network, and are run on top of it. Slicing enables the 240 creation of virtual networks as customer services. 242 2.3. Service Isolation 244 A customer may request, through their SLA, that changes to the other 245 services delivered by the service provider do not have any negative 246 impact on the delivery of the service. This quality is referred to 247 as "isolation" [I-D.ietf-teas-ietf-network-slices] 248 [I-D.ietf-teas-enhanced-vpn]. 250 Delivery of such service isolation may be achieved in the underlying 251 network by various forms of resource partitioning ranging from 252 dedicated allocation of resources for a specific slice, to sharing or 253 resources with safeguards. 255 Although multiple network slices may utilize resources from a single 256 underlying network, isolation should be understood in terms of the 257 following three categorizations. 259 * Performance isolation requires that service delivery for one 260 network slice does not adversely impact congestion or performance 261 levels of other slices. 263 * Security isolation means that attacks or faults occurring in one 264 slice do not impact on other slices. Moreover, the security 265 functions supporting each slice must operate independently so that 266 an attack or misconfiguration of security in one slice will not 267 prevent proper security function in the other slices. Further, 268 privacy concerns require that traffic from one slice is not 269 delivered to an end point in another slice, and that it should not 270 be possible to determine the nature or characteristics of a slice 271 from any external point. 273 * Management isolation means that each slice must be independently 274 viewed, utilized, and managed as a separate network. Furthermore, 275 it should be possible to prevent the operator of one slice from 276 being able to control, view, or detect any aspect of any other 277 network slice. 279 2.4. Control and Orchestration 281 Orchestration combines and coordinates multiple control methods to 282 provide a single mechanism to operate one or more networks to deliver 283 services. In a network slicing environment, an orchestrator is 284 needed to coordinate disparate processes and resources for creating, 285 managing, and deploying the network slicing service. Two aspects of 286 orchestration are required: 288 * Multi-domain Orchestration: Managing connectivity to set up a 289 network slice across multiple administrative domains. 291 * End-to-end Orchestration: Combining resources for an end-to-end 292 service (e.g., underlay connectivity with firewalling, and 293 guaranteed bandwidth with minimum delay). 295 3. Abstraction and Control of Traffic Engineered (TE) Networks (ACTN) 297 ACTN facilitates end-to-end connectivity and provide virtual 298 connectivity services (such as virtual links and virtual networks) to 299 the user. The ACTN framework [RFC8453] introduces three functional 300 components and two interfaces: 302 * Customer Network Controller (CNC) 304 * Multi-domain Service Coordinator (MDSC) 306 * Provisioning Network Controller (PNC) 308 * CNC-MDSC Interface (CMI) 310 * MDSC-PNC Interface (MPI) 312 RFC 8453 also highlights how: 314 * Abstraction of the underlying network resources is provided to 315 higher-layer applications and customer. 317 * Virtualization is achieved by selecting resources according to 318 criteria derived from the details and requirements of the 319 customer, application, or service. 321 * Creation of a virtualized environment is performed to allow 322 operators to view and control multi-domain networks as a single 323 virtualized network. 325 * A network is presented to a customer as a single virtual network 326 via open and programmable interfaces. 328 The ACTN managed infrastructure consists of traffic engineered 329 network resources. The concept of traffic engineering is broad: it 330 describes the planning and operation of networks using a method of 331 reserving and partitioning of network resources in order to 332 facilitate traffic delivery across a network (see 333 [I-D.ietf-teas-rfc3272bis] for more details). In the context of 334 ACTN, traffic engineering network resources may include: 336 * Statistical packet bandwidth. 338 * Physical forwarding plane sources, such as wavelengths and time 339 slots. 341 * Forwarding and cross-connect capabilities. 343 The ACTN network is "sliced" with each customer being given a 344 different partial and abstracted topology view of the physical 345 underlay network. 347 3.1. ACTN Virtual Network as a Network Slice 349 To support multiple customers, each with its own view of and control 350 of a virtual network constructed using a server network, a service 351 provider needs to partition the network resources to create network 352 slices assigned to each customer. 354 An ACTN Virtual Network (VN) is a customer view of a slice of the 355 ACTN-managed infrastructure. It is a network slice that is presented 356 to the customer by the ACTN provider as a set of abstracted 357 resources. See [I-D.ietf-teas-actn-vn-yang] for a detailed 358 description of ACTN VNs and an overview of how various different 359 types of YANG model are applicable to the ACTN framework. 361 Depending on the agreement between customer and provider, various VN 362 operations are possible: 364 * Network Slice Creation: A VN could be pre-configured and created 365 through static configuration or through dynamic request and 366 negotiation between customer and service provider. The VN must 367 meet the network slice requirements specified in the SLA to 368 satisfy the customer's objectives. 370 * Network Slice Operations: The VN may be modified and deleted based 371 on direct customer requests. The customer can further act upon 372 the VN to manage the their traffic flows across the network slice. 374 * Network Slice View: The VN topology is viewed from the customer's 375 perspective. This may be the entire VN topology, or a collection 376 of tunnels that are expressed as customer end points, access 377 links, intra domain paths and inter-domain links. 379 [RFC8454] describes a set of functional primitives that support these 380 different ACTN VN operations. 382 3.2. ACTN Virtual Network for and Scaling Network Slices 384 Scaling considerations for network slicing are an important 385 consideration. If the service provider must manage and maintain 386 state in the core of the network for every network slice then this 387 will quickly limit the number of customer services that can be 388 supported. 390 The importance of scalability for network slices is discussed in 391 [I-D.ietf-teas-enhanced-vpn] and further in 392 [I-D.dong-teas-enhanced-vpn-vtn-scalability]. That work notes the 393 importance of collecting network slices or their composite 394 connectivity constructs into groups of that require similar treatment 395 in the network before realizing those groups in the network. 397 The same consideration applies to ACTN VNs. But fortunately, ACTN 398 VNs may be arranged hierarchically by recursing the MDSCs so that one 399 VN is realized over another VN. This allows the VNs presented to the 400 customer to be aggregated before they are instantiated in the 401 physical network. 403 3.3. Management Components for ACTN and Network Slicing 405 The ACTN management components (CNC, MDSC, and PNC) and interfaces 406 (CMI and MPI) are introduced in Section 3 and described in detail in 407 [RFC8453]. The management components for network slicing are 408 described in [I-D.ietf-teas-ietf-network-slices] and are known as the 409 customer orchestration system, the IETF Network Slice Controller 410 (NSC), and the network controller. The network slicing management 411 components are separated by the Network Slice Service Interface and 412 the Network Configuration Interface, modeling the architecture 413 described in [RFC8309]. 415 The mapping between network slicing management components and ACTN 416 management components is presented visually in Figure 1 and provides 417 a reference for understanding the material in Section 3.4 and 418 Section 4. 420 +---------------------------------------+ 421 | Customer operation system | | +-----+ 422 | (e.g E2E network slice orchestrator, | =====> | CNC | 423 | customer network management system) | | +-----+ 424 +---------------------------------------+ ^ 425 A | | 426 IETF Network Slice | | CMI 427 Service Interface | | | 428 V v 429 +---------------------------------------+ | +------+ 430 | IETF Network Slice Controller (NSC) | =====> | MDSC | 431 +---------------------------------------+ | +------+ 432 A ^ 433 Network | | | 434 Configuration | | MPI 435 Interface | | | 436 V v 437 +---------------------------------------+ | +-----+ 438 | Network Controllers | =====> | PNC | 439 +---------------------------------------+ | +-----+ 441 Figure 1: Mapping Between IETF Network Slice and ACTN Management 442 Components 444 3.4. Examples of ACTN Delivering Types of Network Slices 446 The examples that follow build on the ACTN framework to provide 447 control, management, and orchestration for the network slice life- 448 cycle. These network slices utilize common physical infrastructure, 449 and meet specific service-level requirements. 451 Three examples are shown. Each uses ACTN to achieve a different 452 network slicing scenario. All three scenarios can be scaled up in 453 capacity or be subject to topology changes as well as changes of 454 customer requirements. 456 3.4.1. ACTN Used for Virtual Private Line 458 In the example shown in Figure 2, ACTN provides virtual connections 459 between multiple customer locations (sites accessed through Customer 460 Edge nodes - CEs). The service is requested by the customer (via 461 CNC-A) and delivered as a Virtual Private Line (VPL) service. The 462 benefits of this model include the following. 464 * Automated: The service set-up and operation is managed by the 465 network provider. 467 * Virtual: The private line connectivity is provided from Site A to 468 Site C (VPL1) and from Site B to Site C (VPL2) across the ACTN- 469 managed physical network. 471 * Agile: On-demand adjustments to the connectivity and bandwidth are 472 available according to the customer's requests. 474 In terms of network slicing concept as defined in 475 [I-D.ietf-teas-ietf-network-slices], in this example the customer 476 requests a single network slice with two pairs of point-to-point 477 connectivity constructs between the service demarcation points CE1 478 and CE3, and CE2 and CE3 with each pair comprising one connectivity 479 construct in each direction. 481 (Customer VPL Request) 482 : 483 ------- 484 | CNC-A | 485 Boundary ------- 486 Between . . . . . . . . .:. . . . . . . . . . . 487 Customer & : 488 Network Provider ------ 489 | MDSC | 490 ------ 491 : 492 ----- 493 | PNC | 494 Site A ( ----- ) Site B 495 ----- ( ) ----- 496 | CE1 |========( Physical )========| CE2 | 497 -----\ ( Network ) /----- 498 \ (_______) / 499 \ || / 500 \ || / 501 VPL1 \ || / VPL2 502 \ || / 503 \ || / 504 \ || / 505 \-------------/ 506 | CE3 | 507 ------------- 508 Site C 510 Key: ... ACTN control connectivity 511 === Physical connectivity 512 --- Logical connectivity 513 Figure 2: Virtual Private Line Model 515 3.4.2. ACTN Used for VPN Delivery Model 517 In the example shown in Figure 3, ACTN provides VPN connectivity 518 between two sites across three physical networks. The requirements 519 for the VPN are expressed by the users of the two sites. The request 520 is directed to the CNC, and the CNC interacts with the network 521 provider's MDSC. The benefits of this model include are as follows. 523 * Provides edge-to-edge VPN multi-access connectivity. 525 * Most of the function is managed by the network provider, with some 526 flexibility delegated to the customer-managed CNC. 528 In terms of network slicing concept as defined in 529 [I-D.ietf-teas-ietf-network-slices], in this example the customer 530 requests a single network slice with a pair of point-to-point 531 connectivity constructs (one in each direction) between the service 532 demarcation points at site A and site B. The customer is unaware 533 that the service is delivered over multiple physical networks. 535 -------------- -------------- 536 | Site-A Users | | Site-B Users | 537 -------------- -------------- 538 : : 539 ------------- 540 | CNC | 541 Boundary ------------- 542 Between . . . . . . . . . . . : . . . . . . . . . . . 543 Customer & : 544 Network Provider : 545 --------------------------------- 546 | MDSC | 547 --------------------------------- 548 : : : 549 : : : 550 ------- ------- ------- 551 | PNC | | PNC | | PNC | 552 ------- ------- ------- 553 : : : 554 : : : 555 ______ --------- --------- --------- ______ 556 < > ( ) ( ) ( ) < > 557 ==( Physical )==( Physical )==( Physical )== 558 < > ( Network ) ( Network ) ( Network ) < > 559 < > ( ) ( ) ( ) < > 560 < > ------- ------- ------- < > 561 < >-----------------------------------------------< > 562 <______> <______> 564 Key: ... ACTN control connectivity 565 === Physical connectivity 566 --- Logical connectivity 568 Figure 3: VPN Model 570 3.4.3. ACTN Used to Deliver a Virtual Customer Network 572 In the example shown in Figure 4, ACTN provides a virtual network to 573 the customer. This virtual network is managed by the customer. The 574 figure shows two virtual networks (Network Slice 1 and Network Slice 575 2) each created for a different customer under the care of a 576 different CNC. There are two physical networks controlled by 577 separate PNCs. Network Slice 2 is built using resources from just 578 one physical network, while Network Slice 1 is constructed from 579 resources from both physical networks. 581 The benefits of this model include the following. 583 * The MDSC provides the topology to the customer so that the 584 customer can control their network slice to fit their needs. 586 * Applications can interact with their assigned network slices 587 directly. The customer may implement their own network control 588 methods and traffic prioritization, and manage their own 589 addressing schemes. 591 * Customers may further slice their virtual networks so that this 592 becomes a recursive model. 594 * Service isolation can be provided through selection of physical 595 networking resources through a combination of efforts of the MSDC 596 and PNC. 598 * The network slice may include nodes with specific capabilities. 599 These can be delivered as Physical Network Functions (PNFs) or 600 Virtual Network Functions (VNFs). 602 ___________ 603 ------------- ( ) 604 | CNC |---------------->( Network ) 605 ------------- ( Slice 2 ) 606 ^ (___________) 607 | ___________ ^ 608 | ------------- ( ) : 609 | | CNC |-------->( Network ) : 610 | ------------- ( Slice 1 ) : 611 | ^ (___________) : 612 | | ^ ^ : 613 Boundary | | : : : 614 Between .|. . . .|. . . . . . . . . . . : . .:. . : . . . 615 Customer & | | : : : 616 Network | | : : : 617 Provider v v : : : 618 ------------- : :....: 619 | MDSC | : : 620 ------------- : : 621 ^ ------^-- : 622 | ( ) : 623 v ( Physical ) : 624 ------- ( Network ) : 625 | PNC |<------------>( ) ---^----- 626 ------- | ------- ( ) 627 | PNC |- ( Physical ) 628 | |<-------------------------->( Network ) 629 ------- ( ) 630 ------- 632 Key: --- ACTN control connection 633 ... Virtualization/abstraction through slicing 635 Figure 4: Network Slicing 637 4. YANG Models 639 4.1. Network Slice Service Mapping from TE to ACTN VN Models 641 The role of the TE-service mapping model 642 [I-D.ietf-teas-te-service-mapping-yang] is to create a binding 643 relationship across a Layer 3 Service Model (L3SM) [RFC8299], Layer 2 644 Service Model (L2SM) [RFC8466], and TE Tunnel model 645 [I-D.ietf-teas-yang-te], via the generic ACTN Virtual Network (VN) 646 model [I-D.ietf-teas-actn-vn-yang]. 648 The ACTN VN model is a generic virtual network service model that 649 allows customers to specify a VN that meets the customer's service 650 objectives with various constraints on how the service is delivered. 651 A request for a network slice service may be mapped directly to a 652 request for a VN. 654 The TE-service mapping model [I-D.ietf-teas-te-service-mapping-yang] 655 is used to bind the L3SM with TE-specific parameters. This binding 656 facilitates seamless service operation and enables visibility of the 657 underlay TE network. The TE-service model developed in that document 658 can also be extended to support other services including L2SM, and 659 the Layer 1 Connectivity Service Model (L1CSM) 660 [I-D.ietf-ccamp-l1csm-yang] L1CSM network service models. 662 Figure 5 shows the relationship between the models discussed above. 664 --------------- ----------- 665 | L3SM |<=========| | ----------- 666 --------------- augment | |...........>| ACTN VN | 667 --------------- | Augmented | reference ----------- 668 | L2SM |<=========| Service | 669 --------------- augment | Model | ----------- 670 --------------- | |...........>| TE-topo | 671 | L1CSM |<=========| | reference ----------- 672 --------------- augment | | 673 --------------- | | ----------- 674 | TE & Service |--------->| |...........>| TE-tunnel | 675 | Mapping Types | import ----------- reference ----------- 676 --------------- 678 Figure 5: TE-Service Mapping 680 4.2. Interfaces and Yang Models 682 Figure 6 shows the three ACTN components and two ACTN interfaces as 683 listed in Section 3. The figure also shows the Device Configuration 684 Interface between the PNC and the devices in the physical network. 685 That interface might be used to install state on every device in the 686 network, or might instruct a "head-end" node when a control plane is 687 used within the physical network. In the context of [RFC8309], the 688 Device Configuration Interface uses one or more device configuration 689 models. 691 The figure also shows the Network Slice Service Interface. This 692 interface allows a customer to make requests for delivery of the 693 service, and it facilitates the customer modifying and monitoring the 694 service. In the context of [RFC8309], this is a customer service 695 interface and uses a service model. 697 When an ACTN system is used to manage the delivery of network slices, 698 a network slice resource model is needed. This model will be used 699 for instantiation, operation, and monitoring of network and function 700 resource slices. The YANG model defined in 701 [I-D.ietf-teas-ietf-network-slice-nbi-yang] provides a suitable basis 702 for requesting, controlling, and deleting, network slices. 704 ---------- 705 | Customer | 706 ---------- 707 .......:....... Network Slice Service Interface 708 : 709 ------------- 710 | CNC | 711 ------------- 712 .......:....... CMI 713 : 714 --------------- 715 | MDSC | 716 --------------- 717 .......:....... MPI 718 : 719 ------- 720 | PNC | 721 ------- 722 .......:....... Device Configuration Interface 723 : 724 ---------- 725 ( ) 726 ( Physical ) 727 ( Network ) 728 (________) 730 Figure 6: The Yang Interfaces in Context 732 4.3. ACTN VN Telemetry 734 The ACTN VN KPI telemetry model 735 [I-D.ietf-teas-actn-pm-telemetry-autonomics] provides a way for a 736 customer to define performance monitoring relevant for its VN/network 737 slice via the NETCONF subscription mechanisms [RFC8639], [RFC8640], 738 or using the equivalent mechanisms in RESTCONF [RFC8641], [RFC8650]. 740 Key characteristics of [I-D.ietf-teas-actn-pm-telemetry-autonomics] 741 include the following. 743 * An ability to provide scalable VN-level telemetry aggregation 744 based on a customer subscription model for key performance 745 parameters defined by the customer. 747 * An ability to facilitate proactive re-optimization and 748 reconfiguration of VNs/network slices based on autonomic network 749 traffic engineering scaling configuration mechanisms. 751 5. IANA Considerations 753 This document makes no requests for action by IANA. 755 6. Security Considerations 757 Network slicing involves the control of network resources in order to 758 meet the service requirements of customers. In some deployment 759 models using ACTN, the customer is able to directly request 760 modification in the behaviour of resources owned and operated by a 761 service provider. Such changes could significantly affect the 762 service provider's ability to provide services to other customers. 763 Furthermore, the resources allocated for or consumed by a customer 764 will normally be billable by the service provider. 766 Therefore, it is crucial that the mechanisms used in any network 767 slicing system allow for authentication of requests, security of 768 those requests, and tracking of resource allocations. 770 It should also be noted that while the partitioning or slicing of 771 resources is virtual, as mentioned in Section 2.3 the customers 772 expect and require that there is no risk of leakage of data from one 773 slice to another, no transfer of knowledge of the structure or even 774 existence of other slices. Further, in some service requests, there 775 is an expectation that changes to one slice (under the control of one 776 customer) should not have detrimental effects on the operation of 777 other slices (whether under control of different or the same 778 customers) even within the limits allowed within the SLA. Thus, 779 slices are assumed to be private and to provide the appearance of 780 genuine physical connectivity. 782 Some service providers may offer secure network slices as a service. 783 Such services may claim to include edge-to-edge encryption for the 784 customer's traffic. However, a customer should take full 785 responsibility for the privacy and integrity of their traffic and 786 should carefully consider using their own edge-to-edge encryption. 788 ACTN operates using the NETCONF [RFC6241] or RESTCONF [RFC8040] 789 protocols and assumes the security characteristics of those 790 protocols. Deployment models for ACTN should fully explore the 791 authentication and other security aspects before networks start to 792 carry live traffic. 794 7. Acknowledgements 796 Thanks to Qin Wu, Andy Jones, Ramon Casellas, Gert Grammel, and Kiran 797 Makhijani for their insight and useful discussions about network 798 slicing. 800 This work is partially supported by the European Commission under 801 Horizon 2020 grant agreement number 101015857 Secured autonomic 802 traffic management for a Tera of SDN flows (Teraflow). 804 8. Contributors 806 The following people contributed text to this document. 808 Young Lee 809 Email: younglee.tx@gmail.com 811 Mohamed Boucadair 812 Email: mohamed.boucadair@orange.com 814 Sergio Belotti 815 Email: sergio.belotti@nokia.com 817 Daniele Ceccarelli 818 Email: daniele.ceccarelli@ericsson.com 820 9. Informative References 822 [I-D.dong-teas-enhanced-vpn-vtn-scalability] 823 Dong, J., Li, Z., Gong, L., Yang, G., Guichard, J. N., 824 Mishra, G., and F. Qin, "Scalability Considerations for 825 Enhanced VPN (VPN+)", Work in Progress, Internet-Draft, 826 draft-dong-teas-enhanced-vpn-vtn-scalability-04, 25 827 October 2021, . 830 [I-D.ietf-ccamp-l1csm-yang] 831 Lee, Y., Lee, K., Zheng, H., Dios, O. G. D., and D. 832 Ceccarelli, "A YANG Data Model for L1 Connectivity Service 833 Model (L1CSM)", Work in Progress, Internet-Draft, draft- 834 ietf-ccamp-l1csm-yang-16, 13 December 2021, 835 . 838 [I-D.ietf-teas-actn-pm-telemetry-autonomics] 839 Lee, Y., Dhody, D., Karunanithi, S., Vilalta, R., King, 840 D., and D. Ceccarelli, "YANG models for Virtual Network 841 (VN)/TE Performance Monitoring Telemetry and Scaling 842 Intent Autonomics", Work in Progress, Internet-Draft, 843 draft-ietf-teas-actn-pm-telemetry-autonomics-08, 7 March 844 2022, . 847 [I-D.ietf-teas-actn-vn-yang] 848 Lee, Y., Dhody, D., Ceccarelli, D., Bryskin, I., and B. Y. 849 Yoon, "A YANG Data Model for VN Operation", Work in 850 Progress, Internet-Draft, draft-ietf-teas-actn-vn-yang-13, 851 23 October 2021, . 854 [I-D.ietf-teas-enhanced-vpn] 855 Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A 856 Framework for Enhanced Virtual Private Network (VPN+) 857 Services", Work in Progress, Internet-Draft, draft-ietf- 858 teas-enhanced-vpn-09, 25 October 2021, 859 . 862 [I-D.ietf-teas-ietf-network-slice-nbi-yang] 863 Wu, B., Dhody, D., Rokui, R., Saad, T., and L. Han, "IETF 864 Network Slice Service YANG Model", Work in Progress, 865 Internet-Draft, draft-ietf-teas-ietf-network-slice-nbi- 866 yang-01, 4 March 2022, 867 . 870 [I-D.ietf-teas-ietf-network-slices] 871 Farrel, A., Drake, J., Rokui, R., Homma, S., Makhijani, 872 K., Contreras, L. M., and J. Tantsura, "Framework for IETF 873 Network Slices", Work in Progress, Internet-Draft, draft- 874 ietf-teas-ietf-network-slices-08, 6 March 2022, 875 . 878 [I-D.ietf-teas-rfc3272bis] 879 Farrel, A., "Overview and Principles of Internet Traffic 880 Engineering", Work in Progress, Internet-Draft, draft- 881 ietf-teas-rfc3272bis-15, 24 February 2022, 882 . 885 [I-D.ietf-teas-te-service-mapping-yang] 886 Lee, Y., Dhody, D., Fioccola, G., Wu, Q., Ceccarelli, D., 887 and J. Tantsura, "Traffic Engineering (TE) and Service 888 Mapping YANG Model", Work in Progress, Internet-Draft, 889 draft-ietf-teas-te-service-mapping-yang-09, 24 October 890 2021, . 893 [I-D.ietf-teas-yang-te] 894 Saad, T., Gandhi, R., Liu, X., Beeram, V. P., Bryskin, I., 895 and O. G. D. Dios, "A YANG Data Model for Traffic 896 Engineering Tunnels, Label Switched Paths and Interfaces", 897 Work in Progress, Internet-Draft, draft-ietf-teas-yang-te- 898 29, 7 February 2022, 899 . 902 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 903 and A. Bierman, Ed., "Network Configuration Protocol 904 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 905 . 907 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 908 Chaining (SFC) Architecture", RFC 7665, 909 DOI 10.17487/RFC7665, October 2015, 910 . 912 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 913 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 914 . 916 [RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki, 917 "YANG Data Model for L3VPN Service Delivery", RFC 8299, 918 DOI 10.17487/RFC8299, January 2018, 919 . 921 [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models 922 Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, 923 . 925 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for 926 Abstraction and Control of TE Networks (ACTN)", RFC 8453, 927 DOI 10.17487/RFC8453, August 2018, 928 . 930 [RFC8454] Lee, Y., Belotti, S., Dhody, D., Ceccarelli, D., and B. 931 Yoon, "Information Model for Abstraction and Control of TE 932 Networks (ACTN)", RFC 8454, DOI 10.17487/RFC8454, 933 September 2018, . 935 [RFC8466] Wen, B., Fioccola, G., Ed., Xie, C., and L. Jalil, "A YANG 936 Data Model for Layer 2 Virtual Private Network (L2VPN) 937 Service Delivery", RFC 8466, DOI 10.17487/RFC8466, October 938 2018, . 940 [RFC8639] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, 941 E., and A. Tripathy, "Subscription to YANG Notifications", 942 RFC 8639, DOI 10.17487/RFC8639, September 2019, 943 . 945 [RFC8640] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, 946 E., and A. Tripathy, "Dynamic Subscription to YANG Events 947 and Datastores over NETCONF", RFC 8640, 948 DOI 10.17487/RFC8640, September 2019, 949 . 951 [RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications 952 for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641, 953 September 2019, . 955 [RFC8650] Voit, E., Rahman, R., Nilsen-Nygaard, E., Clemm, A., and 956 A. Bierman, "Dynamic Subscription to YANG Events and 957 Datastores over RESTCONF", RFC 8650, DOI 10.17487/RFC8650, 958 November 2019, . 960 Authors' Addresses 962 Daniel King 963 Old Dog Consulting 964 Email: daniel@olddog.co.uk 966 John Drake 967 Juniper Networks 968 Email: jdrake@juniper.net 970 Haomian Zheng 971 Huawei Technologies 972 Email: zhenghaomian@huawei.com 974 Adrian Farrel 975 Old Dog Consulting 976 Email: adrian@olddog.co.uk