idnits 2.17.1 draft-leeking-teas-actn-problem-statement-00.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 (June 9, 2015) is 3243 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-22) exists of draft-boucadair-connectivity-provisioning-protocol-09 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Young Lee 3 Internet Draft Huawei 4 Intended status: Informational Daniel King 5 Expires: December 10, 2015 Lancaster University 6 M. Boucadair 7 France Telecom 8 R. Jing 9 China Telecom 10 L. Contreras Murillo 11 Telefonica 12 June 9, 2015 14 Problem Statement for Abstraction and Control of Transport Networks 15 draft-leeking-teas-actn-problem-statement-00.txt 17 Status of this Memo 19 This Internet-Draft is submitted to IETF in full conformance with 20 the provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six 28 months and may be updated, replaced, or obsoleted by other documents 29 at any time. It is inappropriate to use Internet-Drafts as 30 reference material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire December 10, 2015. 40 Copyright Notice 42 Copyright (c) 2015 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with 50 respect to this document. Code Components extracted from this 51 document must include Simplified BSD License text as described in 52 Section 4.e of the Trust Legal Provisions and are provided without 53 warranty as described in the Simplified BSD License. 55 Abstract 57 Transport networks that provide connectivity and bandwidth for 58 customer services have typically been static, lacking 59 flexibility, and requiring long planning times when deploying new 60 services. Network Providers and Service Providers have embraced 61 technologies that allow separation of data plane and control plane, 62 distributed signaling for path setup and protection, and centralized 63 path computation for service planning and traffic engineering. 64 Although these technologies provide significant benefits, they do 65 not meet the growing need for network programmability, automation, 66 resource sharing, and service elasticity necessary to meet 67 operators' requirements for virtual network operation. 69 Virtual network operation refers to the creation of a 70 virtualized environment allowing operators to view the 71 abstraction of the underlying multi-administration, multi- 72 vendor, multi-technology networks and to operate, control, and 73 manage these multiple networks as if a single virtualized network. 74 Another dimension of virtual network operation is the use of 75 common core transport network resources by multi-tenant service 76 networks as a way of providing a virtualized infrastructure to 77 flexibly offer new services and applications. 79 The work effort investigating this problem space is known as 80 Abstraction and Control of Transport Networks (ACTN). This 81 document provides an ACTN problem description, a scope of work, 82 and outlines the core objectives and requirements to facilitate 83 virtual network operation. 85 Table of Contents 87 1. Introduction..................................................4 88 1.1. Terminology..............................................5 89 2. Objectives and Functional Requirements........................7 90 2.1. Use Cases................................................7 91 2.1.1 Packet Transport Networks (PTN) in Mobile Backhaul 92 Networks................................................7 93 2.1.2 Packet Optical Integration (POI)....................7 94 2.1.3 Multi-domain Data Center Interconnect...............7 95 2.1.4 On-demand E2E Connectivity Services in Multiple Vendor 96 Domain Transport Networks...............................8 97 2.1.5 Multi Tenant Virtual Network Operators..............9 98 2.1.6 Virtual Network Operation for Multiple Domains in a 99 Single Operator Network.................................10 100 2.1.7 Mobile Virtual Network Operation for Multiple Domains 101 in a Single Operator Network............................10 102 2.1.8 Dynamic Service Control based on Performance 103 Monitoring..............................................11 104 3. Relationship with Existing Technologies & Other Industry 105 Initiatives.............................................11 106 3.1. Virtual Private Networks.................................11 107 3.2. Overlay Networks.........................................12 108 3.3. Other Industry Initiatives...............................12 109 4. Motivations for Additional Functionality......................13 110 4.1. Business Objectives......................................13 111 4.2. Network Resource Recursiveness...........................14 112 4.3. Customer-Initiated Programmability.......................14 113 4.4. Resource Partitioning....................................14 114 4.5. Service Orchestration....................................14 115 5. ACTN Objectives and Requirements..............................15 116 5.1. Capability and Resource Visibility.......................15 117 5.2. Network Programmability..................................16 118 5.3. Common Data Models.......................................16 119 5.4. Scheduling...............................................17 120 5.5. Slicing..................................................17 121 5.6. Adaptability.............................................17 122 5.7. Allocation...............................................17 123 5.8. Isolation................................................18 124 5.9. Manageability............................................18 125 5.10. Resilience..............................................19 126 5.11. Security................................................19 127 5.12. Policy..................................................20 128 5.13. Technology Independence.................................20 129 5.14. Optimization............................................20 130 5.15. Multi-domain Support....................................20 131 5.16. Architecture Principles.................................20 132 5.16.1. Network Partitioning...............................21 133 5.16.2. Orchestration......................................21 134 5.16.3. Recursion..........................................21 135 5.16.4. Legacy Support and Interoperability................21 136 5.17. Other Related Work......................................21 137 5.17.1. Requirements for Automated (Configuration) Management 138 ...........................................................21 139 5.17.2. Connectivity Provisioning Negotiation Protocol (CPNP) 140 ...........................................................21 141 6. References....................................................22 142 6.1. Informative References...................................22 143 7. Acknowledgements..............................................24 144 8. IANA Considerations...........................................24 145 9. Authors' Addresses............................................24 147 1. Introduction 149 Customers continue to demand new services that are time scheduled, 150 dynamic, and underpinned by a Pay As You Go billing model. These 151 services are provided to customers by network operators and service 152 providers and give rise to a variety of applications for office 153 automation, data backup and retrieval, distributed computing, and 154 high-quality media broadcasting. They offer Network and Service 155 Providers new revenue generation opportunities, and these services 156 typically have different traffic characteristics from established 157 network services such as file hosting, web, and email. Deploying and 158 operating these new applications and services using existing network 159 technologies and architectures limits network efficiency, 160 scalability, and elasticity (i.e., they do not offer sufficient 161 capability to adapt to customer and application demands). 163 Network virtualization has been a significant innovation towards 164 meeting customer demands and enabling new applications and services. 165 Separating network resources, and representing resources and 166 topologies via abstracted concepts, facilitates effective sharing 167 (or 'slicing') of physical infrastructure into virtual network 168 service instances corresponding to multiple virtual network 169 topologies that may be used by specific applications, services, and 170 users. Further development is required to allow customers to create, 171 modify, and delete virtual network services dynamically. 173 Transport networks that provide connectivity and bandwidth for 174 customer services have typically been static, lacking flexibility, 175 and requiring long planning times when deploying new services. 176 Network Providers and Service Providers have embraced technologies 177 that allow separation of data plane and control plane, distributed 178 signaling for path setup and protection, and centralized path 179 computation for service planning and traffic engineering. Although 180 these technologies provide significant benefits, they do not meet 181 the growing need for network programmability, automation, resource 182 sharing, and service elasticity necessary to meet operators' 183 requirements for virtual network operation. 185 Virtual network operation refers to the creation of a virtualized 186 environment allowing operators to view the abstraction of the 187 underlying multi-administration, multi-vendor, multi-technology 188 networks and to operate, control and manage these multiple networks 189 as single virtualized network. Another dimension of virtual network 190 operation is the use of common core transport network resources by 191 multi-tenant service networks as a way of providing a virtualized 192 infrastructure to flexibly offer new services and applications. 194 Abstraction and Control of Transport Networks (ACTN) defines new 195 methods and capabilities for the deployment and operation of 196 transport network resource. These are summarized as follows. 198 o Coordination and abstraction of underlying transport network 199 resources to higher-layer applications and customers. Note 200 that higher-layer applications and customers could be 201 internal users of the core transport network resource such as 202 various service networks. 204 o Multi-domain virtual network operation that facilitates 205 multi-administration, multi-vendor, and multi-technology 206 networks as a single virtualized network. 208 o Multi-tenant virtual network operation that consolidates 209 different network services and applications to allow slicing 210 of network resources to meet specific service, application 211 and customer requirements. 213 o Provision of a computation scheme and virtual control 214 capability via a data model to customers who request 215 virtual network services. Note that these customers could, 216 themselves, be service providers. 218 This document first presents the summary of ACTN use-cases, then 219 provides an ACTN problem description and scope of work, and 220 outlines the core objectives and requirements to facilitate 221 virtual network operation. 223 1.1. Terminology 225 This document uses the terminology defined in [RFC4655] and 226 [RFC5440]. Additional terms are defined below. 228 o Customers: 230 Customers are users of virtual network services. They are 231 provided with an abstract view of the network resource (known as 232 "a slice") to support their users and applications. In some 233 cases, customers may have to support multiple virtual network 234 services with different service objectives and QoS requirements 235 to enable multiple types of users and applications. Customers 236 may also be considered to be trusted parties with respect to 237 the provider wholesale service department. A trust model will 238 be required and is discussed further later in this document. 240 o Service Providers (also Virtual Network Service Provider): 242 Service Providers are the providers of virtual network services 243 to their customers. Service Providers typically lease resources 244 from one or more Network Provider to create virtual network 245 services or offer end-to-end services to their customers. A 246 Service Provider may be a Network Provider such that some or 247 all of the resources used are owned by the Service Provider. A 248 Virtual Network Service Provider is a special type of 249 Service Provider in that they might own no physical equipment 250 or infrastructure, or might have only limited physical 251 infrastructure and require virtual resources to be supplied to 252 them by another Service Provider to offer the final service. A 253 Virtual Network Service Provider only provide services built 254 upon a virtual network infrastructure. The rest of this 255 document does not distinguish between a Virtual Network Service 256 Provider and Service Provider. 258 o Network Providers: 260 Network Providers are the infrastructure providers that own the 261 physical network resources and provide transport network 262 resources to their customers. Service Providers can be the 263 customers of Network Providers or can be the Network Providers 264 themselves. 266 o Network Virtualization: 268 Network virtualization, refers to allowing the customers to 269 utilize certain network resources as if they owned them, and thus 270 allows the customers to control their allocated resources in a 271 way most optimal for higher layer or application processes. 272 This customer control facilitates the introduction of new 273 applications (on top of available services) as the customers 274 are given programmable interfaces to create, modify, and delete 275 their virtual network services. 277 o Transport Networks: 279 Transport networks are defined as network infrastructure that 280 provides connectivity and bandwidth for customer services. They 281 are characterized by their ability to support server layer 282 resources providing connectivity bandwidth and traffic engineering 283 for client layer services, such that resource guarantees may be 284 provided to customers. Transport networks discussed in this 285 document different types of connection-oriented networks 286 including both Connection-Oriented Circuit Switched (CO-CS) 287 networks and Connection-Oriented Packet Switched (CO-PS) 288 networks. This implies that at least the following transport 289 networks are in scope: Layer 1 (L1) and Layer 0 (L0) optical 290 networks (e.g., OTN, ODU, OCh/WSON), MPLS-TP, MPLS-TE, as well 291 as other emerging network technologies with connection-oriented 292 behavior. 294 2. Objectives and Functional Requirements 296 2.1 Use Cases 298 A group of Service Providers and Network Providers have identified 299 a number of key use cases that identify key application scenarios for 300 how ACTN may be used. 302 2.1.1 Packet Transport Networks (PTN) in Mobile Backhaul Networks 304 The Packet Transport Networks (PTN) Network Provider may use ACTN to 305 improve efficiency of provision and operation, optimize the 306 resources utilization, and promote the customer's experiences. 307 The Internet-Draft [CHENG] discusses the key requirements for ACTN in 308 a PTN environment, these include: 310 o Faster End-to-End Enterprise services Provisioning 312 o Multi-layer coordination in L2/L3 Packet Transport Networks 314 o Optimizing the network resources utilization (supporting 315 various performances monitoring matrix, such as traffic flow 316 statistics, packet delay, delay variation, throughput and 317 packet-loss rate) 319 o Virtual Networks Operations for Multi-domain Packet Transport 320 Networks 322 2.1.2 Packet Optical Integration (POI) 324 Increasingly there is a need for packet and optical transport 325 networks to work together to provide accelerated services. Transport 326 networks can provide useful information to the packet network 327 allowing it to make intelligent decisions and control its allocated 328 resources. The Internet-Draft [DHODY] outlines the Packet Optical 329 Integration (POI) use case for ACTN, 331 The Internet-Draft [DHODY] discusses the key requirements for ACTN 332 for the Packet Optical Integration (POI) environment, requirements 333 include: 335 o Packet Optical Integration to support Traffic Planning, 336 performance Monitoring, automated congestion management and 337 Automatic Network Adjustments. 339 o Protection and Restoration Synergy in Packet Optical Multi- 340 layer network. 342 o Service Awareness and Coordination between Multiple Network 343 Domains. 345 2.1.3 Multi-domain Data Center Interconnect 347 Data center operators need to interface multi-domain transport 348 networks to offer their global data center applications and 349 services. As data center providers face multi-domain and diverse 350 transport technology, interoperability based on standard-based 351 abstraction is required for dynamic and flexible applications and 352 services. 354 The Internet-Draft [FANG] discusses the key requirements for ACTN 355 for the data center interconnect environment, requirements 356 include: 358 o Multi-domain Data Center Interconnection to support VM 359 Migration, Global Load Balancing, Disaster Recovery, On- 360 demand Virtual Connection/Circuit Services. 362 o The interfaces between the Data Center Operation and each 363 transport network domain should support standards-based 364 abstraction with a common information/data model to support 365 the following: 367 - Network Query (Pull Model) from the Data Center 368 Operation to each transport network domain to collect 369 potential resource availability (e.g., BW availability, 370 latency range, etc.) between a few data center 371 locations. 373 - Network Path Computation Request from the Data Center 374 Operation to each transport network domain to estimate 375 the path availability. 377 - Network Virtual Connections/Circuits Request from the 378 Data Center Operation to each transport domain to 379 establish end-to-end virtual connections/circuits (with 380 type, concurrency, duration, SLA.QoS parameters, 381 protection.reroute policy options, policy constraints 382 such as peering preference, etc.). 384 - Network Virtual Connections/Circuits Modification 385 Request. 387 2.1.4 On-demand E2E Connectivity Services in Multiple Vendor 388 Domain Transport Networks 390 There is a need for creation and operation of a virtualized 391 environment supporting the viewing and controlling different 392 vendor domains, including on-demand network connectivity 393 service across a single operator environment. This will accelerate 394 rapid service deployment of new services, including more dynamic 395 and elastic services, and improve overall network operations and 396 scaling of existing services. 398 The Internet-Draft [KLEE] highlights on-demand edge-to-edge (E2E) 399 connectivity service requirements in multiple vendor domain 400 transport networks, which include: 402 o Two-stage path computation capability in a hierarchical 403 control architecture (MDSC-PNC) and a hierarchical 404 composition of integrated network views. 406 o Coordination of signal flow for E2E connections. 408 o Abstraction of: 410 - Inter-connection data between domains 412 - Customer Endpoint data 414 - The multiple levels/granularities of the abstraction of 415 network resource (which is subject to policy and service 416 need). 418 - Any physical network constraints (such as SRLG, link 419 distance, etc.) should be reflected in abstraction. 421 - Domain preference and local policy (such as preferred 422 peering point(s), preferred route, etc.), Domain network 423 capability (e.g., support of push/pull model). 425 2.1.5 Multi-Tenant Virtual Network Operators 427 Creation and operation of multi-tenant virtual networks that use 428 the common core network resources is important to facilitate rapid 429 deployment of new services, including more dynamic and elastic 430 services, and improve overall network operations and scaling of 431 existing services. 433 The Internet-Draft [KUMAKI] discusses multi-tenant virtual networks 434 that use the common core network resources, requirements include: 436 o On-demand Virtual Network Service Creation 437 o Domain Control Plane/Routing Layer Separation 438 o Independent service Operation for Virtual Services from 439 control of other domains 440 o Multiple service level support for each VN (e.g., bandwidth 441 and latency for each VN service). 443 o VN diversity/survivability should be met in physical network 444 mapping. 445 o VN confidentiality and sharing constraint should be supported. 447 2.1.6 Virtual Network Operation for Multiple Domains in a Single 448 Operator Network 450 Virtual network operation for multiple domains in a single 451 operator network is required. This would facilitate the 452 application of virtual network abstractions to network operations. 453 These abstractions will create a virtualized environment 454 supporting the viewing and controlling different domains as a 455 single virtualized network. 457 This use case is discussed in more detail in [LOPEZ], requirements 458 include: 460 o Creation of a global abstraction of network topology: The VNO 461 Coordinator assembles each domain level abstraction of 462 network topology into a global abstraction of the end-to-end 463 network. 465 o End-to-end connection lifecycle management. 467 o Invocation of path provisioning request to each domain 468 (including optimization requests). 470 o Invocation of path protection/reroute to the affected 471 domain(s). 473 o End-to-end network monitoring and fault management. This could 474 imply potential KPIs and alarm correlation capabilities. 476 o End-to-end accounting and generation of detailed records for 477 resource usage. 479 o End-to-end policy enforcement 481 2.1.7 Mobile Virtual Network Operation for Multiple Domains 482 in a Single Operator Network 484 The use-case for mobile virtual networks with single operator 485 Networks is discuss edin [SHIN]. 487 o Resource abstraction: operational mechanisms in mobile 488 backhaul network to give the current network usage 489 information for dynamic and elastic applications be 490 provisioned dynamically with QoS guarantee. 492 o Load balancing or for recovery, the selection of core DC 493 location from edge constitutes a data center selection 494 problem. 496 o Multi-layer routing and optimization, coordination between 497 these two layers. 499 2.1.8 Dynamic Service Control based on Performance 500 Monitoring 502 Transport networks support various performance monitoring 503 mechanisms, such as traffic flow statistics, packet delay, delay 504 variation, throughput and packet-loss rate for MPLS-TP and packet 505 OTN networks, BER, FEC error correction counters for OTN and DWDM 506 networks, etc. These mechanisms may be used to support 507 dynamic service control of network resources based on the 508 aforementioned performance monitoring. This use case is discussed in 509 [XU], requirements include: 511 o Dynamic Service Control Policy enforcement and Traffic/SLA 512 Monitoring: 513 - Customer service performance monitoring strategy, 514 including the traffic monitoring object (the service 515 need to be monitored) 516 - monitoring parameters (e.g., transmitted and received 517 bytes per unit time), 518 - traffic monitoring cycle (e.g., 15 minutes, 24 hours), 519 - threshold of traffic monitoring (e.g., high and low 520 threshold), etc. 522 3. Relationship with Existing Technologies & Other Industry Initiatives 524 3.1. Virtual Private Networks 526 A Virtual Private Network (VPN) is a well-known concept 527 [RFC4110], [RFC4664], and [RFC4847], and may be used to connect 528 multiple distributed sites via a variety of transport 529 technologies, sometimes over shared network infrastructure. 531 Typically VPNs are managed and provisioned directly by the 532 Network Provider or a VPN Service Provider. VPN systems may be 533 Classified by: 535 o Protocol mechanisms used to tunnel the traffic; 537 o Tunnel termination point and/or location; 539 o Type of connectivity, site-to-site or remote-access; 540 o Quality of Service (QoS) capabilities; 542 o Level of security provided; 544 o Emulated service connectivity layer (layer 1, layer 2, 545 layer 3); 547 Existing VPN solutions are largely technology specific and offer 548 limited elasticity, although some technologies offer greater 549 flexibility (i.e., layer 2 VPNs [RFC4664] and layer 3 VPNs 550 [RFC4110]) when compared with layer 1 VPNs [RFC4847], all 551 technologies are often deployed using pre-defined configurations. 552 [RFC4847] describes virtual networks in terms of ITU-T [Y.1312] 553 and [Y.1313]. Those Recommendations address both the data plane 554 and control plane aspects of VPNs. Concepts of private and 555 shared VPNs are described. 557 The transport layer is achieved by utilizing a variety of 558 technology-specific interfaces - e.g. Gigabit Ethernet (GE), 559 Synchronous Digital Hierarchy (SDH), or Asynchronous Transfer 560 Mode (ATM) for wireless back-hauling, or optical networks OTN and 561 WSON. 563 VPNs offer a scalable tunnel solution for customer traffic; 564 However, they are wholly dependent on the Service Provider to 565 setup and manage the VPNs, lacking customer-initiated service 566 programmability: creation, resizing, and deletion. 568 3.2. Overlay Networks 570 An overlay network [RFC4208] provides an enhanced network 571 virtualization technique, with the overlay network providing a 572 topology comprised of virtual or logical links and nodes, which 573 are built on top of physical nodes and links, providing a 574 topology in which some of the links and nodes are virtual or 575 logical and are built from multiple nodes or links in a server 576 network. 578 Overlay networks are typically used in the multi-layer context 579 in which the packet layer is a client to the server transport 580 layer. The scope of network virtualization in overlay networks is 581 somewhat limited. Customers and applications which need 582 visibility or programmability, and the ability to resize or add 583 resources, may find that overlay network technologies do meet 584 their requirements. 586 3.3. Other Industry Initiatives 587 ONF Architecture [ONF-SDN-ARCH] describes various arrangements of 588 SDN controllers. 590 TM Forum's [TR215] and [TR225] addresses a common information model 591 that can be applied to transport network in particular. 593 ITU-T [Y.1312] and [Y.1313] are a good reference to review for 594 Layer 1 VPN in terms of terminology and architecture. 596 4. Motivations for Additional Functionality 598 4.1. Business Objectives 600 The VPN and overlay network (ON) models are built on the premise 601 that one single Network Provider provides all virtual private or 602 overlay networks to its customers. This model is simple to 603 operate but has some disadvantages in accommodating the 604 increasing need for flexible and dynamic network virtualization 605 capabilities. 607 A Network Provider may provide end-to-end services and content 608 (i.e., web and email) to its customers. Other services, 609 applications, and content are typically provided via Service 610 Providers and Over the Top (OTT) (i.e., Video-on-demand, Social 611 Media) providers. We can further categorize Service Providers 612 as: 614 o A fixed or mobile Internet Service Provider (ISP) which 615 provides Internet connectivity and bandwidth to users; 617 o A service provider that leases network resources from one or 618 more network providers to create virtual network services 619 between ISPs and the core Internet. 621 o Data Center (DC)/content Network Provider and Service Providers 622 who provide connectivity and bandwidth to content servers and 623 application servers. 625 Network Providers and Service Providers of every type, all share 626 The common business and revenue objectives: 628 o Minimize time to plan and deploy new services; 630 o Reduce the reliance on highly skilled personnel to operate 631 their network; 633 o Reduce time to react to changing business demands and customer 634 applications; 636 o Offer new, much more flexible services to their customers; 638 o Maximize network resource usage and efficiency. 640 All aforementioned objectives have the capability to 641 significantly increase revenue and reduce operational costs. 643 Network and Service Providers require capabilities that extend 644 the current landscape of network virtualization capabilities and 645 overall business objectives of the Network Provider, Service 646 Provider, and ultimately the Customer and their Applications. 648 4.2. Network Resource Recursiveness 650 A newly emerged network virtualization environment is a 651 collection of heterogeneous network architectures from different 652 players. VPNs and overlay networks are somewhat limited in 653 addressing programmable interfaces for application or customer 654 layers as well as for the service layer. The model must be 655 extended to address a recursive nature of layer interactions in 656 network virtualization across transport networks, service 657 networks, and customers/applications. 659 4.3. Customer-Initiated Programmability 661 Network-driven technologies such as VPNs and overlay networks 662 provide customers with a set of pre-defined programmatic 663 parameters to enable virtual networks. However, this model is 664 limited to only allow programmable interfaces in which customers 665 initiate and define virtual network services. This model must be 666 extended to allow customer-initiated network programmability. 668 4.4. Resource Partitioning 670 The ability to slice and allocate transport resources for Service 671 Providers would be beneficial. It would improve transport network 672 resource efficiency and provide a method for the transport 673 Network Provider to offer resource flexibility and control to 674 Service Providers and users. 676 4.5. Service Orchestration 678 Another dimension is diversity on the customer side. Customers in 679 this newly emerged network virtualization environment bring 680 different dynamics than the traditional VPNs or Overlay Networks. 681 There may be a multiple virtual slices that need to be created, 682 managed and deleted, each interfacing to a number of Service 683 Providers and Network Providers as the end-points of the clients 684 span across multiple network domains. Thus, multiple components 685 will require automated co-ordination and management, this is 686 known as service orchestration and is therefore one of the key 687 capabilities that should be provided. 689 5. ACTN Objectives 691 The overall goal of enabling network abstraction and multiple 692 concurrent virtual networks to coexist on a shared physical 693 infrastructure comprised of multiple physical layers may 694 be subdivided into several smaller objectives. These are 695 outlined below and are required in order to fulfill the design 696 goals of ACTN. 698 The ACTN effort should utilize existing physical layer monitoring 699 capabilities, algorithmic representation, and modelling of 700 physical layer resources to consider transport metrics and 701 constraints. Moreover, the model of the physical layer resources 702 may need dynamic collection of the status and availability of 703 the underlying transport network infrastructure. 705 5.1. Capability and Resource Visibility 707 It may be necessary for the application or Customer to obtain 708 Information about available capabilities and available network 709 resources, for example, a view and control of abstracted resource. 710 The visibility of the capabilities and the resources can be 711 obtained either by resource discovery or by resource publishing. 712 In the former case, the customer performs resource collection 713 directly from the provider network by using discovery 714 mechanisms to get total information about the available resources 715 to be consumed. In the latter case, the network provider exposes 716 available resources to potential customers (e.g., through a 717 resource catalog) reducing the amount of detail of the 718 underlying network. 720 Furthermore, capabilities and resources will also include: 722 o Peering Points (may be based on business SLAs or policies); 724 o Transport Topology (i.e., transport switching type, topology 725 and connection points); 727 o Transport Capacity (i.e., current bandwidth and maximum 728 bandwidth). 730 o Policy Management (i.e., what resources and capabilities are 731 available, and what may be requested and by whom). 733 o Information about the provider (i.e., informative data about 734 the resource owner) 736 o Geographical information about the resources to be 737 consumed (i.e., geolocation of the resources for preventing 738 legal concerns that could appear in the provision of some 739 services). 741 o Information about resource cost, consumption, etc. (i.e., 742 energy efficiency per transmitted bit, monetary cost of the 743 resource usage per time unit, etc.). 745 o Information about achievable resiliency (i.e., 746 protection/restoration capabilities, recovery time, etc.). 748 5.2. Network Programmability 750 The creation of a programmable abstraction layer for physical 751 network devices would provide information models which 752 would allow operators to manipulate the network resources. By 753 utilizing open programmable north-bound network interfaces, it 754 would enable access to virtual control layer by customer 755 interfaces and applications. 757 A programmable interface should provide customers with the 758 capabilities to dynamically create, deploy, and operate services 759 in response to customer and application demands. 761 5.3. Common Data Models 763 The data model that describes the abstraction of the underlying 764 transport network should be agnostic to each technology 765 type within the ACTN framework. The model will provide a uniform 766 structure which is extensible to support any future 767 technologies. 769 The model will represent the physical resources as a set of 770 attributes, characteristics and functionality, while adaptively 771 capturing the true real-time and dynamic (real-time) properties 772 of underlying physical resources. 774 The data model can be decomposed into the following elements. 776 o Attributes 778 o Metrics 780 o Control Actions 781 o Semantics 783 o Administrative information (resource ownership) 785 Virtual infrastructure requests from ACTN customers will be 786 translated into network parameters according to aforementioned 787 network abstraction model. Utilizing this mechanism, a request is 788 translated into topology and multi-dimensional nodes, interfaces 789 and spectrum space with specific attributes such as bandwidth, 790 QoS, and node capability. 792 Apart from facilitating the request of resources, these data 793 models could be used for other tasks like network operation 794 (e.g., the management of the abstracted transport infrastructure 795 by the customer), configuration (e.g., the control of the 796 resources), monitoring (e.g., the uniform view of different 797 infrastructures in use), Service Level Agreements (SLA) customization 798 (e.g., the particularization of the collected metrics according to 799 the customer interests), etc. 801 5.4. Scheduling 803 When requesting network slices it should be possible to request 804 an immediate or scheduled service. 806 To enable such on-demand consumption of resources, the Network 807 Providers would be capable of employing appropriate scheduling 808 algorithms in a centralized entity, or alternatively distributed 809 across all of the network elements. 811 5.5. Slicing 813 It should be possible for transport network infrastructure to be 814 partitioned into multiple independent virtual networks through a 815 process known as "slicing". This partitioning is based on 816 provider service types, customers and application requirements. 818 5.6. Adaptability 820 Adaptability of services would allow the Service Provider, user, 821 and application to request modification of existing virtual network 822 resources that have been assigned. This may include resizing of 823 bandwidth, modification of the underlying topology, and 824 adding/removing connectivity points to modify the virtual network 825 topology itself. 827 5.7. Allocation 828 When establishing a network slice, a customer may require 829 specific guarantees for the virtual node and link attributes. 830 This might include a request that guarantees minimum packet 831 processing times on a virtual node, and fixed loss and delay 832 characteristics on the virtual links. This should be governed by 833 SLAs and can have implications in the supportive transport 834 technologies, and in the properties of the service to be offered 835 to the customer (e.g., protected versus non-protected). 837 To provide such guarantees and to create an illusion of an 838 isolated and dedicated network slice to each customer, the 839 Network Providers must employ the necesssary scheduling capability. 841 5.8. Isolation 843 Isolation, both of physical underlay infrastructure and of co- 844 existing virtual networks, is required for management and 845 confidentiality reasons. Additionally there must be no leakage of 846 traffic between different customers. 847 Furthermore, there must be mechanisms that ensure that once 848 network slices are assigned, Customer and Application services do 849 not compete for the transport resources that support their 850 virtual networks. 852 Within their virtual networks, each customer or application 853 should be able to use arbitrary network topology, routing, or 854 forwarding functions as well as customized control mechanisms 855 independent of the underlying physical network and of other 856 coexisting virtual networks. 858 It must also be possible for many virtual networks to share the 859 underlying infrastructure (multi-tenant), without impacting 860 the performance of applications utilizing the virtual networks. 862 5.9. Manageability 864 A broad range of capabilities will need to be provided 865 through a set of well-defined interfaces. These capabilities 866 apply to the management of end-to-end services and include the 867 ability to request, control, provisioning, monitoring, resilience, 868 adapt,and re-optimize those services. Specifically it should 869 be possible to provide the following funcitons. 871 o Control of virtual network resources. This control must be 872 capable of delivering end-to-end services with optimization of 873 connectivity and virtual infrastructure. Such optimization is 874 based on client interface and application demands, 875 technology constraints (bandwidth, latency, jitter, 876 function, etc.), and commercial constraints (energy, customer 877 SLA, etc.). 879 o Automation of virtual service and function requests and 880 objectives, and providing on-demand and self-service network 881 slicing subject to policy constraints set by the operators of 882 the underlying physical networks, and under the control of 883 commercial agreements between all parties. 885 o Infrastructure elasticity to allow rapid provisioning, 886 automatic scaling out, or in, of virtual resources. 888 o Virtual resource monitoring 890 o Control of bandwidth, energy consumption and quality of 891 service/packet scheduling. 893 5.10. Resilience 895 The resilience of the transport service provided to the customer 896 will depend on the requirements expressed by the customer. Two 897 different resilience scenarios may be considered: (i) the 898 resilience as observed from the point of view of the customer; 899 and (ii) the resilience as observed from the point of view of the 900 provider. 902 The former case refers to the situation in which the customer 903 requests specific resilience requirements on the offered 904 transport service. For instance, the customer can request 905 transport protection through the provision of disjoint paths 906 connecting service end-points. This specific requirement forces 907 the provider to explicitly assign transport resources to a 908 customer. 910 However there are other situations in which the provider has to 911 allocate resources for implicit resilience. For instance, the 912 customer could request a service with certain QoS or availability 913 for a single connection between service end-points according to 914 an SLA. In that case, the provider could trigger recovery actions 915 in the network, e.g. during a network outage, and according to 916 the conditions of the SLA. These measures may not be perceived by 917 the customer. 919 5.11. Security 921 Network programmability may introduce new security and 922 misconfiguration vulnerabilities. These must be investigated and 923 discussed, and then solved. ACTN-based 924 networks must be resilient to existing, and new, faults and 925 attacks. 927 Failure or security breach in one ACTN slice should not impact 928 another virtual network. It must also be possible to separate 929 untrusted services and applications, along with confidential 930 services and applications that must be secured. 932 Some other aspects are relevant to security within the context of 933 ACTN are as follows. 935 o Security aspects from the service point of view. For instance, 936 encryption capabilities as part of the service capabilities that 937 could be requested by the customer. 939 o Security aspects from the customer/provider relationship point 940 of view. For instance aspects like authentication, 941 authorization, logging, etc. 943 5.12. Policy 945 To be discussed. 947 5.13. Technology Independence 949 ACTN must support a variety of underlay transport technologies, 950 providing the flexibility to manage a variety of heterogeneous 951 network technologies. 953 5.14. Optimization 955 The service provider must be able to 956 optimize the provided transport infrastructure without impacting 957 the customer services. As the resources become consumed some 958 fragmentation in the usage of the underlying infrastructure could 959 occur. The provider then can be interested in optimizing the 960 usage of its resources for several reasons (e.g., energy 961 consumption, re-utilization of vacant resources, etc.). 963 5.15. Multi-domain Support 965 A given customer could required to compose an end-to-end 966 transport service by using network capabilities from different 967 service providers that may be internal organizations or external 968 entities. Reasons for that could be geographical coverage of the 969 service (not fully served by a unique provider), resource 970 availability (not enough resources from a given provider), or 971 simply resiliency (provider diversity). ACTN should allow the 972 multi-domain approach to give the customer the possibility of 973 composing multi-provider transport services. 975 5.16. Architectural Principles 976 5.16.1. Network Partitioning 978 Coexistence of multiple network slices will need to be supported. 979 It should also be possible for multiple network slices used by 980 different customers to coexist, spanning part or 981 all of the underlying physical networks. 983 5.16.2. Orchestration 985 ACTN should allow orchestration (automated co-ordination of 986 functions) for managing and controlling virtual network services 987 that may span multiple Service Providers and Network Providers. 989 5.16.3. Recursion 991 It should be possible for a network slice to be segmented to 992 allow a slicing hierarchy with parent child relationships. 993 Allowing a customer to become a virtual provider is known 994 as "recursion" or "nesting" of network slices. 996 5.16.4. Legacy Support and Interoperability 998 The ability to deploy ACTN should be transparent to existing 999 physical network control and management mechanisms and protocols. 1000 Additionally, interoperability with non-ACTN based (i.e., 1001 conventional) networks should be guaranteed, thus allowing for 1002 the coexistence of both kinds of network solutions from the 1003 perspective of either the customer or the provider. 1005 5.17. Other Related Work 1007 5.17.1. Requirements for Automated (Configuration) Management 1009 Given the ever-increasing complexity of the configuration tasks 1010 required for the dynamic provisioning of IP networks and 1011 services, [I-D.boucadair-network-automation-requirements] aims at 1012 listing the requirements to drive the specification of an 1013 automated configuration management framework, including the 1014 requirements for a protocol to convey configuration information 1015 towards the managed entities. 1017 5.17.2. Connectivity Provisioning Negotiation Protocol (CPNP) 1019 [I-D.boucadair-connectivity-provisioning-protocol] specifies 1020 the Connectivity Provisioning Negotiation Protocol (CPNP) which 1021 could be used to facilitate the dynamic negotiation of service 1022 parameters between a Customer and a Provider. As such, CPNP is a 1023 generic protocol that can be used for various negotiation 1024 purposes that include (but are not necessarily limited to) 1025 connectivity provisioning services, storage facilities, CDN 1026 (Content Delivery Networks) footprint, etc. 1028 The generic Connectivity Provisioning Profile (CPP) template 1029 allows for: 1031 o Automating the process of service negotiation and activation, 1032 thus accelerating service provisioning; 1034 o Setting the (traffic) objectives of Traffic Engineering 1035 functions and service management functions. 1037 o Enriching service and network management systems with 1038 'decision-making' capabilities based on negotiated/offered 1039 CPPs. 1041 6. References 1043 6.1. Informative References 1045 [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, 1046 "Generalized Multiprotocol Label Switching (GMPLS) 1047 User-Network Interface (UNI): Resource ReserVation 1048 Protocol-Traffic Engineering (RSVP-TE) Support for the 1049 Overlay Model", RFC 4208, October 2005. 1051 [RFC4110] R. Callon and M. Suzuki, "A Framework for Layer 3 1052 Provider-Provisioned Virtual Private Networks 1053 (PPVPNs)", RFC 4110, July 2005. 1055 [RFC4847] T. Takeda, Ed., "Framework and Requirements for Layer 1 1056 Virtual Private Networks", RFC 4847, April 2007. 1058 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path 1059 Computation Element (PCE)-Based Architecture", RFC 1060 4655, August 2006. 1062 [RFC4664] L. Andersson, and E. Rosen, Eds., "Framework for Layer 1063 2 Virtual Private Networks (L2VPNs)", RFC 4664, Sep 1064 2006. 1066 [RFC5440] JP. Vasseur, Ed. And JL. Le Roux, Ed. "Path Computation 1067 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 1068 March 2009. 1070 [I-D.boucadair-connectivity-provisioning-protocol] 1071 Boucadair, M. and C. Jacquenet, "Connectivity 1072 Provisioning Negotiation Protocol (CPNP)", draft- 1073 boucadair-connectivity-provisioning-protocol-09 (work 1074 in progress), March 2015. 1076 [I-D.boucadair-network-automation-requirements] 1077 Boucadair, M. and C. Jacquenet, "Requirements for 1078 Automated (Configuration) Management", draft- 1079 boucadair-network-automation-requirements-05 (work in 1080 progress), February 2015. 1082 [CHENG] W. Cheng, et. al., "ACTN Use-cases for Packet Transport 1083 Networks in Mobile Backhaul Networks", draft-cheng-actn- 1084 ptn-requirements, work in progress. 1086 [DHODY] D. Dhody, et. al., "Packet Optical Integration (POI) Use 1087 Cases for Abstraction and Control of Transport Networks 1088 (ACTN)", draft-dhody-actn-poi-use-case, work in progress. 1090 [FANG] L. Fang, "ACTN Use Case for Multi-domain Data Center 1091 Interconnect", draft-fang-actn-multidomain-dci, work in 1092 progress. 1094 [KLEE] K. Lee, H. Lee, R. Vilata, V. Lopez, "ACTN Use-case for 1095 On-demand E2E Connectivity Services in Multiple Vendor 1096 Domain Transport Networks", draft-klee-actn-connectivity- 1097 multi-vendor-domains, work in progress. 1099 [KUMAKI] K. Kumaki, T. Miyasaka, "ACTN : Use case for Multi 1100 Tenant VNO ", draft-kumaki-actn-multitenant-vno, work in 1101 progress. 1103 [LOPEZ] D. Lopez (Ed), "ACTN Use-case for Virtual Network 1104 Operation for Multiple Domains in a Single Operator 1105 Network", draft-lopez-actn-vno-multidomains, work in 1106 progress. 1108 [SHIN] J. Shin, R. Hwang, J. Lee, "ACTN Use-case for Mobile 1109 Virtual Network Operation for Multiple Domains in a Single 1110 Operator Network", draft-shin-actn-mvno-multi-domain, work 1111 in progress. 1113 [XU] Y. Xu, et. al., "Use Cases and Requirements of Dynamic 1114 Service Control based on Performance Monitoring in ACTN 1115 Architecture", draft-xu-actn-perf-dynamic-service-control, 1116 work in progress. 1118 [Y.1312] Y.1312 - Layer 1 Virtual Private Network Generic 1119 requirements and architecture elements, ITU-T 1120 Recommendation, September 2003, available from 1121 . 1123 [Y.1313] Y.1313 - Layer 1 Virtual Private Network service and 1124 network architectures, ITU-T Recommendation, July 2004, 1125 available from . 1127 [TR215] TM Forum TR251, Logical Resource Network Model 1128 Advancements and Insights, August 2014, 1129 . 1131 [TR225] TM Forum TR225, Logical Resource: Network Function 1132 Model, June 2015, . 1134 [ONF-SDN-ARCH] Software Defined Network Architcture, ONF TR-502, 1135 June 2014, . 1137 7. Acknowledgements 1139 The authors wish to thank the contributions on the IETF ACTN 1140 mailing list. 1142 8. IANA Considerations 1144 This problem statement document makes no requests for IANA action. 1146 9. Authors' Addresses 1148 Young Lee 1149 Huawei Technologies 1150 5340 Legacy Drive 1151 Plano, TX 75023, USA 1152 Phone: (469)277-5838 1153 Email: leeyoung@huawei.com 1155 Daniel King 1156 Lancaster University 1157 Email: d.king@lancaster.ac.uk 1159 Mohamed Boucadair 1160 France Telecom 1161 Rennes 35000 1162 France 1163 Email: mohamed.boucadair@orange.com 1164 Ruiquan Jing, 1165 China Telecom Corporation Limited, 1166 No. 118, Xizhimenneidajie, Xicheng District, Beijing, China 1167 Email: jingrq@ctbri.com.cn 1169 Luis Miguel Contreras Murillo 1170 Telefonica I+D 1171 Email: lmcm@tid.es