idnits 2.17.1 draft-leeking-actn-problem-statement-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- 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 (September 29, 2014) is 3490 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-01 == Outdated reference: A later version (-05) exists of draft-boucadair-network-automation-requirements-02 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Young Lee 2 Internet Draft Huawei 3 Daniel King 4 Intended status: Informational Lancaster University 5 Expires: December 2015 M. Boucadair 6 France Telecom 7 R. Jing 8 China Telecom 9 L. Contreras Murillo 10 Telefonica 12 September 29, 2014 14 Problem Statement for Abstraction and Control of Transport Networks 16 draft-leeking-actn-problem-statement-03.txt 18 Status of this Memo 20 This Internet-Draft is submitted to IETF in full conformance with 21 the provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six 29 months and may be updated, replaced, or obsoleted by other documents 30 at any time. It is inappropriate to use Internet-Drafts as 31 reference material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire March 29, 2015. 41 Copyright Notice 42 Copyright (c) 2014 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 Previously transport networks were typically static, lacked 58 flexibility, and required long planning times when deploying new 59 services. Network Providers and Service Providers have embraced 60 technologies that allow separation of data plane and control plane, 61 distributed signaling for path setup and protection, and centralized 62 path computation for service planning and traffic engineering. 63 Although these technologies provide significant benefits, they do 64 not meet the growing need for network programmability, automation, 65 resource sharing, and service elasticity necessary for meeting 66 operator's requirement for their virtual network operation. 68 Virtual network operation refers to the creation of a 69 virtualized environment allowing operators to view the 70 abstraction of the underlying multi-admin, multi-vendor, multi- 71 technology networks and to operate, control and manage these 72 multiple networks as if a single virtualized network. Another 73 dimension of virtual network operation is associated with use of 74 the common core transport network resource by multi-tenant 75 service networks as a way of providing a virtualized 76 infrastructure to flexibly offer new services and applications. 78 The work effort investigating this problem space is known as 79 Abstraction and Control of Transport Networks (ACTN). This 80 document provides an ACTN problem description, scope of work, 81 and outlines the core requirements to facilitate virtual network 82 operation. 84 Table of Contents 86 1. Introduction...................................................4 87 1.1. Terminology...............................................5 88 2. Relationship with Existing Technologies & Other Industry 89 initiatives.......................................................7 90 2.1. Virtual Private Networks..................................7 91 2.2. Overlay Networks..........................................8 92 2.3. Other Industry Initiatives................................9 93 3. Motivations for Additional Functionality.......................9 94 3.1. Business Objectives.......................................9 95 3.2. Network Resource Recursiveness...........................10 96 3.3. Customer-Initiated Programmability.......................11 97 3.4. Resource Partitioning....................................11 98 3.5. Service Orchestration....................................11 99 4. ACTN Objectives and Requirements..............................11 100 4.1. Capability and Resource Visibility.......................12 101 4.2. Network Programmability..................................13 102 4.3. Common Data Models.......................................13 103 4.4. Scheduling...............................................15 104 4.5. Allocation...............................................15 105 4.6. Adaptability.............................................15 106 4.7. Slicing..................................................15 107 4.8. Isolation................................................16 108 4.9. Manageability............................................16 109 4.10. Resilience..............................................17 110 4.11. Security................................................18 111 4.12. Policy..................................................18 112 4.13. Technology Independence.................................18 113 4.14. Optimization............................................18 114 4.15. Multi-domain Support....................................19 115 4.16. Architecture Principles.................................19 116 4.16.1. Network Partitioning...............................19 117 4.16.2. Orchestration......................................19 118 4.16.3. Recursion..........................................19 119 4.16.4. Legacy Support and Interoperability................20 120 4.17. Other Related Work......................................20 121 4.17.1. Requirements for Automated (Configuration) Management 122 ...........................................................20 123 4.17.2. Connectivity Provisioning Negotiation Protocol (CPNP) 124 ...........................................................20 125 5. References....................................................21 126 5.1. Informative References...................................21 127 6. Acknowledgements..............................................22 128 7. IANA Considerations...........................................22 129 8. Authors' Addresses............................................22 131 1. Introduction 133 Customers continue to demand new services that are time scheduled, 134 dynamic, and underpinned by a Pay As You Go billing model. These 135 services are provided to customers by network operators and service 136 providers and give rise to a variety of applications for office 137 automation, data backup and retrieval, distributed computing, and 138 high-quality media broadcasting. They offer Network and Service 139 Providers new revenue generation opportunities, and these services 140 typically have different traffic characteristics from established 141 network services such as file hosting, web, and email. Deploying and 142 operating these new applications and services using traditional 143 network technologies and architectures limits network efficiency, 144 scalability, and elasticity (i.e., capable of adapting to customer 145 and application demands). 147 Network virtualization has been a significant innovation towards 148 meeting customer demands, and enabling new applications and 149 services. Separating network resources, and representing resources 150 and topologies via abstracted concepts, facilitate effective 151 sharing, or slicing, of physical infrastructure into virtual network 152 service instances corresponding to multiple virtual network 153 topologies that may be used by specific applications, services and 154 users. Further development is required to allow customers to create, 155 modify, and delete virtual network services dynamically. 157 Previously transport networks were typically static, lacked 158 flexibility, and required long planning times when deploying new 159 services. Network Providers and Service Providers have embraced 160 technologies that allow separation of data plane and control plane, 161 distributed signaling for path setup and protection, and centralized 162 path computation for service planning and traffic engineering. 163 Although these technologies provide significant benefits, they do 164 not meet the growing need for network programmability, automation, 165 resource sharing, and service elasticity necessary for meeting 166 operator's requirement for their virtual network operation. 168 Virtual network operation refers to the creation of a virtualized 169 environment allowing operators to view the abstraction of the 170 underlying multi-admin, multi-vendor, multi-technology networks and 171 to operate, control and manage these multiple networks as single 172 virtualized network. Another dimension of virtual network operation 173 is associated with use of the common core transport network resource 174 by multi-tenant service networks as a way of providing a virtualized 175 infrastructure to flexibly offer new services and applications. 177 Abstraction and Control of Transport Networks (ACTN) defines new 178 methods and capabilities for the deployment and operation of 179 transport network resource. These are summarized as: 181 o Coordination and abstraction of underlying transport network 182 resources to higher-layer applications and customers (note 183 that higher-layer applications and customers could be 184 internal users of the core transport network resource such as 185 various service networks); 187 o Multi-domain virtual network operation that facilitates 188 multi-admin, multi-vendor, multi-technology networks as a 189 single virtualized network. 191 o Multi-tenant virtual network operation that consolidates 192 different network services and applications to allow slicing 193 of network resources to meet specific service, application 194 and customer requirements; 196 o Provision of a computation scheme and virtual control 197 capability, via a data model, to customers who request 198 virtual network services (note that these customers could be 199 service providers themselves); 201 This document provides an ACTN problem description and scope of 202 work, and outlines the core requirements to facilitate virtual 203 network operation. 205 1.1. Terminology 207 This document uses the terminology defined in [RFC4655], and 208 [RFC5440]. Additional terms are defined below. 210 o Customers: 212 Customers are users of virtual network services. They are 213 provided with an abstract resource view of the network resource 214 (known as "a slice") to support their users and applications. In 215 some cases, customers may have to support multiple virtual 216 network services with different service objectives and QoS 217 requirements to support multiple types of users and applications. 218 Customers can be internal trusted parties with respect to the 219 provider such as wholesale service department, etc. Customers can 220 also be trusted external parties with respect to the provider. 222 o Service Providers (also Virtual Network Service Provider): 224 Service Providers are the providers of virtual network services 225 to their customers. Service Providers typically lease resources 226 from single or multiple Network Providers' facilities to create 227 virtual network services and offer end-to-end services to their 228 customers. A Virtual Network Service Provider is a type of 229 Service Provider, except that they may own no physical equipment 230 or infrastructure, or have limited physical infrastructure and 231 will require virtual resources for offering the final service, 232 and only provide services built upon virtual network 233 infrastructure. In general, this document does not distinguish 234 between a Virtual Network Service Provider and Service Provider. 236 o Network Providers: 238 Network Providers are the infrastructure providers that own the 239 physical network resources and provide transport network 240 resources to their customers. Service Providers can be the 241 customers of Network Providers or can be the Network Providers 242 themselves. 244 o Network Virtualization: 246 Network virtualization, refers to allowing the customers to 247 Utilize a certain network resources as if they own them and thus 248 allows them to control their allocated resources in a way most 249 optimal with higher layer or application processes. This customer 250 control facilitates the introduction of new applications (on top 251 of available services) as the customers are given programmable 252 interfaces to create, modify, and delete their virtual network 253 services. 255 o Transport Networks 257 Transport networks are defined as network infrastructure that 258 provides connectivity and bandwidth for customer services. They 259 are characterized by their ability to support server layer 260 provisioning and traffic engineering for client layer services, 261 such that resource guarantees may be provided to their customers. 262 Transport networks in this document refer to a set of different 263 type of connection-oriented networks, which include Connection- 264 Oriented Circuit Switched (CO-CS) networks and Connection- 265 Oriented Packet Switched (CO-PS) networks. This implies that at 266 least the following transport networks are in scope: Layer 1 (L1) 267 and Layer 0 (L0) optical networks (e.g., OTN, ODU, OCh/WSON), 268 MPLS-TP, MPLS-TE, as well as other emerging network technologies 269 with connection-oriented behavior. 271 2. Relationship with Existing Technologies & Other Industry initiatives 273 2.1. Virtual Private Networks 275 A Virtual Private Network (VPN) is a well-known concept 276 [RFC4110], [RFC4664] and [RFC4847], and may be used to connect 277 Multiple distributed sites via a variety of transport 278 technologies, sometimes over shared network infrastructure. 280 Typically VPNs are managed and provisioned directly by the 281 Network Provider or a VPN Service Provider. VPN systems may be 282 Classified by: 284 o Protocol mechanisms used to tunnel the traffic; 286 o Tunnel termination point and/or location; 288 o Type of connectivity, site-to-site or remote-access; 290 o Quality of Service (QoS) capabilities; 291 o Level of security provided; 293 o Emulated service connectivity layer (layer 1, layer 2, 294 layer 3); 296 Existing VPN solutions are largely technology specific and offer 297 limited elasticity, although some technologies offer greater 298 flexibility (i.e., layer 2 VPNs [RFC4664] and layer 3 VPNs 299 [RFC4110]) when compared with layer 1 VPNs [RFC4847], all 300 technologies are often deployed using pre-defined configurations. 301 [RFC4847] describes virtual networks in terms of ITU-T Y.1312 and 302 Y.1313. Those Recommendations address both the data plane and 303 control plane aspects of VPNs. Concepts of private and shared 304 VPNs are described. 306 The transport layer is achieved by utilizing a variety of 307 technology-specific interfaces - e.g. Gigabit Ethernet (GE), 308 Synchronous Digital Hierarchy (SDH), or Asynchronous Transfer 309 Mode (ATM) for wireless back-hauling, or optical networks OTN and 310 WSON). 312 VPNs offer a scalable tunnel solution for customer traffic; 313 However, they are wholly dependent on the Service Provider to 314 setup and manage the VPNs, lacking customer-initiated service 315 programmability: creation, resizing, and deletion. 317 2.2. Overlay Networks 319 An overlay network [RFC4208] provides an enhanced network 321 virtualization technique, with the overlay network providing a 322 topology comprised of virtual or logical links and nodes, which 323 are built on top of physical nodes and links, providing a 324 topology in which some of the links and nodes are virtual or 325 logical and are built from multiple nodes or links in a server 326 network. 328 Overlay networks are typically used in the multi-layer context, 329 In which the packet layer is a client to the server transport 330 layer. The scope of network virtualization in overlay networks is 331 somewhat limited. Customers and applications which need 332 visibility or programmability, and the ability to resize or add 333 resources, may find that overlay network technologies do meet 334 their requirements. 336 2.3. Other Industry Initiatives 338 ONF SDN Architecture 339 (https://www.opennetworking.org/images/stories/downloads/sdn- 340 resources/technical-reports/TR_SDN_ARCH_1.0_06062014.pdf) 341 describes various arrangements of SDN controllers. 343 TM Forum's TR 215/TR225 addresses a common information model that 344 can be applied to transport network in particular. 346 ITU-T Y.1312 and Y.1313 are a good reference to review for Layer 1 347 VPN in terms of terminology and architecture. 349 3. Motivations for Additional Functionality 351 3.1. Business Objectives 353 The traditional VPN and overlay network (ON) models are built on 354 the premise that one single Network Provider provides all virtual 355 private or overlay networks to its customers. This model is 356 simple to operate but has some disadvantages in accommodating the 357 increasing need for flexible and dynamic network virtualization 358 capabilities. 360 A Network Provider may provide traditional end-to-end services 361 And content (i.e., web and email) to its customers. Emerging 362 services, applications and content are typically provided via 363 Service Providers and Over the Top (OTT) (i.e., Video-on-demand, 364 Social Media) providers. We can further categorize Service 365 Providers as: 367 o A fixed or mobile Internet Service Providers (ISPs) which 368 provide Internet connectivity and bandwidth to users; 370 o A service provider that leases network resources from one or 371 more network providers to create virtual network services 372 between ISPs and the core Internet. 374 o Data Center (DC)/content Network Provider and Service Providers 375 who provide connectivity and bandwidth to content servers and 376 application servers. 378 Network Providers and Service Providers of every type, all share 379 The common business and revenue objectives: 381 o Minimize time to plan and deploy new services; 383 o Reduce the reliance on highly skilled personnel to operate 384 their network; 386 o Reduce time to react to changing business demands and customer 387 applications; 389 o Offer new, much more flexible services to their customers; 391 o Maximize network resource usage and efficiency. 393 All aforementioned objectives have the capability to significant 394 increase revenue and reduce operational costs. 396 Network and Service Providers require capabilities that extend 397 the current landscape of network virtualization capabilities and 398 overall business objectives of the Network Provider, Service 399 Provider, and ultimately the Customer and their Applications. 401 3.2. Network Resource Recursiveness 403 A newly emerged network virtualization environment is a 404 Collection of heterogeneous network architectures from different 405 players. VPNs and overlay networks are somewhat limited in 406 addressing programmable interfaces for application or customer 407 layers as well as for the service layer. The model must be 408 extended to address a recursive nature of layer interactions in 409 network virtualization across transport networks, service 410 networks, and customers/applications. 412 3.3. Customer-Initiated Programmability 414 Network-driven technologies such as VPNs and overlay networks 415 provide customers with a set of pre-defined programmatic 416 parameters to enable virtual networks. However, this model is 417 limited to only allow programmable interfaces in which customers 418 initiate and define virtual network services. This model must be 419 extended to allow customer-initiated network programmability. 421 3.4. Resource Partitioning 423 The ability to slice and allocate transport resources for Service 424 Providers would be beneficial. It would improve transport network 425 resource efficiency and provide a method for the transport 426 Network Provider to offer resource flexibility and control to 427 Service Providers and users. 429 3.5. Service Orchestration 431 Another dimension is diversity on the customer side. Customers in 432 this newly emerged network virtualization environment bring 433 different dynamics than the traditional VPNs or Overlay Networks. 434 There may be a multiple virtual slices that need to be created, 435 managed and deleted, each interfacing to a number of Service 436 Providers and Network Providers as the end-points of the clients 437 span across multiple network domains. Thus, multiple components 438 will require automated co-ordination and management, this is 439 known as service orchestration and is therefore one of the key 440 capabilities that should be provided. 442 4. ACTN Objectives and Requirements 444 The overall goal of enabling network abstraction and multiple 445 concurrent virtual networks to coexist together on a shared 446 physical infrastructure, comprised on multiple physical layers, 447 and may be subdivided into several smaller objectives. These are 448 outlined below and are required in order to fulfill the design 449 goals of ACTN. 451 The ACTN effort should utilize existing physical layer monitoring 452 capabilities, algorithmic representation and modelling of 453 physical layer resources to consider appropriate transport 454 metrics and constraints. Moreover, the model may want to support 455 dynamic collection of the statistics (i.e., status and 456 availability) of the underlying transport network infrastructure. 458 4.1. Capability and Resource Visibility 460 It may be necessary for the application or Customer to obtain 461 available capabilities and available network resources, for 462 example, abstracted resource view and control. The visibility of 463 the capabilities and the resources can be obtained either by 464 resource discovery or by resource publishing. In the former case, 465 the customer performs resource collection directly from the 466 provider network by using discovery mechanisms to get total 467 information about the available resources to be consumed. In the 468 latter case, the network provider exposes available resources to 469 potential customers (e.g., through a resource catalog) reducing 470 the amount of detail of the underlying network. 472 Furthermore, capabilities and resources will also include: 474 o Peering Points (may be based on business SLAs or policies); 476 o Transport Topology (i.e., transport switching type, topology 477 and connection points); 479 o Transport Capacity (i.e., current bandwidth and maximum 480 bandwidth). 482 o Policy Management (i.e., what resources and capabilities are 483 available, and what may be requested and by whom). 485 o Information about the provider (i.e., informative data about 486 the resource owner) 488 o Geographical information respect to the resources to be 489 consumed (i.e., geolocation of the resources for preventing 490 legal concerns that could appear in the provision of some final 491 services). 493 o Information about resource cost, consumption, etc. (i.e., 494 energy efficiency per transmitted bit, monetary cost of the 495 resource usage per time unit, etc.). 497 o Information about achievable resiliency (i.e., 498 protection/restoration capabilities, recover time, etc.). 500 4.2. Network Programmability 502 A programmable interface should provide customers with the 503 capabilities to dynamically create, deploy, and operate services 504 in response to customer and application demands. To enable the 505 on-demand services, the separation of control and forwarding is a 506 fundamental requirement. Once this separation is achieved the 507 network layer may be programmed irrespective of the underlying 508 forwarding mechanism. 510 The creation of a programmable abstraction layer for physical 511 network devices would provide information models which 512 would allow operators to manipulate the network resources. By 513 utilizing open programmable north-bound network interfaces, it 514 would enable access to virtual control layer by customer 515 interfaces and applications. 517 4.3. Common Data Models 519 The abstraction of the underlay transport, and resource 520 Information representation model should describe each technology 521 type within the ACTN framework; they will all follow a uniform 522 structure, which is extensible to support any future 523 technologies. 525 Such models will represent the physical resources as a set of 526 attributes, characteristics and functionality, while adaptively 527 capturing the true real-time and dynamic (real-time) properties 528 of underlying physical resources. 530 For future discussion, abstraction and the technology agnostic 531 virtualization requirements may benefit from being split into new 532 sub-sections, suggested below: 534 Attributes 536 o Metrics 538 o Control Actions 540 o Semantics 542 o Administrative information (resource ownership) 544 Resources will be described with semantic methods so that the 545 resource description models can be exposed in a uniformly 546 structured manner to the upper layers. 548 Virtual infrastructure requests from ACTN customers will be 549 translated into network parameters according to aforementioned 550 network abstraction model. Utilizing this mechanism, a request is 551 translated into topology and multi-dimensional nodes, interfaces 552 and spectrum space with specific attributes such as bandwidth, 553 QoS, and node capability. 555 Apart from facilitating the request of resources, these data 556 models could be used for other tasks like network operation 557 (e.g., the management of the abstracted transport infrastructure 558 by the customer), configuration (e.g., the control of the 559 resources), monitoring (e.g., the uniform view of different 560 infrastructures in use), KPI customization (e.g., the 561 particularization of the collected metrics according to the 562 customer interests), etc. 564 4.4. Scheduling 566 When requesting network slices it should be possible to request 567 an immediate or scheduled service. 569 To enable such on-demand consumption of resources, the Network 570 Providers must employ appropriate scheduling algorithms in all of 571 the network elements. 573 4.5. Allocation 575 When establishing a network slice, a customer may require 576 specific guarantees for the virtual node and link attributes. 577 This might include a request that guarantees minimum packet 578 processing on a virtual node, and fixed loss and delay 579 characteristics on the virtual links. This should be governed by 580 Service Level Agreements (SLAs) and can have implications in the 581 supportive transport technologies, and in the properties of the 582 service to be offered to the customer (e.g., protected versus 583 non-protected). 585 To provide such guarantees and to create an illusion of an 586 Isolated and dedicated network slice to each customer, the 587 Network Providers must employ appropriate scheduling algorithms 588 in all of the network elements. 590 4.6. Adaptability 592 Adaptability of services would allow the Service Provider, user, 593 and application to request modification of exist network resource 594 that has been assigned. This may include resizing of bandwidth, 595 modification of the topology, and adding/removing connectivity 596 points. 598 4.7. Slicing 599 It should be possible for transport network infrastructure to be 600 partitioned into multiple independent virtual networks known as 601 "slicing", based on provider service types, customers and 602 application requirements. 604 4.8. Isolation 606 Isolation, both of physical underlay infrastructure and of co- 607 existing virtual networks, and ensure no leakage of traffic. 608 Furthermore, there must be mechanisms that ensure that once 609 network slices are assigned Customer and Application services are 610 not competing for transport resources. 612 Each customer or application should be able to use arbitrary 613 network topology, routing, or forwarding functions as well as 614 customized control mechanisms independent of the underlying 615 physical network and other coexisting virtual networks. 617 It must also be possible for many virtual networks to share the 618 underlying infrastructure, without significantly impacting the 619 performance of applications utilizing the virtual networks. 621 4.9. Manageability 623 A broad range of capabilities, including: request, control, 624 provisioning, monitoring, resilience, adaptation and re- 625 optimization of end-to-end services will need to be provided 626 through a set of well-defined interfaces, specifically it should 627 be possible to provide: 629 o Control of virtual network resources, capable of delivering 630 end-to-end services optimisation of connectivity and virtual 631 infrastructure based on client interface and application 632 demands, technology constraints (bandwidth, latency, jitter, 633 function, etc.) and commercial constraints (energy, customer 634 SLA, etc.). 636 o Automation of virtual service and function requests and 637 objectives, and providing on-demand and self-service network 638 slicing. 640 o Infrastructure elasticity to allow rapid provisioning, 641 automatic scaling out, or in, of virtual resources. 643 o Virtual resource monitoring [Editor's Note: Control of 644 bandwidth, energy consumption and quality of service/packet 645 scheduling.] 647 [Editor's Note: The requirements on the technology driver from 648 both sides need to be analysed, e.g. the information update 649 frequency.] 651 4.10. Resilience 653 The resilience of the transport service provided to the customer 654 will depend on the requirements expressed by the customer. Two 655 different resilience scenarios may be considered: (i) the 656 resilience as observed from the point of view of the customer; 657 and (ii) the resilience as observed from the point of view of the 658 provider. 660 The former case refers to the situation in which the customer 661 request for specific resilience requirements on the offered 662 transport service. For instance, the customer can request 663 transport protection on the disjoint paths for connecting service 664 end-points. This specific requirement forces the provider to 665 explicitly assign transport resources to a customer. 667 However there are other situations in which the provider has to 668 allocate resources for implicit resilience. For instance, the 669 customer could request a service with certain QoS or availability 670 for a single connection between service end-points according to 671 an SLA. In that case, the provider could trigger recovery actions 672 in the network, e.g. during a network outage, and according to 673 the conditions of the SLA. These measures may not be perceived by 674 the customer. 676 4.11. Security 678 Network programmability may introduce new security and 679 misconfiguration vulnerabilities. These must be investigated and 680 discussed, and then solved with suitable solutions. ACTN-based 681 networks must be resilient to existing, and new, faults and 682 attacks. 684 Failure or security breach in one ACTN slice should not impact 685 another virtual network. It must also be possible for separation 686 of untrusted services and applications, along with confidential 687 services and applications that must be secured. 689 Some other aspects are relevant to security within the context of 690 ACTN: 692 o Security aspects from the service point of view. For instance, 693 encryption capabilities as part of the service capabilities that 694 could be requested by the customer. 695 o Security aspects from the customer/provider relationship point 696 of view. For instance aspects like authentication, 697 authorization, logging, etc. 699 4.12. Policy 701 [To be discussed.] 703 4.13. Technology Independence 705 ACTN must support a variety of underlay transport technologies, 706 providing the flexibility to manage a variety of heterogeneous 707 network technologies. 709 4.14. Optimization 711 It should be guaranteed the capability of the service provider to 712 optimize the provided transport infrastructure without impacting 713 the customer services. As the resources become consumed some 714 fragmentation in the usage of the underlying infrastructure could 715 occur. The provider then can be interested in optimizing the 716 usage of its resources for several reasons (e.g., energy 717 consumption, reutilization of vacant resources, etc.). 719 4.15. Multi-domain Support 721 A given customer could required to compose an end-to-end 722 transport service by using network capabilities from different 723 service providers that may be internal organizations or external 724 entity. Reasons for that could be geographical coverage of the 725 service (not fully served by a unique provider), resource 726 availability (not enough resources from a given provider) or 727 simply resiliency (provider diversity). ACTN should allow the 728 multi domain approach for giving the customer the possibility of 729 composing multi-provider transport services. 731 4.16. Architecture Principles 733 4.16.1. Network Partitioning 735 Coexistence of multiple network slices will need to be supported. 736 It should also be possible for multiple network slices used by 737 different customers to coexist together, spanning over part or 738 full of the underlying physical networks. 740 4.16.2. Orchestration 742 ACTN should allow orchestration (automated co-ordination of 743 functions) for managing and controlling virtual network services 744 that may span multiple Service Providers and Network Providers. 746 4.16.3. Recursion 747 It should be possible for a network slice to be segmented to 748 allow a slicing hierarchy with parent child relationships. 749 Allowing a customer to become a virtual provider, this is known 750 as recursion as well as nesting of network slices. 752 4.16.4. Legacy Support and Interoperability 754 Capability to deploy ACTN should be transparent to existing 755 Physical network control and management mechanisms and protocols. 756 Additionally, interoperability with non-ACTN based (i.e., 757 conventional) networks should be guaranteed, thus allowing for 758 the coexistence of both kinds of network solutions from the 759 perspective of either the customer or the provider. 761 4.17. Other Related Work 763 4.17.1. Requirements for Automated (Configuration) Management 765 Given the ever-increasing complexity of the configuration tasks 766 required for the dynamic provisioning of IP networks and 767 services, [I-D.boucadair-network-automation-requirements] aims at 768 listing the requirements to drive the specification of an 769 automated configuration management framework, including the 770 requirements for a protocol to convey configuration information 771 towards the managed entities. 773 4.17.2. Connectivity Provisioning Negotiation Protocol (CPNP) 775 [I-D.boucadair-connectivity-provisioning-protocol] specifies 776 the Connectivity Provisioning Negotiation Protocol (CPNP) which 777 is used to facilitate the dynamic negotiation of service 778 parameters between a Customer and a Provider. As such, CPNP is a 779 generic protocol that can be used for various negotiation 780 purposes that include (but are not necessarily limited to) 781 connectivity provisioning services, storage facilities, CDN 782 (Content Delivery Networks) footprint, etc. 784 The generic CPP template allows for: 786 o Automating the process of service negotiation and activation, 787 thus accelerating service provisioning; 789 o Setting the (traffic) objectives of Traffic Engineering 790 functions and service management functions. 792 o Enriching service and network management systems with 793 'decision-making' capabilities based on negotiated/offered 794 CPPs. 796 5. References 798 5.1. Informative References 800 [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, 801 "Generalized Multiprotocol Label Switching (GMPLS) 802 User-Network Interface (UNI): Resource ReserVation 803 Protocol-Traffic Engineering (RSVP-TE) Support for the 804 Overlay Model", RFC 4208, October 2005. 806 [RFC4110] R. Callon and M. Suzuki, "A Framework for Layer 3 807 Provider-Provisioned Virtual Private Networks 808 (PPVPNs)", RFC 4110, July 2005. 810 [RFC4847] T. Takeda, Ed., "Framework and Requirements for Layer 1 811 Virtual Private Networks", RFC 4847, April 2007. 813 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path 814 Computation Element (PCE)-Based Architecture", RFC 815 4655, August 2006. 817 [RFC4664] L. Andersson, and E. Rosen, Eds., "Framework for Layer 818 2 Virtual Private Networks (L2VPNs)", RFC 4664, Sep 819 2006. 821 [RFC5440] JP. Vasseur, Ed. And JL. Le Roux, Ed. "Path Computation 822 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 823 March 2009. 825 [I-D.boucadair-connectivity-provisioning-protocol] 826 Boucadair, M. and C. Jacquenet, "Connectivity 827 Provisioning Negotiation Protocol (CPNP)", draft- 828 boucadair-connectivity-provisioning-protocol-01 (work 829 in progress), October 2013. 831 [I-D.boucadair-network-automation-requirements] 832 Boucadair, M. and C. Jacquenet, "Requirements for 833 Automated (Configuration) Management", draft- 834 boucadair-network-automation-requirements-02 (work in 835 progress), June 2013. 837 6. Acknowledgements 839 The authors wish to thank the contributions on the IETF ACTN 840 mailing list. 842 7. IANA Considerations 844 Not Applicable. 846 8. Authors' Addresses 848 Young Lee 849 Huawei Technologies 850 5340 Legacy Drive 851 Plano, TX 75023, USA 852 Phone: (469)277-5838 853 Email: leeyoung@huawei.com 855 Daniel King 856 Lancaster University 857 Email: d.king@lancaster.ac.uk 859 Mohamed Boucadair 860 France Telecom 861 Rennes 35000 862 France 863 Email: mohamed.boucadair@orange.com 865 Ruiquan Jing, 866 China Telecom Corporation Limited, 867 No. 118, Xizhimenneidajie, Xicheng District, Beijing, China 868 Email: jingrq@ctbri.com.cn 870 Luis Miguel Contreras Murillo 871 Telefonica I+D 872 Email: lmcm@tid.es 874 Intellectual Property Statement 876 The IETF Trust takes no position regarding the validity or scope 877 of any Intellectual Property Rights or other rights that might be 878 claimed to pertain to the implementation or use of the technology 879 described in any IETF Document or the extent to which any license 880 under such rights might or might not be available; nor does it 881 represent that it has made any independent effort to identify any 882 such rights. 884 Copies of Intellectual Property disclosures made to the IETF 885 Secretariat and any assurances of licenses to be made available, 886 Or the result of an attempt made to obtain a general license or 887 permission for the use of such proprietary rights by implementers 888 or users of this specification can be obtained from the IETF on- 889 line IPR repository at http://www.ietf.org/ipr 891 The IETF invites any interested party to bring to its attention 892 any copyrights, patents or patent applications, or other 893 proprietary rights that may cover technology that may be required 894 to implement any standard or specification contained in an IETF 895 Document. Please address the information to the IETF at ietf- 896 ipr@ietf.org. 898 Disclaimer of Validity 900 All IETF Documents and the information contained therein are 901 provided on an "AS IS" basis and THE CONTRIBUTOR, THE 902 ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE 903 INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING 904 TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 905 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 906 THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 907 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 909 Acknowledgment 911 Funding for the RFC Editor function is currently provided by the 912 Internet Society.