idnits 2.17.1 draft-leeking-actn-problem-statement-02.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 3, 2014) is 3616 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 2014 M. Boucadair 6 France Telecom 7 R. Jing 8 China Telecom 9 L. Contreras Murillo 10 Telefonica 12 June 3, 2014 14 Problem Statement for Abstraction and Control of Transport Networks 16 draft-leeking-actn-problem-statement-02.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 December 3, 2014. 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 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........................7 89 2.1. Virtual Private Networks..................................7 90 2.2. Overlay Networks..........................................8 91 3. Motivations for Additional Functionality.......................9 92 3.1. Business Objectives.......................................9 93 3.2. Network Resource Recursiveness...........................10 94 3.3. Customer-Initiated Programmability.......................10 95 3.4. Resource Partitioning....................................10 96 3.5. Service Orchestration....................................11 97 4. ACTN Objectives and Requirements..............................11 98 4.1. Capability and Resource Visibility.......................11 99 4.2. Network Programmability..................................12 100 4.3. Common Data Models.......................................13 101 4.4. Scheduling...............................................14 102 4.5. Allocation...............................................14 103 4.6. Adaptability.............................................15 104 4.7. Slicing..................................................15 105 4.8. Isolation................................................15 106 4.9. Manageability............................................16 107 4.10. Resilience..............................................16 108 4.11. Security................................................17 109 4.12. Policy..................................................18 110 4.13. Technology Independence.................................18 111 4.14. Optimization............................................18 112 4.15. Multi-domain Support....................................18 113 4.16. Architecture Principles.................................19 114 4.16.1. Network Partitioning...............................19 115 4.16.2. Orchestration......................................19 116 4.16.3. Recursion..........................................19 117 4.16.4. Legacy Support and Interoperability................19 118 4.17. Other Related Work......................................19 119 4.17.1. Requirements for Automated (Configuration) Management 120 ...........................................................19 121 4.17.2. Connectivity Provisioning Negotiation Protocol (CPNP) 122 ...........................................................20 123 5. References....................................................20 124 5.1. Informative References...................................20 125 6. Acknowledgements..............................................21 126 7. IANA Considerations...........................................22 127 8. Authors' Addresses............................................22 129 1. Introduction 131 Customers continue to demand new services that are time scheduled, 132 dynamic, and underpinned by a Pay As You Go billing model. These 133 services are provided to customers by network operators and service 134 providers and give rise to a variety of applications for office 135 automation, data backup and retrieval, distributed computing, and 136 high-quality media broadcasting. They offer Network and Service 137 Providers new revenue generation opportunities, and these services 138 typically have different traffic characteristics from established 139 network services such as file hosting, web, and email. Deploying and 140 operating these new applications and services using traditional 141 network technologies and architectures limits network efficiency, 142 scalability, and elasticity (i.e., capable of adapting to customer 143 and application demands). 145 Network virtualization has been a significant innovation towards 146 meeting customer demands, and enabling new applications and 147 services. Separating network resources, and representing resources 148 and topologies via abstracted concepts, facilitate effective 149 sharing, or slicing, of physical infrastructure into virtual network 150 service instances corresponding to multiple virtual network 151 topologies that may be used by specific applications, services and 152 users. Further development is required to allow customers to create, 153 modify, and delete virtual network services dynamically. 155 Previously transport networks were typically static, lacked 156 flexibility, and required long planning times when deploying new 157 services. Network Providers and Service Providers have embraced 158 technologies that allow separation of data plane and control plane, 159 distributed signaling for path setup and protection, and centralized 160 path computation for service planning and traffic engineering. 161 Although these technologies provide significant benefits, they do 162 not meet the growing need for network programmability, automation, 163 resource sharing, and service elasticity necessary for meeting 164 operator's requirement for their virtual network operation. 166 Virtual network operation refers to the creation of a virtualized 167 environment allowing operators to view the abstraction of the 168 underlying multi-admin, multi-vendor, multi-technology networks and 169 to operate, control and manage these multiple networks as single 170 virtualized network. Another dimension of virtual network operation 171 is associated with use of the common core transport network resource 172 by multi-tenant service networks as a way of providing a virtualized 173 infrastructure to flexibly offer new services and applications. 175 Abstraction and Control of Transport Networks (ACTN) defines new 176 methods and capabilities for the deployment and operation of 177 transport network resource. These are summarized as: 179 o Coordination and abstraction of underlying transport network 180 resources to higher-layer applications and customers (note 181 that higher-layer applications and customers could be 182 internal users of the core transport network resource such as 183 various service networks); 185 o Multi-domain virtual network operation that facilitates 186 multi-admin, multi-vendor, multi-technology networks as a 187 single virtualized network. 189 o Multi-tenant virtual network operation that consolidates 190 different network services and applications to allow slicing 191 of network resources to meet specific service, application 192 and customer requirements; 194 o Provision of a computation scheme and virtual control 195 capability, via a data model, to customers who request 196 virtual network services (note that these customers could be 197 service providers themselves); 199 This document provides an ACTN problem description and scope of 200 work, and outlines the core requirements to facilitate virtual 201 network operation. 203 1.1. Terminology 205 This document uses the terminology defined in [RFC4655], and 206 [RFC5440]. Additional terms are defined below. 208 o Customers: 210 Customers are users of virtual network services. They are 211 provided with an abstract resource view of the network resource 212 (known as "a slice") to support their users and applications. In 213 some cases, customers may have to support multiple virtual 214 network services with different service objectives and QoS 215 requirements to support multiple types of users and applications. 216 Customers can be internal trusted parties with respect to the 217 provider such as wholesale service department, etc. Customers can 218 also be trusted external parties with respect to the provider. 220 o Service Providers (also Virtual Network Service Provider): 222 Service Providers are the providers of virtual network services 223 to their customers. Service Providers typically lease resources 224 from single or multiple Network Providers' facilities to create 225 virtual network services and offer end-to-end services to their 226 customers. A Virtual Network Service Provider is a type of 227 Service Provider, except that they may own no physical equipment 228 or infrastructure, or have limited physical infrastructure and 229 will require virtual resources for offering the final service, 230 and only provide services built upon virtual network 231 infrastructure. In general, this document does not distinguish 232 between a Virtual Network Service Provider and Service Provider. 234 o Network Providers: 236 Network Providers are the infrastructure providers that own the 237 physical network resources and provide transport network 238 resources to their customers. Service Providers can be the 239 customers of Network Providers or can be the Network Providers 240 themselves. 242 o Network Virtualization: 244 Network virtualization, refers to allowing the customers to 245 Utilize a certain network resources as if they own them and thus 246 allows them to control their allocated resources in a way most 247 optimal with higher layer or application processes. This customer 248 control facilitates the introduction of new applications (on top 249 of available services) as the customers are given programmable 250 interfaces to create, modify, and delete their virtual network 251 services. 253 o Transport Networks 255 Transport networks are defined as network infrastructure that 256 provides connectivity and bandwidth for customer services. They 257 are characterized by their ability to support server layer 258 provisioning and traffic engineering for client layer services, 259 such that resource guarantees may be provided to their customers. 260 Transport networks in this document refer to a set of different 261 type of connection-oriented networks, which include Connection- 262 Oriented Circuit Switched (CO-CS) networks and Connection- 263 Oriented Packet Switched (CO-PS) networks. This implies that at 264 least the following transport networks are in scope of the 265 discussion of this draft: Layer 1 (L1) optical networks (e.g., 266 Optical Transport Networks (OTN) and Wavelength Switched Optical 267 Networks (WSON)), MPLS-TP, MPLS-TE, as well as other emerging 268 network technologies with connection-oriented behavior. 270 2. Relationship with Existing Technologies 272 2.1. Virtual Private Networks 274 A Virtual Private Network (VPN) is a well-known concept 275 [RFC4110], [RFC4664] and [RFC4847], and may be used to connect 276 Multiple distributed sites via a variety of transport 277 technologies, sometimes over shared network infrastructure. 279 Typically VPNs are managed and provisioned directly by the 280 Network Provider or a VPN Service Provider. VPN systems may be 281 Classified by: 283 o Protocol mechanisms used to tunnel the traffic; 285 o Tunnel termination point and/or location; 287 o Type of connectivity, site-to-site or remote-access; 289 o Quality of Service (QoS) capabilities; 290 o Level of security provided; 292 o Emulated service connectivity layer (layer 1, layer 2, 293 layer 3); 295 Existing VPN solutions are largely technology specific and offer 296 limited elasticity, although some technologies offer greater 297 flexibility (i.e., layer 2 VPNs [RFC4664] and layer 3 VPNs 298 [RFC4110]) when compared with layer 1 VPNs [RFC4847], all 299 technologies are often deployed using pre-defined configurations. 300 The transport layer is achieved by utilizing a variety of 301 technology-specific interfaces - e.g. Gigabit Ethernet (GE), 302 Synchronous Digital Hierarchy (SDH), or Asynchronous Transfer 303 Mode (ATM) for wireless back-hauling, or optical networks OTN and 304 WSON). 306 VPNs offer a scalable tunnel solution for customer traffic; 307 However, they are wholly dependent on the Service Provider to 308 setup and manage the VPNs, lacking customer-initiated service 309 programmability: creation, resizing, and deletion. 311 2.2. Overlay Networks 313 An overlay network [RFC4208] provides an enhanced network 314 virtualization technique, with the overlay network providing a 315 topology comprised of virtual or logical links and nodes, which 316 are built on top of physical nodes and links, providing a 317 topology in which some of the links and nodes are virtual or 318 logical and are built from multiple nodes or links in a server 319 network. 321 Overlay networks are typically used in the multi-layer context, 322 In which the packet layer is a client to the server transport 323 layer. The scope of network virtualization in overlay networks is 324 somewhat limited. Customers and applications which need 325 visibility or programmability, and the ability to resize or add 326 resources, may find that overlay network technologies do meet 327 their requirements. 329 3. Motivations for Additional Functionality 331 3.1. Business Objectives 333 The traditional VPN and overlay network (ON) models are built on 334 the premise that one single Network Provider provides all virtual 335 private or overlay networks to its customers. This model is 336 simple to operate but has some disadvantages in accommodating the 337 increasing need for flexible and dynamic network virtualization 338 capabilities. 340 A Network Provider may provide traditional end-to-end services 341 And content (i.e., web and email) to its customers. Emerging 342 services, applications and content are typically provided via 343 Service Providers and Over the Top (OTT) (i.e., Video-on-demand, 344 Social Media) providers. We can further categorize Service 345 Providers as: 347 o A fixed or mobile Internet Service Providers (ISPs) which 348 provide Internet connectivity and bandwidth to users; 350 o A service provider that leases network resources from one or 351 more network providers to create virtual network services 352 between ISPs and the core Internet. 354 o Data Center (DC)/content Network Provider and Service Providers 355 who provide connectivity and bandwidth to content servers and 356 application servers. 358 Network Providers and Service Providers of every type, all share 359 The common business and revenue objectives: 361 o Minimize time to plan and deploy new services; 363 o Reduce the reliance on highly skilled personnel to operate 364 their network; 366 o Reduce time to react to changing business demands and customer 367 applications; 369 o Offer new, much more flexible services to their customers; 371 o Maximize network resource usage and efficiency. 373 All aforementioned objectives have the capability to significant 374 increase revenue and reduce operational costs. 376 Network and Service Providers require capabilities that extend 377 the current landscape of network virtualization capabilities and 378 overall business objectives of the Network Provider, Service 379 Provider, and ultimately the Customer and their Applications. 381 3.2. Network Resource Recursiveness 383 A newly emerged network virtualization environment is a 384 Collection of heterogeneous network architectures from different 385 players. VPNs and overlay networks are somewhat limited in 386 addressing programmable interfaces for application or customer 387 layers as well as for the service layer. The model must be 388 extended to address a recursive nature of layer interactions in 389 network virtualization across transport networks, service 390 networks, and customers/applications. 392 3.3. Customer-Initiated Programmability 394 Network-driven technologies such as VPNs and overlay networks 395 provide customers with a set of pre-defined programmatic 396 parameters to enable virtual networks. However, this model is 397 limited to only allow programmable interfaces in which customers 398 initiate and define virtual network services. This model must be 399 extended to allow customer-initiated network programmability. 401 3.4. Resource Partitioning 403 The ability to slice and allocate transport resources for Service 404 Providers would be beneficial. It would improve transport network 405 resource efficiency and provide a method for the transport 406 Network Provider to offer resource flexibility and control to 407 Service Providers and users. 409 3.5. Service Orchestration 411 Another dimension is diversity on the customer side. Customers in 412 this newly emerged network virtualization environment bring 413 different dynamics than the traditional VPNs or Overlay Networks. 414 There may be a multiple virtual slices that need to be created, 415 managed and deleted, each interfacing to a number of Service 416 Providers and Network Providers as the end-points of the clients 417 span across multiple network domains. Thus, multiple components 418 will require automated co-ordination and management, this is 419 known as service orchestration and is therefore one of the key 420 capabilities that should be provided. 422 4. ACTN Objectives and Requirements 424 The overall goal of enabling network abstraction and multiple 425 concurrent virtual networks to coexist together on a shared 426 physical infrastructure, comprised on multiple physical layers, 427 and may be subdivided into several smaller objectives. These are 428 outlined below and are required in order to fulfill the design 429 goals of ACTN. 431 The ACTN effort should utilize existing physical layer monitoring 432 capabilities, algorithmic representation and modelling of 433 physical layer resources to consider appropriate transport 434 metrics and constraints. Moreover, the model may want to support 435 dynamic collection of the statistics (i.e., status and 436 availability) of the underlying transport network infrastructure. 438 4.1. Capability and Resource Visibility 440 It may be necessary for the application or Customer to obtain 441 available capabilities and available network resources, for 442 example, abstracted resource view and control. The visibility of 443 the capabilities and the resources can be obtained either by 444 resource discovery or by resource publishing. In the former case, 445 the customer performs resource collection directly from the 446 provider network by using discovery mechanisms to get total 447 information about the available resources to be consumed. In the 448 latter case, the network provider exposes available resources to 449 potential customers (e.g., through a resource catalog) reducing 450 the amount of detail of the underlying network. 452 Furthermore, capabilities and resources will also include: 454 o Peering Points (may be based on business SLAs or policies); 456 o Transport Topology (i.e., transport switching type, topology 457 and connection points); 459 o Transport Capacity (i.e., current bandwidth and maximum 460 bandwidth). 462 o Policy Management (i.e., what resources and capabilities are 463 available, and what may be requested and by whom). 465 o Information about the provider (i.e., informative data about 466 the resource owner) 468 o Geographical information respect to the resources to be 469 consumed (i.e., geolocation of the resources for preventing 470 legal concerns that could appear in the provision of some final 471 services). 473 o Information about resource cost, consumption, etc. (i.e., 474 energy efficiency per transmitted bit, monetary cost of the 475 resource usage per time unit, etc.). 477 o Information about achievable resiliency (i.e., 478 protection/restoration capabilities, recover time, etc.). 480 4.2. Network Programmability 482 A programmable interface should provide customers with the 483 capabilities to dynamically create, deploy, and operate services 484 in response to customer and application demands. To enable the 485 on-demand services, the separation of control and forwarding is a 486 fundamental requirement. Once this separation is achieved the 487 network layer may be programmed irrespective of the underlying 488 forwarding mechanism. 490 The creation of a programmable abstraction layer for physical 491 network devices would provide information models which 492 would allow operators to manipulate the network resources. By 493 utilizing open programmable north-bound network interfaces, it 494 would enable access to virtual control layer by customer 495 interfaces and applications. 497 4.3. Common Data Models 499 The abstraction of the underlay transport, and resource 500 Information representation model should describe each technology 501 type within the ACTN framework; they will all follow a uniform 502 structure, which is extensible to support any future 503 technologies. 505 Such models will represent the physical resources as a set of 506 attributes, characteristics and functionality, while adaptively 507 capturing the true real-time and dynamic (real-time) properties 508 of underlying physical resources. 510 For future discussion, abstraction and the technology agnostic 511 virtualization requirements may benefit from being split into new 512 sub-sections, suggested below: 514 Attributes 516 o Metrics 518 o Control Actions 520 o Semantics 522 o Administrative information (resource ownership) 524 Resources will be described with semantic methods so that the 525 resource description models can be exposed in a uniformly 526 structured manner to the upper layers. 528 Virtual infrastructure requests from ACTN customers will be 529 translated into network parameters according to aforementioned 530 network abstraction model. Utilizing this mechanism, a request is 531 translated into topology and multi-dimensional nodes, interfaces 532 and spectrum space with specific attributes such as bandwidth, 533 QoS, and node capability. 535 Apart from facilitating the request of resources, these data 536 models could be used for other tasks like network operation 537 (e.g., the management of the abstracted transport infrastructure 538 by the customer), configuration (e.g., the control of the 539 resources), monitoring (e.g., the uniform view of different 540 infrastructures in use), KPI customization (e.g., the 541 particularization of the collected metrics according to the 542 customer interests), etc. 544 4.4. Scheduling 546 When requesting network slices it should be possible to request 547 an immediate or scheduled service. 549 To enable such on-demand consumption of resources, the Network 550 Providers must employ appropriate scheduling algorithms in all of 551 the network elements. 553 4.5. Allocation 555 When establishing a network slice, a customer may require 556 specific guarantees for the virtual node and link attributes. 557 This might include a request that guarantees minimum packet 558 processing on a virtual node, and fixed loss and delay 559 characteristics on the virtual links. This should be governed by 560 Service Level Agreements (SLAs) and can have implications in the 561 supportive transport technologies, and in the properties of the 562 service to be offered to the customer (e.g., protected versus 563 non-protected). 565 To provide such guarantees and to create an illusion of an 566 Isolated and dedicated network slice to each customer, the 567 Network Providers must employ appropriate scheduling algorithms 568 in all of the network elements. 570 4.6. Adaptability 572 Adaptability of services would allow the Service Provider, user, 573 and application to request modification of exist network resource 574 that has been assigned. This may include resizing of bandwidth, 575 modification of the topology, and adding/removing connectivity 576 points. 578 4.7. Slicing 580 It should be possible for transport network infrastructure to be 581 partitioned into multiple independent virtual networks known as 582 "slicing", based on provider service types, customers and 583 application requirements. 585 4.8. Isolation 587 Isolation, both of physical underlay infrastructure and of co- 588 existing virtual networks, and ensure no leakage of traffic. 589 Furthermore, there must be mechanisms that ensure that once 590 network slices are assigned Customer and Application services are 591 not competing for transport resources. 593 Each customer or application should be able to use arbitrary 594 network topology, routing, or forwarding functions as well as 595 customized control mechanisms independent of the underlying 596 physical network and other coexisting virtual networks. 598 It must also be possible for many virtual networks to share the 599 underlying infrastructure, without significantly impacting the 600 performance of applications utilizing the virtual networks. 602 4.9. Manageability 604 A broad range of capabilities, including: request, control, 605 provisioning, monitoring, resilience, adaptation and re- 606 optimization of end-to-end services will need to be provided 607 through a set of well-defined interfaces, specifically it should 608 be possible to provide: 610 o Control of virtual network resources, capable of delivering 611 end-to-end services optimisation of connectivity and virtual 612 infrastructure based on client interface and application 613 demands, technology constraints (bandwidth, latency, jitter, 614 function, etc.) and commercial constraints (energy, customer 615 SLA, etc.). 617 o Automation of virtual service and function requests and 618 objectives, and providing on-demand and self-service network 619 slicing. 621 o Infrastructure elasticity to allow rapid provisioning, 622 automatic scaling out, or in, of virtual resources. 624 o Virtual resource monitoring [Editor's Note: Control of 625 bandwidth, energy consumption and quality of service/packet 626 scheduling.] 628 [Editor's Note: The requirements on the technology driver from 629 both sides need to be analysed, e.g. the information update 630 frequency.] 632 4.10. Resilience 634 The resilience of the transport service provided to the customer 635 will depend on the requirements expressed by the customer. Two 636 different resilience scenarios may be considered: (i) the 637 resilience as observed from the point of view of the customer; 638 and (ii) the resilience as observed from the point of view of the 639 provider. 641 The former case refers to the situation in which the customer 642 request for specific resilience requirements on the offered 643 transport service. For instance, the customer can request 644 transport protection on the disjoint paths for connecting service 645 end-points. This specific requirement forces the provider to 646 explicitly assign transport resources to a customer. 648 However there are other situations in which the provider has to 649 allocate resources for implicit resilience. For instance, the 650 customer could request a service with certain QoS or availability 651 for a single connection between service end-points according to 652 an SLA. In that case, the provider could trigger recovery actions 653 in the network, e.g. during a network outage, and according to 654 the conditions of the SLA. These measures may not be perceived by 655 the customer. 657 4.11. Security 659 Network programmability may introduce new security and 660 misconfiguration vulnerabilities. These must be investigated and 661 discussed, and then solved with suitable solutions. ACTN-based 662 networks must be resilient to existing, and new, faults and 663 attacks. 665 Failure or security breach in one ACTN slice should not impact 666 another virtual network. It must also be possible for separation 667 of untrusted services and applications, along with confidential 668 services and applications that must be secured. 670 Some other aspects are relevant to security within the context of 671 ACTN: 673 o Security aspects from the service point of view. For instance, 674 encryption capabilities as part of the service capabilities that 675 could be requested by the customer. 676 o Security aspects from the customer/provider relationship point 677 of view. For instance aspects like authentication, 678 authorization, logging, etc. 680 4.12. Policy 682 [To be discussed.] 684 4.13. Technology Independence 686 ACTN must support a variety of underlay transport technologies, 687 providing the flexibility to manage a variety of heterogeneous 688 network technologies. 690 4.14. Optimization 692 It should be guaranteed the capability of the service provider to 693 optimize the provided transport infrastructure without impacting 694 the customer services. As the resources become consumed some 695 fragmentation in the usage of the underlying infrastructure could 696 occur. The provider then can be interested in optimizing the 697 usage of its resources for several reasons (e.g., energy 698 consumption, reutilization of vacant resources, etc.). 700 4.15. Multi-domain Support 702 A given customer could required to compose an end-to-end 703 transport service by using network capabilities from different 704 service providers that may be internal organizations or external 705 entity. Reasons for that could be geographical coverage of the 706 service (not fully served by a unique provider), resource 707 availability (not enough resources from a given provider) or 708 simply resiliency (provider diversity). ACTN should allow the 709 multi domain approach for giving the customer the possibility of 710 composing multi-provider transport services. 712 4.16. Architecture Principles 714 4.16.1. Network Partitioning 716 Coexistence of multiple network slices will need to be supported. 717 It should also be possible for multiple network slices used by 718 different customers to coexist together, spanning over part or 719 full of the underlying physical networks. 721 4.16.2. Orchestration 723 ACTN should allow orchestration (automated co-ordination of 724 functions) for managing and controlling virtual network services 725 that may span multiple Service Providers and Network Providers. 727 4.16.3. Recursion 729 It should be possible for a network slice to be segmented to 730 allow a slicing hierarchy with parent child relationships. 731 Allowing a customer to become a virtual provider, this is known 732 as recursion as well as nesting of network slices. 734 4.16.4. Legacy Support and Interoperability 736 Capability to deploy ACTN should be transparent to existing 737 Physical network control and management mechanisms and protocols. 738 Additionally, interoperability with non-ACTN based (i.e., 739 conventional) networks should be guaranteed, thus allowing for 740 the coexistence of both kinds of network solutions from the 741 perspective of either the customer or the provider. 743 4.17. Other Related Work 745 4.17.1. Requirements for Automated (Configuration) Management 747 Given the ever-increasing complexity of the configuration tasks 748 required for the dynamic provisioning of IP networks and 749 services, [I-D.boucadair-network-automation-requirements] aims at 750 listing the requirements to drive the specification of an 751 automated configuration management framework, including the 752 requirements for a protocol to convey configuration information 753 towards the managed entities. 755 4.17.2. Connectivity Provisioning Negotiation Protocol (CPNP) 757 [I-D.boucadair-connectivity-provisioning-protocol] specifies 758 the Connectivity Provisioning Negotiation Protocol (CPNP) which 759 is used to facilitate the dynamic negotiation of service 760 parameters between a Customer and a Provider. As such, CPNP is a 761 generic protocol that can be used for various negotiation 762 purposes that include (but are not necessarily limited to) 763 connectivity provisioning services, storage facilities, CDN 764 (Content Delivery Networks) footprint, etc. 766 The generic CPP template allows for: 768 o Automating the process of service negotiation and activation, 769 thus accelerating service provisioning; 771 o Setting the (traffic) objectives of Traffic Engineering 772 functions and service management functions. 774 o Enriching service and network management systems with 775 'decision-making' capabilities based on negotiated/offered 776 CPPs. 778 5. References 780 5.1. Informative References 782 [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, 783 "Generalized Multiprotocol Label Switching (GMPLS) 784 User-Network Interface (UNI): Resource ReserVation 785 Protocol-Traffic Engineering (RSVP-TE) Support for the 786 Overlay Model", RFC 4208, October 2005. 788 [RFC4110] R. Callon and M. Suzuki, "A Framework for Layer 3 789 Provider-Provisioned Virtual Private Networks 790 (PPVPNs)", RFC 4110, July 2005. 792 [RFC4847] T. Takeda, Ed., "Framework and Requirements for Layer 1 793 Virtual Private Networks", RFC 4847, April 2007. 795 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path 796 Computation Element (PCE)-Based Architecture", RFC 797 4655, August 2006. 799 [RFC4664] L. Andersson, and E. Rosen, Eds., "Framework for Layer 800 2 Virtual Private Networks (L2VPNs)", RFC 4664, Sep 801 2006. 803 [RFC5440] JP. Vasseur, Ed. And JL. Le Roux, Ed. "Path Computation 804 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 805 March 2009. 807 [I-D.boucadair-connectivity-provisioning-protocol] 808 Boucadair, M. and C. Jacquenet, "Connectivity 809 Provisioning Negotiation Protocol (CPNP)", draft- 810 boucadair-connectivity-provisioning-protocol-01 (work 811 in progress), October 2013. 813 [I-D.boucadair-network-automation-requirements] 814 Boucadair, M. and C. Jacquenet, "Requirements for 815 Automated (Configuration) Management", draft- 816 boucadair-network-automation-requirements-02 (work in 817 progress), June 2013. 819 6. Acknowledgements 821 The authors wish to thank the contributions on the IETF ACTN 822 mailing list. 824 7. IANA Considerations 826 Not Applicable. 828 8. Authors' Addresses 830 Young Lee 831 Huawei Technologies 832 5340 Legacy Drive 833 Plano, TX 75023, USA 834 Phone: (469)277-5838 835 Email: leeyoung@huawei.com 837 Daniel King 838 Lancaster University 839 Email: d.king@lancaster.ac.uk 841 Mohamed Boucadair 842 France Telecom 843 Rennes 35000 844 France 845 Email: mohamed.boucadair@orange.com 847 Ruiquan Jing, 848 China Telecom Corporation Limited, 849 No. 118, Xizhimenneidajie, Xicheng District, Beijing, China 850 Email: jingrq@ctbri.com.cn 852 Luis Miguel Contreras Murillo 853 Telefonica I+D 854 Email: lmcm@tid.es 856 Intellectual Property Statement 858 The IETF Trust takes no position regarding the validity or scope 859 of any Intellectual Property Rights or other rights that might be 860 claimed to pertain to the implementation or use of the technology 861 described in any IETF Document or the extent to which any license 862 under such rights might or might not be available; nor does it 863 represent that it has made any independent effort to identify any 864 such rights. 866 Copies of Intellectual Property disclosures made to the IETF 867 Secretariat and any assurances of licenses to be made available, 868 Or the result of an attempt made to obtain a general license or 869 permission for the use of such proprietary rights by implementers 870 or users of this specification can be obtained from the IETF on- 871 line IPR repository at http://www.ietf.org/ipr 873 The IETF invites any interested party to bring to its attention 874 any copyrights, patents or patent applications, or other 875 proprietary rights that may cover technology that may be required 876 to implement any standard or specification contained in an IETF 877 Document. Please address the information to the IETF at ietf- 878 ipr@ietf.org. 880 Disclaimer of Validity 882 All IETF Documents and the information contained therein are 883 provided on an "AS IS" basis and THE CONTRIBUTOR, THE 884 ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE 885 INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING 886 TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 887 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 888 THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 889 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 891 Acknowledgment 893 Funding for the RFC Editor function is currently provided by the 894 Internet Society.