Network Working Group Young Lee Internet Draft Huawei Daniel King Intended status: Informational Lancaster University Expires: December 2014 M. Boucadair France Telecom R. Jing China Telecom L. Contreras Murillo Telefonica June 3, 2014 Problem Statement for Abstraction and Control of Transport Networks draft-leeking-actn-problem-statement-02.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire December 3, 2014. Copyright Notice Lee and King Expires December 3, 2014 [Page 1] Internet-Draft ACTN Problem Statement June 2014 Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Abstract Previously transport networks were typically static, lacked flexibility, and required long planning times when deploying new services. Network Providers and Service Providers have embraced technologies that allow separation of data plane and control plane, distributed signaling for path setup and protection, and centralized path computation for service planning and traffic engineering. Although these technologies provide significant benefits, they do not meet the growing need for network programmability, automation, resource sharing, and service elasticity necessary for meeting operator's requirement for their virtual network operation. Virtual network operation refers to the creation of a virtualized environment allowing operators to view the abstraction of the underlying multi-admin, multi-vendor, multi- technology networks and to operate, control and manage these multiple networks as single virtualized network. Another dimension of virtual network operation is associated with use of the common core transport network resource by multi-tenant service networks as a way of providing a virtualized infrastructure to flexibly offer new services and applications. The work effort investigating this problem space is known as Abstraction and Control of Transport Networks (ACTN). This document provides an ACTN problem description, scope of work, and outlines the core requirements to facilitate virtual network operation. Lee & King Expires December, 2014 [Page 2] Internet-Draft ACTN Problem Statement June 2014 Table of Contents 1. Introduction...................................................4 1.1. Terminology...............................................5 2. Relationship with Existing Technologies........................7 2.1. Virtual Private Networks..................................7 2.2. Overlay Networks..........................................8 3. Motivations for Additional Functionality.......................9 3.1. Business Objectives.......................................9 3.2. Network Resource Recursiveness...........................10 3.3. Customer-Initiated Programmability.......................10 3.4. Resource Partitioning....................................10 3.5. Service Orchestration....................................11 4. ACTN Objectives and Requirements..............................11 4.1. Capability and Resource Visibility.......................11 4.2. Network Programmability..................................12 4.3. Common Data Models.......................................13 4.4. Scheduling...............................................14 4.5. Allocation...............................................14 4.6. Adaptability.............................................15 4.7. Slicing..................................................15 4.8. Isolation................................................15 4.9. Manageability............................................16 4.10. Resilience..............................................16 4.11. Security................................................17 4.12. Policy..................................................18 4.13. Technology Independence.................................18 4.14. Optimization............................................18 4.15. Multi-domain Support....................................18 4.16. Architecture Principles.................................19 4.16.1. Network Partitioning...............................19 4.16.2. Orchestration......................................19 4.16.3. Recursion..........................................19 4.16.4. Legacy Support and Interoperability................19 4.17. Other Related Work......................................19 4.17.1. Requirements for Automated (Configuration) Management ...........................................................19 4.17.2. Connectivity Provisioning Negotiation Protocol (CPNP) ...........................................................20 5. References....................................................20 5.1. Informative References...................................20 6. Acknowledgements..............................................21 7. IANA Considerations...........................................22 8. Authors' Addresses............................................22 Lee & King Expires December, 2014 [Page 3] Internet-Draft ACTN Problem Statement June 2014 1. Introduction Customers continue to demand new services that are time scheduled, dynamic, and underpinned by a Pay As You Go billing model. These services are provided to customers by network operators and service providers and give rise to a variety of applications for office automation, data backup and retrieval, distributed computing, and high-quality media broadcasting. They offer Network and Service Providers new revenue generation opportunities, and these services typically have different traffic characteristics from established network services such as file hosting, web, and email. Deploying and operating these new applications and services using traditional network technologies and architectures limits network efficiency, scalability, and elasticity (i.e., capable of adapting to customer and application demands). Network virtualization has been a significant innovation towards meeting customer demands, and enabling new applications and services. Separating network resources, and representing resources and topologies via abstracted concepts, facilitate effective sharing, or slicing, of physical infrastructure into virtual network service instances corresponding to multiple virtual network topologies that may be used by specific applications, services and users. Further development is required to allow customers to create, modify, and delete virtual network services dynamically. Previously transport networks were typically static, lacked flexibility, and required long planning times when deploying new services. Network Providers and Service Providers have embraced technologies that allow separation of data plane and control plane, distributed signaling for path setup and protection, and centralized path computation for service planning and traffic engineering. Although these technologies provide significant benefits, they do not meet the growing need for network programmability, automation, resource sharing, and service elasticity necessary for meeting operator's requirement for their virtual network operation. Virtual network operation refers to the creation of a virtualized environment allowing operators to view the abstraction of the underlying multi-admin, multi-vendor, multi-technology networks and to operate, control and manage these multiple networks as single virtualized network. Another dimension of virtual network operation is associated with use of the common core transport network resource by multi-tenant service networks as a way of providing a virtualized infrastructure to flexibly offer new services and applications. Lee & King Expires December, 2014 [Page 4] Internet-Draft ACTN Problem Statement June 2014 Abstraction and Control of Transport Networks (ACTN) defines new methods and capabilities for the deployment and operation of transport network resource. These are summarized as: o Coordination and abstraction of underlying transport network resources to higher-layer applications and customers (note that higher-layer applications and customers could be internal users of the core transport network resource such as various service networks); o Multi-domain virtual network operation that facilitates multi-admin, multi-vendor, multi-technology networks as a single virtualized network. o Multi-tenant virtual network operation that consolidates different network services and applications to allow slicing of network resources to meet specific service, application and customer requirements; o Provision of a computation scheme and virtual control capability, via a data model, to customers who request virtual network services (note that these customers could be service providers themselves); This document provides an ACTN problem description and scope of work, and outlines the core requirements to facilitate virtual network operation. 1.1. Terminology This document uses the terminology defined in [RFC4655], and [RFC5440]. Additional terms are defined below. o Customers: Customers are users of virtual network services. They are provided with an abstract resource view of the network resource (known as "a slice") to support their users and applications. In Lee & King Expires December, 2014 [Page 5] Internet-Draft ACTN Problem Statement June 2014 some cases, customers may have to support multiple virtual network services with different service objectives and QoS requirements to support multiple types of users and applications. Customers can be internal trusted parties with respect to the provider such as wholesale service department, etc. Customers can also be trusted external parties with respect to the provider. o Service Providers (also Virtual Network Service Provider): Service Providers are the providers of virtual network services to their customers. Service Providers typically lease resources from single or multiple Network Providers' facilities to create virtual network services and offer end-to-end services to their customers. A Virtual Network Service Provider is a type of Service Provider, except that they may own no physical equipment or infrastructure, or have limited physical infrastructure and will require virtual resources for offering the final service, and only provide services built upon virtual network infrastructure. In general, this document does not distinguish between a Virtual Network Service Provider and Service Provider. o Network Providers: Network Providers are the infrastructure providers that own the physical network resources and provide transport network resources to their customers. Service Providers can be the customers of Network Providers or can be the Network Providers themselves. o Network Virtualization: Network virtualization, refers to allowing the customers to Utilize a certain network resources as if they own them and thus allows them to control their allocated resources in a way most optimal with higher layer or application processes. This customer control facilitates the introduction of new applications (on top of available services) as the customers are given programmable interfaces to create, modify, and delete their virtual network services. o Transport Networks Lee & King Expires December, 2014 [Page 6] Internet-Draft ACTN Problem Statement June 2014 Transport networks are defined as network infrastructure that provides connectivity and bandwidth for customer services. They are characterized by their ability to support server layer provisioning and traffic engineering for client layer services, such that resource guarantees may be provided to their customers. Transport networks in this document refer to a set of different type of connection-oriented networks, which include Connection- Oriented Circuit Switched (CO-CS) networks and Connection- Oriented Packet Switched (CO-PS) networks. This implies that at least the following transport networks are in scope of the discussion of this draft: Layer 1 (L1) optical networks (e.g., Optical Transport Networks (OTN) and Wavelength Switched Optical Networks (WSON)), MPLS-TP, MPLS-TE, as well as other emerging network technologies with connection-oriented behavior. 2. Relationship with Existing Technologies 2.1. Virtual Private Networks A Virtual Private Network (VPN) is a well-known concept [RFC4110], [RFC4664] and [RFC4847], and may be used to connect Multiple distributed sites via a variety of transport technologies, sometimes over shared network infrastructure. Typically VPNs are managed and provisioned directly by the Network Provider or a VPN Service Provider. VPN systems may be Classified by: o Protocol mechanisms used to tunnel the traffic; o Tunnel termination point and/or location; o Type of connectivity, site-to-site or remote-access; o Quality of Service (QoS) capabilities; Lee & King Expires December, 2014 [Page 7] Internet-Draft ACTN Problem Statement June 2014 o Level of security provided; o Emulated service connectivity layer (layer 1, layer 2, layer 3); Existing VPN solutions are largely technology specific and offer limited elasticity, although some technologies offer greater flexibility (i.e., layer 2 VPNs [RFC4664] and layer 3 VPNs [RFC4110]) when compared with layer 1 VPNs [RFC4847], all technologies are often deployed using pre-defined configurations. The transport layer is achieved by utilizing a variety of technology-specific interfaces - e.g. Gigabit Ethernet (GE), Synchronous Digital Hierarchy (SDH), or Asynchronous Transfer Mode (ATM) for wireless back-hauling, or optical networks OTN and WSON). VPNs offer a scalable tunnel solution for customer traffic; However, they are wholly dependent on the Service Provider to setup and manage the VPNs, lacking customer-initiated service programmability: creation, resizing, and deletion. 2.2. Overlay Networks An overlay network [RFC4208] provides an enhanced network virtualization technique, with the overlay network providing a topology comprised of virtual or logical links and nodes, which are built on top of physical nodes and links, providing a topology in which some of the links and nodes are virtual or logical and are built from multiple nodes or links in a server network. Overlay networks are typically used in the multi-layer context, In which the packet layer is a client to the server transport layer. The scope of network virtualization in overlay networks is somewhat limited. Customers and applications which need visibility or programmability, and the ability to resize or add resources, may find that overlay network technologies do meet their requirements. Lee & King Expires December, 2014 [Page 8] Internet-Draft ACTN Problem Statement June 2014 3. Motivations for Additional Functionality 3.1. Business Objectives The traditional VPN and overlay network (ON) models are built on the premise that one single Network Provider provides all virtual private or overlay networks to its customers. This model is simple to operate but has some disadvantages in accommodating the increasing need for flexible and dynamic network virtualization capabilities. A Network Provider may provide traditional end-to-end services And content (i.e., web and email) to its customers. Emerging services, applications and content are typically provided via Service Providers and Over the Top (OTT) (i.e., Video-on-demand, Social Media) providers. We can further categorize Service Providers as: o A fixed or mobile Internet Service Providers (ISPs) which provide Internet connectivity and bandwidth to users; o A service provider that leases network resources from one or more network providers to create virtual network services between ISPs and the core Internet. o Data Center (DC)/content Network Provider and Service Providers who provide connectivity and bandwidth to content servers and application servers. Network Providers and Service Providers of every type, all share The common business and revenue objectives: o Minimize time to plan and deploy new services; o Reduce the reliance on highly skilled personnel to operate their network; o Reduce time to react to changing business demands and customer applications; Lee & King Expires December, 2014 [Page 9] Internet-Draft ACTN Problem Statement June 2014 o Offer new, much more flexible services to their customers; o Maximize network resource usage and efficiency. All aforementioned objectives have the capability to significant increase revenue and reduce operational costs. Network and Service Providers require capabilities that extend the current landscape of network virtualization capabilities and overall business objectives of the Network Provider, Service Provider, and ultimately the Customer and their Applications. 3.2. Network Resource Recursiveness A newly emerged network virtualization environment is a Collection of heterogeneous network architectures from different players. VPNs and overlay networks are somewhat limited in addressing programmable interfaces for application or customer layers as well as for the service layer. The model must be extended to address a recursive nature of layer interactions in network virtualization across transport networks, service networks, and customers/applications. 3.3. Customer-Initiated Programmability Network-driven technologies such as VPNs and overlay networks provide customers with a set of pre-defined programmatic parameters to enable virtual networks. However, this model is limited to only allow programmable interfaces in which customers initiate and define virtual network services. This model must be extended to allow customer-initiated network programmability. 3.4. Resource Partitioning The ability to slice and allocate transport resources for Service Providers would be beneficial. It would improve transport network resource efficiency and provide a method for the transport Network Provider to offer resource flexibility and control to Lee & King Expires December, 2014 [Page 10] Internet-Draft ACTN Problem Statement June 2014 Service Providers and users. 3.5. Service Orchestration Another dimension is diversity on the customer side. Customers in this newly emerged network virtualization environment bring different dynamics than the traditional VPNs or Overlay Networks. There may be a multiple virtual slices that need to be created, managed and deleted, each interfacing to a number of Service Providers and Network Providers as the end-points of the clients span across multiple network domains. Thus, multiple components will require automated co-ordination and management, this is known as service orchestration and is therefore one of the key capabilities that should be provided. 4. ACTN Objectives and Requirements The overall goal of enabling network abstraction and multiple concurrent virtual networks to coexist together on a shared physical infrastructure, comprised on multiple physical layers, and may be subdivided into several smaller objectives. These are outlined below and are required in order to fulfill the design goals of ACTN. The ACTN effort should utilize existing physical layer monitoring capabilities, algorithmic representation and modelling of physical layer resources to consider appropriate transport metrics and constraints. Moreover, the model may want to support dynamic collection of the statistics (i.e., status and availability) of the underlying transport network infrastructure. 4.1. Capability and Resource Visibility It may be necessary for the application or Customer to obtain available capabilities and available network resources, for example, abstracted resource view and control. The visibility of the capabilities and the resources can be obtained either by resource discovery or by resource publishing. In the former case, the customer performs resource collection directly from the Lee & King Expires December, 2014 [Page 11] Internet-Draft ACTN Problem Statement June 2014 provider network by using discovery mechanisms to get total information about the available resources to be consumed. In the latter case, the network provider exposes available resources to potential customers (e.g., through a resource catalog) reducing the amount of detail of the underlying network. Furthermore, capabilities and resources will also include: o Peering Points (may be based on business SLAs or policies); o Transport Topology (i.e., transport switching type, topology and connection points); o Transport Capacity (i.e., current bandwidth and maximum bandwidth). o Policy Management (i.e., what resources and capabilities are available, and what may be requested and by whom). o Information about the provider (i.e., informative data about the resource owner) o Geographical information respect to the resources to be consumed (i.e., geolocation of the resources for preventing legal concerns that could appear in the provision of some final services). o Information about resource cost, consumption, etc. (i.e., energy efficiency per transmitted bit, monetary cost of the resource usage per time unit, etc.). o Information about achievable resiliency (i.e., protection/restoration capabilities, recover time, etc.). 4.2. Network Programmability A programmable interface should provide customers with the capabilities to dynamically create, deploy, and operate services in response to customer and application demands. To enable the Lee & King Expires December, 2014 [Page 12] Internet-Draft ACTN Problem Statement June 2014 on-demand services, the separation of control and forwarding is a fundamental requirement. Once this separation is achieved the network layer may be programmed irrespective of the underlying forwarding mechanism. The creation of a programmable abstraction layer for physical network devices would provide information models which would allow operators to manipulate the network resources. By utilizing open programmable north-bound network interfaces, it would enable access to virtual control layer by customer interfaces and applications. 4.3. Common Data Models The abstraction of the underlay transport, and resource Information representation model should describe each technology type within the ACTN framework; they will all follow a uniform structure, which is extensible to support any future technologies. Such models will represent the physical resources as a set of attributes, characteristics and functionality, while adaptively capturing the true real-time and dynamic (real-time) properties of underlying physical resources. For future discussion, abstraction and the technology agnostic virtualization requirements may benefit from being split into new sub-sections, suggested below: Attributes o Metrics o Control Actions o Semantics o Administrative information (resource ownership) Lee & King Expires December, 2014 [Page 13] Internet-Draft ACTN Problem Statement June 2014 Resources will be described with semantic methods so that the resource description models can be exposed in a uniformly structured manner to the upper layers. Virtual infrastructure requests from ACTN customers will be translated into network parameters according to aforementioned network abstraction model. Utilizing this mechanism, a request is translated into topology and multi-dimensional nodes, interfaces and spectrum space with specific attributes such as bandwidth, QoS, and node capability. Apart from facilitating the request of resources, these data models could be used for other tasks like network operation (e.g., the management of the abstracted transport infrastructure by the customer), configuration (e.g., the control of the resources), monitoring (e.g., the uniform view of different infrastructures in use), KPI customization (e.g., the particularization of the collected metrics according to the customer interests), etc. 4.4. Scheduling When requesting network slices it should be possible to request an immediate or scheduled service. To enable such on-demand consumption of resources, the Network Providers must employ appropriate scheduling algorithms in all of the network elements. 4.5. Allocation When establishing a network slice, a customer may require specific guarantees for the virtual node and link attributes. This might include a request that guarantees minimum packet processing on a virtual node, and fixed loss and delay characteristics on the virtual links. This should be governed by Service Level Agreements (SLAs) and can have implications in the supportive transport technologies, and in the properties of the Lee & King Expires December, 2014 [Page 14] Internet-Draft ACTN Problem Statement June 2014 service to be offered to the customer (e.g., protected versus non-protected). To provide such guarantees and to create an illusion of an Isolated and dedicated network slice to each customer, the Network Providers must employ appropriate scheduling algorithms in all of the network elements. 4.6. Adaptability Adaptability of services would allow the Service Provider, user, and application to request modification of exist network resource that has been assigned. This may include resizing of bandwidth, modification of the topology, and adding/removing connectivity points. 4.7. Slicing It should be possible for transport network infrastructure to be partitioned into multiple independent virtual networks known as "slicing", based on provider service types, customers and application requirements. 4.8. Isolation Isolation, both of physical underlay infrastructure and of co- existing virtual networks, and ensure no leakage of traffic. Furthermore, there must be mechanisms that ensure that once network slices are assigned Customer and Application services are not competing for transport resources. Each customer or application should be able to use arbitrary network topology, routing, or forwarding functions as well as customized control mechanisms independent of the underlying physical network and other coexisting virtual networks. It must also be possible for many virtual networks to share the underlying infrastructure, without significantly impacting the Lee & King Expires December, 2014 [Page 15] Internet-Draft ACTN Problem Statement June 2014 performance of applications utilizing the virtual networks. 4.9. Manageability A broad range of capabilities, including: request, control, provisioning, monitoring, resilience, adaptation and re- optimization of end-to-end services will need to be provided through a set of well-defined interfaces, specifically it should be possible to provide: o Control of virtual network resources, capable of delivering end-to-end services optimisation of connectivity and virtual infrastructure based on client interface and application demands, technology constraints (bandwidth, latency, jitter, function, etc.) and commercial constraints (energy, customer SLA, etc.). o Automation of virtual service and function requests and objectives, and providing on-demand and self-service network slicing. o Infrastructure elasticity to allow rapid provisioning, automatic scaling out, or in, of virtual resources. o Virtual resource monitoring [Editor's Note: Control of bandwidth, energy consumption and quality of service/packet scheduling.] [Editor's Note: The requirements on the technology driver from both sides need to be analysed, e.g. the information update frequency.] 4.10. Resilience The resilience of the transport service provided to the customer will depend on the requirements expressed by the customer. Two different resilience scenarios may be considered: (i) the resilience as observed from the point of view of the customer; and (ii) the resilience as observed from the point of view of the Lee & King Expires December, 2014 [Page 16] Internet-Draft ACTN Problem Statement June 2014 provider. The former case refers to the situation in which the customer request for specific resilience requirements on the offered transport service. For instance, the customer can request transport protection on the disjoint paths for connecting service end-points. This specific requirement forces the provider to explicitly assign transport resources to a customer. However there are other situations in which the provider has to allocate resources for implicit resilience. For instance, the customer could request a service with certain QoS or availability for a single connection between service end-points according to an SLA. In that case, the provider could trigger recovery actions in the network, e.g. during a network outage, and according to the conditions of the SLA. These measures may not be perceived by the customer. 4.11. Security Network programmability may introduce new security and misconfiguration vulnerabilities. These must be investigated and discussed, and then solved with suitable solutions. ACTN-based networks must be resilient to existing, and new, faults and attacks. Failure or security breach in one ACTN slice should not impact another virtual network. It must also be possible for separation of untrusted services and applications, along with confidential services and applications that must be secured. Some other aspects are relevant to security within the context of ACTN: o Security aspects from the service point of view. For instance, encryption capabilities as part of the service capabilities that could be requested by the customer. o Security aspects from the customer/provider relationship point of view. For instance aspects like authentication, Lee & King Expires December, 2014 [Page 17] Internet-Draft ACTN Problem Statement June 2014 authorization, logging, etc. 4.12. Policy [To be discussed.] 4.13. Technology Independence ACTN must support a variety of underlay transport technologies, providing the flexibility to manage a variety of heterogeneous network technologies. 4.14. Optimization It should be guaranteed the capability of the service provider to optimize the provided transport infrastructure without impacting the customer services. As the resources become consumed some fragmentation in the usage of the underlying infrastructure could occur. The provider then can be interested in optimizing the usage of its resources for several reasons (e.g., energy consumption, reutilization of vacant resources, etc.). 4.15. Multi-domain Support A given customer could required to compose an end-to-end transport service by using network capabilities from different service providers that may be internal organizations or external entity. Reasons for that could be geographical coverage of the service (not fully served by a unique provider), resource availability (not enough resources from a given provider) or simply resiliency (provider diversity). ACTN should allow the multi domain approach for giving the customer the possibility of composing multi-provider transport services. Lee & King Expires December, 2014 [Page 18] Internet-Draft ACTN Problem Statement June 2014 4.16. Architecture Principles 4.16.1. Network Partitioning Coexistence of multiple network slices will need to be supported. It should also be possible for multiple network slices used by different customers to coexist together, spanning over part or full of the underlying physical networks. 4.16.2. Orchestration ACTN should allow orchestration (automated co-ordination of functions) for managing and controlling virtual network services that may span multiple Service Providers and Network Providers. 4.16.3. Recursion It should be possible for a network slice to be segmented to allow a slicing hierarchy with parent child relationships. Allowing a customer to become a virtual provider, this is known as recursion as well as nesting of network slices. 4.16.4. Legacy Support and Interoperability Capability to deploy ACTN should be transparent to existing Physical network control and management mechanisms and protocols. Additionally, interoperability with non-ACTN based (i.e., conventional) networks should be guaranteed, thus allowing for the coexistence of both kinds of network solutions from the perspective of either the customer or the provider. 4.17. Other Related Work 4.17.1. Requirements for Automated (Configuration) Management Given the ever-increasing complexity of the configuration tasks Lee & King Expires December, 2014 [Page 19] Internet-Draft ACTN Problem Statement June 2014 required for the dynamic provisioning of IP networks and services, [I-D.boucadair-network-automation-requirements] aims at listing the requirements to drive the specification of an automated configuration management framework, including the requirements for a protocol to convey configuration information towards the managed entities. 4.17.2. Connectivity Provisioning Negotiation Protocol (CPNP) [I-D.boucadair-connectivity-provisioning-protocol] specifies the Connectivity Provisioning Negotiation Protocol (CPNP) which is used to facilitate the dynamic negotiation of service parameters between a Customer and a Provider. As such, CPNP is a generic protocol that can be used for various negotiation purposes that include (but are not necessarily limited to) connectivity provisioning services, storage facilities, CDN (Content Delivery Networks) footprint, etc. The generic CPP template allows for: o Automating the process of service negotiation and activation, thus accelerating service provisioning; o Setting the (traffic) objectives of Traffic Engineering functions and service management functions. o Enriching service and network management systems with 'decision-making' capabilities based on negotiated/offered CPPs. 5. References 5.1. Informative References [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, "Generalized Multiprotocol Label Switching (GMPLS) User-Network Interface (UNI): Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Support for the Lee & King Expires December, 2014 [Page 20] Internet-Draft ACTN Problem Statement June 2014 Overlay Model", RFC 4208, October 2005. [RFC4110] R. Callon and M. Suzuki, "A Framework for Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs)", RFC 4110, July 2005. [RFC4847] T. Takeda, Ed., "Framework and Requirements for Layer 1 Virtual Private Networks", RFC 4847, April 2007. [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006. [RFC4664] L. Andersson, and E. Rosen, Eds., "Framework for Layer 2 Virtual Private Networks (L2VPNs)", RFC 4664, Sep 2006. [RFC5440] JP. Vasseur, Ed. And JL. Le Roux, Ed. "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009. [I-D.boucadair-connectivity-provisioning-protocol] Boucadair, M. and C. Jacquenet, "Connectivity Provisioning Negotiation Protocol (CPNP)", draft- boucadair-connectivity-provisioning-protocol-01 (work in progress), October 2013. [I-D.boucadair-network-automation-requirements] Boucadair, M. and C. Jacquenet, "Requirements for Automated (Configuration) Management", draft- boucadair-network-automation-requirements-02 (work in progress), June 2013. 6. Acknowledgements The authors wish to thank the contributions on the IETF ACTN mailing list. Lee & King Expires December, 2014 [Page 21] Internet-Draft ACTN Problem Statement June 2014 7. IANA Considerations Not Applicable. 8. Authors' Addresses Young Lee Huawei Technologies 5340 Legacy Drive Plano, TX 75023, USA Phone: (469)277-5838 Email: leeyoung@huawei.com Daniel King Lancaster University Email: d.king@lancaster.ac.uk Mohamed Boucadair France Telecom Rennes 35000 France Email: mohamed.boucadair@orange.com Ruiquan Jing, China Telecom Corporation Limited, No. 118, Xizhimenneidajie, Xicheng District, Beijing, China Email: jingrq@ctbri.com.cn Luis Miguel Contreras Murillo Telefonica I+D Email: lmcm@tid.es Lee & King Expires December, 2014 [Page 22] Internet-Draft ACTN Problem Statement June 2014 Intellectual Property Statement The IETF Trust takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in any IETF Document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Copies of Intellectual Property disclosures made to the IETF Secretariat and any assurances of licenses to be made available, Or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on- line IPR repository at http://www.ietf.org/ipr The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement any standard or specification contained in an IETF Document. Please address the information to the IETF at ietf- ipr@ietf.org. Disclaimer of Validity All IETF Documents and the information contained therein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Lee & King Expires December, 2014 [Page 23] Internet-Draft ACTN Problem Statement June 2014 Internet Society. Lee & King Expires December, 2014 [Page 24]