idnits 2.17.1 draft-king-teas-applicability-actn-slicing-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 2, 2020) is 1301 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-12 == Outdated reference: A later version (-12) exists of draft-ietf-teas-actn-pm-telemetry-autonomics-03 == Outdated reference: A later version (-24) exists of draft-ietf-teas-actn-vn-yang-09 == Outdated reference: A later version (-17) exists of draft-ietf-teas-enhanced-vpn-06 == Outdated reference: A later version (-27) exists of draft-ietf-teas-rfc3272bis-01 == Outdated reference: A later version (-15) exists of draft-ietf-teas-te-service-mapping-yang-04 == Outdated reference: A later version (-36) exists of draft-ietf-teas-yang-te-25 == Outdated reference: A later version (-05) exists of draft-nsdt-teas-ns-framework-04 -- Obsolete informational reference (is this intentional?): RFC 8049 (Obsoleted by RFC 8299) Summary: 0 errors (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). 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: April 5, 2021 Juniper Networks 6 H. Zheng 7 Huawei Technologies 8 October 2, 2020 10 Applicability of Abstraction and Control of Traffic Engineered Networks 11 (ACTN) to Network Slicing 12 draft-king-teas-applicability-actn-slicing-08 14 Abstract 16 Network abstraction is a technique that can be applied to a network 17 domain that utilizes a set of policies to select network resources 18 and obtain a view of potential connectivity across the network. 20 Network slicing is an approach to network operations that builds on 21 the concept of network abstraction to provide programmability, 22 flexibility, and modularity. It may use techniques such as Software 23 Defined Networking (SDN) and Network Function Virtualization (NFV) to 24 create multiple logical or virtual networks, each tailored for a set 25 of services share the same set of requirements. 27 Abstraction and Control of Traffic Engineered Networks (ACTN) is 28 described in RFC 8453. It defines an SDN-based architecture that 29 relies on the concept of network and service abstraction to detach 30 network and service control from the underlying data plane. 32 This document outlines the applicability of ACTN to network slicing 33 in a Traffic Engineering (TE) network that utilizes IETF technology. 34 It also identifies the features of network slicing not currently 35 within the scope of ACTN, and indicates where ACTN might be extended. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at https://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on April 5, 2021. 54 Copyright Notice 56 Copyright (c) 2020 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (https://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 72 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 73 2. Requirements for Network Slicing . . . . . . . . . . . . . . 6 74 2.1. Resource Slicing . . . . . . . . . . . . . . . . . . . . 6 75 2.2. Service Isolation . . . . . . . . . . . . . . . . . . . . 6 76 2.3. Network Virtualization . . . . . . . . . . . . . . . . . 7 77 2.4. Control and Orchestration . . . . . . . . . . . . . . . . 7 78 3. Abstraction and Control of Traffic Engineered (TE) Networks 79 (ACTN) . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 80 3.1. ACTN Virtual Network as a Network Slice . . . . . . . . . 8 81 3.2. Examples of ACTN Delivering Types of Network Slices . . . 9 82 3.2.1. ACTN Used for Virtual Private Line Model . . . . . . 9 83 3.2.2. ACTN Used for VPN Delivery Model . . . . . . . . . . 10 84 3.2.3. ACTN Used to Deliver a Virtual Consumer Network . . . 11 85 4. YANG Models . . . . . . . . . . . . . . . . . . . . . . . . . 13 86 4.1. Network Slice Service Mapping from TE to ACTN VN Models . 13 87 4.2. Network Slice NBI Model . . . . . . . . . . . . . . . . . 14 88 4.3. ACTN VN Telemetry . . . . . . . . . . . . . . . . . . . . 15 89 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 90 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 91 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 92 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17 93 9. Informative References . . . . . . . . . . . . . . . . . . . 17 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 96 1. Introduction 98 The principles of network resource separation are not new. For 99 years, separated overlay and logical (virtual) networking have 100 existed, allowing multiple services to be deployed over a single 101 physical network comprised of single or multiple layers. However, 102 several key differences exist that differentiate overlay and virtual 103 networking from network slicing. 105 A network slice is a virtual (that is, logical) network with its own 106 network topology and a set of network resources that are used to 107 provide connectivity that conforms to a specific Service Level 108 Agreement (SLA) or set of Service Level Objectives (SLOs). The 109 network resources used to realize a network slice belong to the 110 network that is sliced. The resources may be assigned and dedicated 111 to an individual slice, or they may be shared with other slices 112 enabling different degrees of service guarantee and providing 113 different levels of isolaiton between the traffic in each slice. 114 Further dicussion on network slicing can be found in 115 [I-D.nsdt-teas-ns-framework]. 117 The term "Transport Network Slice" is used in some documentation to 118 describe a network slice that is used to support another network 119 service by carrying traffic across one or more underlay networks. A 120 transport network slice could span multiple technologies (such as IP, 121 MPLS, or optical) and multiple administrative domains. The logical 122 network that is a transport network slice may be kept separate from 123 other concurrent logical networks each with independent control and 124 management. Each can be created or modified on demand. A transport 125 network slice is just a special application of a network slice: this 126 document will concern itself with the more general case of a network 127 slice. 129 At one end of the spectrum, a virtual private wire or a virtual 130 private network (VPN) may be used to build a network slice. In these 131 cases, the network slices do not require the service provider to 132 isolate network resources for the provision of the service - the 133 service is "virtual". 135 At the other end of the spectrum there may be a detailed description 136 of a complex service that will meet the needs of a set of 137 applications with connectivity and service function requirements that 138 may include compute resource, storage capability, and access to 139 content. Such a service may be requested dynamically (that is, 140 instantiated when an application needs it, and released when the 141 application no longer needs it), and modified as the needs of the 142 application change. This type of enhanced VPN is described in more 143 detail in [I-D.ietf-teas-enhanced-vpn]. 145 Abstraction and Control of TE Networks (ACTN) [RFC8453] is a 146 framework that facilitates the abstraction of underlying network 147 resources to higher-layer applications and that allows nework 148 operators to create virtual networks for their customers through the 149 abstraction of the operators' network resources. ACTN is described 150 further in Section 3. 152 This document outlines the application of ACTN and associated 153 enabling technologies to provide network slicing in a network that 154 utilizes IETF technologies such as IP, MPLS, or GMPLS. It describes 155 how the ACTN functional components can be used to support model- 156 driven partitioning of variable-sized bandwidth to facilitate network 157 sharing and virtualization. Furthermore, the use of model-based 158 interfaces to dynamically request the instantiation of virtual 159 networks can be extended to encompass requesting and instantiation of 160 specific service functions (which may be both physical or virtual), 161 and to partition network resources such as compute resource, storage 162 capability, and access to content. 164 Various efforts within the IETF are investigating the concept of 165 network slicing (for example, [I-D.nsdt-teas-ns-framework]) and 166 investigate the applicability of IETF protocols to the delivery of 167 network slicing (for example, [I-D.ietf-teas-enhanced-vpn]). This 168 document highlights how the ACTN approach might be extended to 169 address the requirements of network slicing where the underlying 170 network is TE-capable. It is not the intention that this work 171 contradicts or competes with other IETF work. 173 1.1. Terminology 175 This document uses the following terminology. Many of these terms 176 are in common usage in other work in the IETF and do not always have 177 consistent meanings (see for example, [I-D.ietf-teas-enhanced-vpn] 178 and [I-D.nsdt-teas-ns-framework]). The terms defined below are 179 intended to give context and meaning for use in this document only 180 and do not force wider applicability. As other work matures, it is 181 hoped that the terminology will converge. 183 Service Provider: A server network or collection of server networks. 184 The persons or organization responsible for operating such 185 networks. 187 Consumer: Any application, client network, or customer of a service 188 provider. Note that the ACTN framework [RFC8453] refers to the 189 consumer of a network service as a 'customer' because it will 190 often be the case that a VPN consumer is a customer of the 191 operator of the core network that delivers the service. In the 192 context of a network slice, the consumer may well be a customer, 193 but might also be a client network of the service provider (which 194 could also be an internal organization of the service provider), 195 or an application that engineers traffic in the network. 197 Service Functions (SFs): Components that provide specific functions 198 within a network. SFs are often combined in a specific sequence 199 called a service function chain to deliver services [RFC7665]. 201 Resource: Any feature including connectivity, compute, storage, and 202 content delivery that forms part of or can be accessed through a 203 network. Resources may be shared between users, applications, and 204 clients, or they may be dedicated for use by a unique consumer. 206 Infrastructure Resources: The hardware and software for hosting and 207 connecting SFs. These resources may include computing hardware, 208 storage capacity, network resources (e.g., links and switching/ 209 routing devices enabling network connectivity), and physical 210 assets for radio access. 212 Service Level Agreement (SLA): An agreement between a consumer and 213 network provider that describes the quality with which features 214 and functions are to be delivered. It may include measures of 215 bandwidth, latency, and jitter; the types of service (such as 216 firewalls or billing) to be provided; the location, nature, and 217 quantities of services (such as the amount and location of compute 218 resources and the accelerators required). SLAs may be described 219 as a set of Service Level Objectives (SLOs), each setting 220 constraints on particular elements of the service. 222 Network Slice: A network slice is a virtual (that is, logical) 223 network with its own network topology and a set of network 224 resources that are used to provide connectivity that conforms to 225 an SLA or set of SLOs. The resources may be assigned and 226 dedicated to an individual slice, or they may be shared with other 227 slices enabling different degrees of service guarantee and 228 providing different levels of isolaiton between the traffic in 229 each slice. A slice could span multiple technologies (such as IP, 230 MPLS, or optical) and administrative domains. 232 Transport Network Slice: A network slice that is used to support 233 another network service by carrying traffic across one or more 234 networks. 236 Network Slice Service: An agreement between a consumer and a service 237 provider to deliver network resources according to a specific 238 service level agreement. 240 2. Requirements for Network Slicing 242 The concept of network slicing is a key capability to serve consumers 243 with a wide variety of different service needs expressed in term of 244 latency, reliability, capacity, and service function specific 245 capabilities (SLOs). 247 This section outlines the key capabilities required to realize 248 network slicing in an IETF technology network. Consideration of 249 slicing in other technology networks (such as radio access networks) 250 is out of scope. 252 2.1. Resource Slicing 254 Network resources need to be allocated and dedicated for use by a 255 specific network slice, or they may be shared among multiple slices. 256 This allows a flexible approach that can deliver a range of services 257 by partitioning (that is, slicing) the available network resources to 258 make them available to meet the consumer's SLA. 260 2.2. Service Isolation 262 A consumer may request, through their SLA, that the service delivered 263 to them is isolated from any other services delivered to any other 264 consumers. That is, the SLA may request that changes to the other 265 services do not have any negative impact on the delivery of the 266 service. 268 Delivery of such service isolation may be achieved in the underlying 269 network by various forms of resource partitioning ranging from 270 dedicated allocation of resources for a specific slice, to sharing or 271 resources with safeguards. 273 Although multiple network slices may utilize resources from a single 274 underlying network, isolation should be understood in terms of the 275 following three categorisations. 277 o Performance isolation requires that service delivery for one 278 network slice does not adversely impact congestion or performance 279 levels of other slices. 281 o Security isolation means that attacks or faults occurring in one 282 slice do not impact on other slices. Moreover, the security 283 functions supporting each slice must operate independently so that 284 an attack or misconfiguration of security in one slice will not 285 prevent proper security function in the other slices. 287 o Management isolation means that each slice must be independently 288 viewed, utilized and managed as a separate network. Furthermore, 289 it should be possible to prevent the operator of one slice from 290 being able to control, view, or detect any aspect of any other 291 network slice. 293 2.3. Network Virtualization 295 Network virtualization enables the creation of multiple virtual 296 networks that are operationally decoupled from the underlying 297 physical network, and are run on top of it. Slicing enables the 298 creation of virtual networks as consumer services. 300 2.4. Control and Orchestration 302 Orchestration combines and coordinates multiple control methods to 303 provide a single mechanism to operate one or more networks to deliver 304 services. In a network slicing environment, an orchestrator is 305 needed to coordinate disparate processes and resources for creating, 306 managing, and deploying the network slicing service. Two aspects of 307 orchestration are required: 309 o Multi-domain Orchestration: Managing connectivity setup of the 310 network slice across multiple administrative domains. 312 o End-to-end Orchestration: Combining resources for an end-to-end 313 service (e.g., transport connectivity with firewalling, and 314 guaranteed bandwidth with minimum delay). 316 3. Abstraction and Control of Traffic Engineered (TE) Networks (ACTN) 318 ACTN facilitates end-to-end connections and provides them to the 319 user. The ACTN framework [RFC8453] introduces three functional 320 components and two interfaces: 322 o Customer Network Controller (CNC) 324 o Multi-domain Service Coordinator (MDSC) 326 o Provisioning Network Controller (PNC) 328 o CNC-MDSC Interface (CMI) 330 o MDSC-PNC Interface (MPI) 332 RFC 8453 also highlights how: 334 o Abstraction of the underlying network resources is provided to 335 higher-layer applications and consumers. 337 o Virtualization is achieved by selecting resources according to 338 criteria derived from the details and requirements of the 339 consumer, application, or service. 341 o Creation of a virtualized environment is performed to allow 342 operators to view and control multi-domain networks as a single 343 virtualized network. 345 o The presentation of networks to a consumer as a single virtual 346 network via open and programmable interfaces. 348 The ACTN managed infrastructure consists of traffic engineered 349 network resources. The concept of traffic engineering is broad: it 350 dscribes the planning and operation of networks using a method of 351 reserving and partitioning of network resources in order to 352 facilitate traffic delivery across a network (see 353 [I-D.ietf-teas-rfc3272bis] for more details). In the context of 354 ACTN, traffic engineering network resources may include: 356 o Statistical packet bandwidth. 358 o Physical forwarding plane sources, such as wavelengths and time 359 slots. 361 o Forwarding and cross-connect capabilities. 363 The ACTN network is "sliced" with consumers being given a different 364 partial and abstracted topology view of the physical underlying 365 network. 367 3.1. ACTN Virtual Network as a Network Slice 369 To support multiple consumers, each with its own view of and control 370 of the server network, a service provider needs to partition the 371 server network resources to create network slices assigned to each 372 consumer. 374 An ACTN Virtual Network (VN) is a consumer view of a slice of the 375 ACTN-managed infrastructure. It is a network slice that is presented 376 to the consumer by the ACTN provider as a set of abstracted 377 resources. See [I-D.ietf-teas-actn-vn-yang] for a detailed view of 378 ACTN VNs and an overview of how various different types of YANG model 379 are applicable to the ACTN framework. 381 Depending on the agreement between consumer and provider, various VN 382 operations are possible: 384 o Network Slice Creation: A VN could be pre-configured and created 385 through static configuration or through dynamic request and 386 negotiation between consumer and service provider. The VN must 387 meet the network slice requirements specified in the SLA (i.e., 388 SLOs) to satisfy the consumer's objectives. 390 o Network Slice Operations: The VN may be modified and deleted based 391 on consumer requests. The consumer can further act upon the VN to 392 manage traffic flows across the network slice. 394 o Network Slice View: The VN topology is viewed from the consumer's 395 perspective. This may be the entire VN topology or a collection 396 of tunnels that are expressed as consumer end points, access 397 links, intra domain paths and inter-domain links. 399 [RFC8454] describes a set of functional primitives that support these 400 different ACTN VN operations. 402 3.2. Examples of ACTN Delivering Types of Network Slices 404 The examples that follow build on the ACTN framework to provide 405 control, management, and orchestration for the network slice life- 406 cycle. These network slices utilize common physical infrastructure, 407 and meet specific service-level requirements. 409 Three examples are shown. Each uses ACTN to achieve a different 410 network slicing scenario. All three scenarios can be scaled up in 411 capacity or be subject to topology changes as well as changes of 412 consumer requirements. 414 3.2.1. ACTN Used for Virtual Private Line Model 416 In the example shown in Figure 1, ACTN provides virtual connections 417 between multiple consumer locations (sites accessed through Customer 418 Edge nodes - CEs). The service is requested by the consumer (via 419 CNC-A) and delivered as a Virtual Private Line (VPL) service. The 420 benefits of this model include: 422 o Automated: the service set-up and operation is managed by the 423 network provider. 425 o Virtual: the private line connectivity is provided from Site A to 426 Site C (VPL1) and from Site B to Site C (VPL2) across the ACTN- 427 managed physical network. 429 o Agile: on-demand adjustments to the connectivity and bandwidth are 430 available according to the consumer's requests. 432 (Consumer VPL Request) 433 : 434 ------- 435 | CNC-A | 436 Boundary ------- 437 Between . . . . . . . . .:. . . . . . . . . . . 438 Consumer & : 439 Network Provider ------ 440 | MDSC | 441 ------ 442 : 443 ----- 444 | PNC | 445 Site A ( ----- ) Site B 446 ----- ( ) ----- 447 | CE1 |========( Physical )========| CE2 | 448 -----\ ( Network ) /----- 449 \ (_______) / 450 \ || / 451 \ || / 452 VPL1 \ || / VPL2 453 \ || / 454 \ || / 455 \ || / 456 \-------------/ 457 | CE3 | 458 ------------- 459 Site C 461 Key: ... ACTN control connectivity 462 === Physical connectivity 463 --- Logical connectivity 465 Figure 1: Virtual Private Line Model 467 3.2.2. ACTN Used for VPN Delivery Model 469 In the example shown in Figure 2, ACTN provides VPN connectivity 470 between two sites across three physical networks. The requirements 471 for the VPN are expressed by the users of the two sites who are the 472 consumers. Their requests are directed to the CNC, and the CNC 473 interacts with the network provider's MDSC. The benefits of this 474 model include: 476 o Provides edge-to-edge VPN multi-access connectivity. 478 o Most of the function is managed by the network provider, with some 479 flexibility delegated to the consumer-managed CNC. 481 -------------- -------------- 482 | Site-A Users | | Site-B Users | 483 -------------- -------------- 484 : : 485 ------------- 486 | CNC | 487 Boundary ------------- 488 Between . . . . . . . . . . . : . . . . . . . . . . . 489 Consumer & : 490 Network Provider : 491 --------------------------------- 492 | MDSC | 493 --------------------------------- 494 : : : 495 : : : 496 ------- ------- ------- 497 | PNC | | PNC | | PNC | 498 ------- ------- ------- 499 : : : 500 : : : 501 ______ ----- ----- ----- ______ 502 < > ( ) ( ) ( ) < > 503 ====( Phys. )======( Phys. )======( Phys. )==== 504 < > ( Net ) ( Net ) ( Net ) < > 505 < > ----- ----- ----- < > 506 < >-----------------------------------------------< > 507 <______> <______> 509 Key: ... ACTN control connectivity 510 === Physical connectivity 511 --- Logical connectivity 513 Figure 2: VPN Model 515 3.2.3. ACTN Used to Deliver a Virtual Consumer Network 517 In this example (shown in Figure 3), ACTN provides a virtual network 518 to the consumer. This virtual network is managed by the consumer. 519 The figure whos two virtual networks (Network Slice 1 and Network 520 Slice 2) each created for a different consumer under the care of a 521 different CNC. There are two physical networks controlled by 522 separate PNCs. Network Slice 2 is built using resources from just 523 one physical network, while Network Slice 1 is constructed from 524 resources from both physical networks. 526 The benefits of this model include: 528 o The MDSC provides the topology to the consumer so that the 529 consumer can control their network slice to fit their needs. 531 o Applications can interact with their assigned network slices 532 directly. The consumer may implement their own network control 533 methods and traffic prioritization, and manage their own 534 addressing schemes. 536 o Consumers may further slice their vitrual networks so that this 537 becomes a recursive model. 539 o Service isolation can be provided through selection of physical 540 networking resources through a combination of efforts of the MSDC 541 and PNC. 543 o The network slice may include nodes with specific capabilities. 544 These can be delivered as Physical Network Functions (PNFs) or 545 Virtual Network Functions (VNFs). 547 ___________ 548 ------------- ( ) 549 | CNC |----------->( Network ) 550 ------------- ( Slice 2 ) 551 ^ (___________) 552 | ___________ ^ 553 ------------- ( ) : 554 | CNC |----------->( Network ) : 555 ------------- ( Slice 1 ) : 556 ^ | (___________) : 557 | | ^ ^ : 558 Boundary | | : : : 559 Between . . . .|. .|. . . . . . . . . . : . .:. . : . . . 560 Consumer & | | : : : 561 Network Provider | | : : : 562 v v : : : 563 ------------- : :....: 564 | MDSC | : : 565 ------------- : : 566 ^ ------^-- : 567 | ( ) : 568 v ( Physical ) : 569 ------- ( Network ) : 570 | PNC |<------------>( ) ---^----- 571 ------- | ------- ( ) 572 | PNC |- ( Physical ) 573 | |<-------------------------->( Network ) 574 ------- ( ) 575 ------- 577 Key: --- ACTN control connection 578 ... Virtualization/abstraction through slicing 580 Figure 3: Network Slicing 582 4. YANG Models 584 4.1. Network Slice Service Mapping from TE to ACTN VN Models 586 The role of the TE-service mapping model 587 [I-D.ietf-teas-te-service-mapping-yang] is to create a binding 588 relationship across a Layer 3 Service Model (L3SM) [RFC8049], Layer 2 589 Service Model (L2SM) [RFC8466], and TE Tunnel model 590 [I-D.ietf-teas-yang-te], via the generic ACTN Virtual Network (VN) 591 model [I-D.ietf-teas-actn-vn-yang]. 593 The ACTN VN model is a generic virtual network service model that 594 allows consumers to specify a VN that meets the consumer's service 595 objectives with various constraints on how the service is delivered. 597 The TE-service mapping model [I-D.ietf-teas-te-service-mapping-yang] 598 is used to bind the L3SM with TE-specific parameters. This binding 599 facilitates seamless service operation and enables visibility of the 600 underlay TE network. The TE-service model developed in that document 601 can also be extended to support other services including L2SM, and 602 the Layer 1 Connectivity Service Model (L1CSM) 603 [I-D.ietf-ccamp-l1csm-yang] L1CSM network service models. 605 Figure 4 shows the relationship between the models discussed above. 607 -------------- -------------- 608 | L3SM |<=======| | ---------- 609 -------------- augment| |..........>| ACTN VN | 610 -------------- | Augmented | reference ---------- 611 | L2SM |<=======| Service | 612 -------------- augment| Model | ---------- 613 -------------- | |..........>| TE-topo | 614 | L1CSM |<=======| | reference ---------- 615 -------------- augment| | 616 -------------- | | ---------- 617 | TE & Service |------->| |..........>| TE-tunnel| 618 | Mapping Types| import -------------- reference ---------- 619 -------------- 621 Figure 4: TE-Service Mapping 623 4.2. Network Slice NBI Model 625 Figure 5 shows the three ACTN components and two ACTN interfaces as 626 listed in Section 3. The figure also shows the Southbound Interface 627 (SBI) between the PNC and the devices in the physical network. That 628 interface might be used to install state on every device in the 629 network, or might instruct a "head-end" node if a control plane is 630 used within the physical network. 632 The figure also shows the Northbound Interface (NBI). This interface 633 allows a consumer of a service to make requests for delivery of the 634 service, and it facilitates the consumer modifying and monitoring the 635 service. 637 When an ACTN system is used to manage the delivery of network slices, 638 a network slice resource model is needed. This model will be used 639 for instantiation, operation, and monitoring of network and function 640 resource slices. The YANG model defined in 641 [I-D.wd-teas-transport-slice-yang] provides a suitable basis for 642 requesting, controlling and deleting, network slices. 644 ---------- 645 | Consumer | 646 ---------- 647 .......:....... NBI 648 : 649 ------------- 650 | CNC | 651 ------------- 652 .......:....... CMI 653 : 654 --------------- 655 | MDSC | 656 --------------- 657 .......:....... MPI 658 : 659 ------- 660 | PNC | 661 ------- 662 .......:....... SBI 663 : 664 ---------- 665 ( ) 666 ( Physical ) 667 ( Network ) 668 (________) 670 Figure 5: The NBI Model in Context 672 4.3. ACTN VN Telemetry 674 The ACTN VN KPI telemetry model 675 [I-D.ietf-teas-actn-pm-telemetry-autonomics] provides a way for a 676 consumer to define performance monitoring relevant for its VN/network 677 slice via the NETCONF subscription mechanisms [RFC8639], [RFC8640] or 678 the equivalent mechanisms in RESTCONF [RFC8641], [RFC8650]. 680 Key characteristics of [I-D.ietf-teas-actn-pm-telemetry-autonomics] 681 include: 683 o An ability to provide scalable VN-level telemetry aggregation 684 based on consumer subscription model for key performance 685 parameters defined by the consumer. 687 o An ability to facilitate proactive re-optimization and 688 reconfiguration of VNs/network slices based on network autonomic 689 traffic engineering scaling configuration mechanism. 691 5. IANA Considerations 693 This document makes no requests for action by IANA. 695 6. Security Considerations 697 Network slicing involves the control of network resources in order to 698 meet the service requirements of consumers. In some deployment 699 models, the consumer is able to directly request modification in the 700 behaviour of resources owned and operated by a service provider. 701 Such changes could significantly affect the service provider's 702 ability to provide services to other consumers. Furthermore, the 703 resources allocated for or consumed by a consumer will normally be 704 billable by the service provider. 706 Therefore, it is crucial that the mechanisms used in any network 707 slicing system allow for authentication of requests, security of 708 those requests, and tracking of resource allocations. 710 It should also be noted that while the partitioning or slicing of 711 resources is virtual, the consumers expect and require that there is 712 no risk of leakage of data from one slice to another, no transfer of 713 knowledge of the structure or even existence of other slices, and 714 that changes to one slice (under the control of one consumer) should 715 not have detrimental effects on the operation of other slices 716 (whether under control of different or the same consumers) beyond the 717 limits allowed within the SLA. Thus, slices are assumed to be 718 private and to provide the appearance of genuine physical 719 connectivity. 721 ACTN operates using the NETCONF [RFC6241] or RESTCONF [RFC8040] 722 protocols and assumes the security characteristics of those 723 protocols. Deployment models for ACTN should fully explore the 724 authentication and other security aspects before networks start to 725 carry live traffic. 727 7. Acknowledgements 729 Thanks to Qin Wu, Andy Jones, Ramon Casellas, Gert Grammel, and Kiran 730 Makhijani for their insight and useful discussions about network 731 slicing. 733 8. Contributors 735 The following people contributed text to this document. 737 Young Lee 738 Email: younglee.tx@gmail.com 740 Mohamed Boucadair 741 Email: mohamed.boucadair@orange.com 743 Sergio Belotti 744 Email: sergio.belotti@nokia.com 746 Daniele Ceccarelli 747 Email: daniele.ceccarelli@ericsson.com 749 Adrian Farrel 750 adrian@olddog.co.uk 752 9. Informative References 754 [I-D.ietf-ccamp-l1csm-yang] 755 Lee, Y., Lee, K., Zheng, H., Dios, O., and D. Ceccarelli, 756 "A YANG Data Model for L1 Connectivity Service Model 757 (L1CSM)", draft-ietf-ccamp-l1csm-yang-12 (work in 758 progress), September 2020. 760 [I-D.ietf-teas-actn-pm-telemetry-autonomics] 761 Lee, Y., Dhody, D., Karunanithi, S., Vilata, R., King, D., 762 and D. Ceccarelli, "YANG models for VN/TE Performance 763 Monitoring Telemetry and Scaling Intent Autonomics", 764 draft-ietf-teas-actn-pm-telemetry-autonomics-03 (work in 765 progress), July 2020. 767 [I-D.ietf-teas-actn-vn-yang] 768 Lee, Y., Dhody, D., Ceccarelli, D., Bryskin, I., and B. 769 Yoon, "A YANG Data Model for VN Operation", draft-ietf- 770 teas-actn-vn-yang-09 (work in progress), July 2020. 772 [I-D.ietf-teas-enhanced-vpn] 773 Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A 774 Framework for Enhanced Virtual Private Networks (VPN+) 775 Service", draft-ietf-teas-enhanced-vpn-06 (work in 776 progress), July 2020. 778 [I-D.ietf-teas-rfc3272bis] 779 Farrel, A., "Overview and Principles of Internet Traffic 780 Engineering", draft-ietf-teas-rfc3272bis-01 (work in 781 progress), July 2020. 783 [I-D.ietf-teas-te-service-mapping-yang] 784 Lee, Y., Dhody, D., Fioccola, G., WU, Q., Ceccarelli, D., 785 and J. Tantsura, "Traffic Engineering (TE) and Service 786 Mapping Yang Model", draft-ietf-teas-te-service-mapping- 787 yang-04 (work in progress), July 2020. 789 [I-D.ietf-teas-yang-te] 790 Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin, 791 "A YANG Data Model for Traffic Engineering Tunnels, Label 792 Switched Paths and Interfaces", draft-ietf-teas-yang-te-25 793 (work in progress), July 2020. 795 [I-D.nsdt-teas-ns-framework] 796 Gray, E. and J. Drake, "Framework for Transport Network 797 Slices", draft-nsdt-teas-ns-framework-04 (work in 798 progress), July 2020. 800 [I-D.wd-teas-transport-slice-yang] 801 Bo, W., Dhody, D., Han, L., and R. Rokui, "A Yang Data 802 Model for Transport Slice NBI", draft-wd-teas-transport- 803 slice-yang-02 (work in progress), July 2020. 805 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 806 and A. Bierman, Ed., "Network Configuration Protocol 807 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 808 . 810 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 811 Chaining (SFC) Architecture", RFC 7665, 812 DOI 10.17487/RFC7665, October 2015, 813 . 815 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 816 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 817 . 819 [RFC8049] Litkowski, S., Tomotaki, L., and K. Ogaki, "YANG Data 820 Model for L3VPN Service Delivery", RFC 8049, 821 DOI 10.17487/RFC8049, February 2017, 822 . 824 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for 825 Abstraction and Control of TE Networks (ACTN)", RFC 8453, 826 DOI 10.17487/RFC8453, August 2018, 827 . 829 [RFC8454] Lee, Y., Belotti, S., Dhody, D., Ceccarelli, D., and B. 830 Yoon, "Information Model for Abstraction and Control of TE 831 Networks (ACTN)", RFC 8454, DOI 10.17487/RFC8454, 832 September 2018, . 834 [RFC8466] Wen, B., Fioccola, G., Ed., Xie, C., and L. Jalil, "A YANG 835 Data Model for Layer 2 Virtual Private Network (L2VPN) 836 Service Delivery", RFC 8466, DOI 10.17487/RFC8466, October 837 2018, . 839 [RFC8639] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, 840 E., and A. Tripathy, "Subscription to YANG Notifications", 841 RFC 8639, DOI 10.17487/RFC8639, September 2019, 842 . 844 [RFC8640] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, 845 E., and A. Tripathy, "Dynamic Subscription to YANG Events 846 and Datastores over NETCONF", RFC 8640, 847 DOI 10.17487/RFC8640, September 2019, 848 . 850 [RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications 851 for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641, 852 September 2019, . 854 [RFC8650] Voit, E., Rahman, R., Nilsen-Nygaard, E., Clemm, A., and 855 A. Bierman, "Dynamic Subscription to YANG Events and 856 Datastores over RESTCONF", RFC 8650, DOI 10.17487/RFC8650, 857 November 2019, . 859 Authors' Addresses 861 Daniel King 862 Old Dog Consulting 864 Email: daniel@olddog.co.uk 865 John Drake 866 Juniper Networks 868 Email: jdrake@juniper.net 870 Haomian Zheng 871 Huawei Technologies 873 Email: zhenghaomian@huawei.com