Network Working Group Young Lee Internet Draft Huawei Intended status: Informational Daniel King Expires: December 10, 2015 Lancaster University M. Boucadair France Telecom R. Jing China Telecom L. Contreras Murillo Telefonica June 9, 2015 Problem Statement for Abstraction and Control of Transport Networks draft-leeking-teas-actn-problem-statement-00.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 10, 2015. Copyright Notice Copyright (c) 2015 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 Lee & King Expires December 10, 2015 [Page 1] Internet-Draft ACTN PS June 2015 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 Transport networks that provide connectivity and bandwidth for customer services have typically been static, lacking flexibility, and requiring 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 to meet operators' requirements for virtual network operation. Virtual network operation refers to the creation of a virtualized environment allowing operators to view the abstraction of the underlying multi-administration, multi- vendor, multi-technology networks and to operate, control, and manage these multiple networks as if a single virtualized network. Another dimension of virtual network operation is the use of common core transport network resources 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, a scope of work, and outlines the core objectives and requirements to facilitate virtual network operation. Table of Contents 1. Introduction..................................................4 1.1. Terminology..............................................5 2. Objectives and Functional Requirements........................7 2.1. Use Cases................................................7 2.1.1 Packet Transport Networks (PTN) in Mobile Backhaul Networks................................................7 2.1.2 Packet Optical Integration (POI)....................7 2.1.3 Multi-domain Data Center Interconnect...............7 2.1.4 On-demand E2E Connectivity Services in Multiple Vendor Domain Transport Networks...............................8 2.1.5 Multi Tenant Virtual Network Operators..............9 Lee & King Expires December 10, 2015 [Page 2] Internet-Draft ACTN PS June 2015 2.1.6 Virtual Network Operation for Multiple Domains in a Single Operator Network.................................10 2.1.7 Mobile Virtual Network Operation for Multiple Domains in a Single Operator Network............................10 2.1.8 Dynamic Service Control based on Performance Monitoring..............................................11 3. Relationship with Existing Technologies & Other Industry Initiatives.............................................11 3.1. Virtual Private Networks.................................11 3.2. Overlay Networks.........................................12 3.3. Other Industry Initiatives...............................12 4. Motivations for Additional Functionality......................13 4.1. Business Objectives......................................13 4.2. Network Resource Recursiveness...........................14 4.3. Customer-Initiated Programmability.......................14 4.4. Resource Partitioning....................................14 4.5. Service Orchestration....................................14 5. ACTN Objectives and Requirements..............................15 5.1. Capability and Resource Visibility.......................15 5.2. Network Programmability..................................16 5.3. Common Data Models.......................................16 5.4. Scheduling...............................................17 5.5. Slicing..................................................17 5.6. Adaptability.............................................17 5.7. Allocation...............................................17 5.8. Isolation................................................18 5.9. Manageability............................................18 5.10. Resilience..............................................19 5.11. Security................................................19 5.12. Policy..................................................20 5.13. Technology Independence.................................20 5.14. Optimization............................................20 5.15. Multi-domain Support....................................20 5.16. Architecture Principles.................................20 5.16.1. Network Partitioning...............................21 5.16.2. Orchestration......................................21 5.16.3. Recursion..........................................21 5.16.4. Legacy Support and Interoperability................21 5.17. Other Related Work......................................21 5.17.1. Requirements for Automated (Configuration) Management ...........................................................21 5.17.2. Connectivity Provisioning Negotiation Protocol (CPNP) ...........................................................21 6. References....................................................22 6.1. Informative References...................................22 7. Acknowledgements..............................................24 8. IANA Considerations...........................................24 9. Authors' Addresses............................................24 Lee & King Expires December 10, 2015 [Page 3] Internet-Draft ACTN PS June 2015 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 existing network technologies and architectures limits network efficiency, scalability, and elasticity (i.e., they do not offer sufficient capability to adapt 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, facilitates 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. Transport networks that provide connectivity and bandwidth for customer services have typically been static, lacking flexibility, and requiring 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 to meet operators' requirements for virtual network operation. Virtual network operation refers to the creation of a virtualized environment allowing operators to view the abstraction of the underlying multi-administration, 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 the use of common core transport network resources by multi-tenant service networks as a way of providing a virtualized infrastructure to flexibly offer new services and applications. Abstraction and Control of Transport Networks (ACTN) defines new methods and capabilities for the deployment and operation of Lee & King Expires December 10, 2015 [Page 4] Internet-Draft ACTN PS June 2015 transport network resource. These are summarized as follows. 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-administration, multi-vendor, and 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, themselves, be service providers. This document first presents the summary of ACTN use-cases, then provides an ACTN problem description and scope of work, and outlines the core objectives and 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 view of the network resource (known as "a slice") to support their users and applications. In some cases, customers may have to support multiple virtual network services with different service objectives and QoS requirements to enable multiple types of users and applications. Customers may also be considered to be trusted parties with respect to the provider wholesale service department. A trust model will be required and is discussed further later in this document. 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 one or more Network Provider to create virtual network Lee & King Expires December 10, 2015 [Page 5] Internet-Draft ACTN PS June 2015 services or offer end-to-end services to their customers. A Service Provider may be a Network Provider such that some or all of the resources used are owned by the Service Provider. A Virtual Network Service Provider is a special type of Service Provider in that they might own no physical equipment or infrastructure, or might have only limited physical infrastructure and require virtual resources to be supplied to them by another Service Provider to offer the final service. A Virtual Network Service Provider only provide services built upon a virtual network infrastructure. The rest of 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 certain network resources as if they owned them, and thus allows the customers to control their allocated resources in a way most optimal for 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: 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 resources providing connectivity bandwidth and traffic engineering for client layer services, such that resource guarantees may be provided to customers. Transport networks discussed in this document different types of connection-oriented networks including both 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: Layer 1 (L1) and Layer 0 (L0) optical networks (e.g., OTN, ODU, OCh/WSON), MPLS-TP, MPLS-TE, as well as other emerging network technologies with connection-oriented behavior. Lee & King Expires December 10, 2015 [Page 6] Internet-Draft ACTN PS June 2015 2. Objectives and Functional Requirements 2.1 Use Cases A group of Service Providers and Network Providers have identified a number of key use cases that identify key application scenarios for how ACTN may be used. 2.1.1 Packet Transport Networks (PTN) in Mobile Backhaul Networks The Packet Transport Networks (PTN) Network Provider may use ACTN to improve efficiency of provision and operation, optimize the resources utilization, and promote the customer's experiences. The Internet-Draft [CHENG] discusses the key requirements for ACTN in a PTN environment, these include: o Faster End-to-End Enterprise services Provisioning o Multi-layer coordination in L2/L3 Packet Transport Networks o Optimizing the network resources utilization (supporting various performances monitoring matrix, such as traffic flow statistics, packet delay, delay variation, throughput and packet-loss rate) o Virtual Networks Operations for Multi-domain Packet Transport Networks 2.1.2 Packet Optical Integration (POI) Increasingly there is a need for packet and optical transport networks to work together to provide accelerated services. Transport networks can provide useful information to the packet network allowing it to make intelligent decisions and control its allocated resources. The Internet-Draft [DHODY] outlines the Packet Optical Integration (POI) use case for ACTN, The Internet-Draft [DHODY] discusses the key requirements for ACTN for the Packet Optical Integration (POI) environment, requirements include: o Packet Optical Integration to support Traffic Planning, performance Monitoring, automated congestion management and Automatic Network Adjustments. o Protection and Restoration Synergy in Packet Optical Multi- layer network. Lee & King Expires December 10, 2015 [Page 7] Internet-Draft ACTN PS June 2015 o Service Awareness and Coordination between Multiple Network Domains. 2.1.3 Multi-domain Data Center Interconnect Data center operators need to interface multi-domain transport networks to offer their global data center applications and services. As data center providers face multi-domain and diverse transport technology, interoperability based on standard-based abstraction is required for dynamic and flexible applications and services. The Internet-Draft [FANG] discusses the key requirements for ACTN for the data center interconnect environment, requirements include: o Multi-domain Data Center Interconnection to support VM Migration, Global Load Balancing, Disaster Recovery, On- demand Virtual Connection/Circuit Services. o The interfaces between the Data Center Operation and each transport network domain should support standards-based abstraction with a common information/data model to support the following: - Network Query (Pull Model) from the Data Center Operation to each transport network domain to collect potential resource availability (e.g., BW availability, latency range, etc.) between a few data center locations. - Network Path Computation Request from the Data Center Operation to each transport network domain to estimate the path availability. - Network Virtual Connections/Circuits Request from the Data Center Operation to each transport domain to establish end-to-end virtual connections/circuits (with type, concurrency, duration, SLA.QoS parameters, protection.reroute policy options, policy constraints such as peering preference, etc.). - Network Virtual Connections/Circuits Modification Request. 2.1.4 On-demand E2E Connectivity Services in Multiple Vendor Domain Transport Networks There is a need for creation and operation of a virtualized environment supporting the viewing and controlling different vendor domains, including on-demand network connectivity Lee & King Expires December 10, 2015 [Page 8] Internet-Draft ACTN PS June 2015 service across a single operator environment. This will accelerate rapid service deployment of new services, including more dynamic and elastic services, and improve overall network operations and scaling of existing services. The Internet-Draft [KLEE] highlights on-demand edge-to-edge (E2E) connectivity service requirements in multiple vendor domain transport networks, which include: o Two-stage path computation capability in a hierarchical control architecture (MDSC-PNC) and a hierarchical composition of integrated network views. o Coordination of signal flow for E2E connections. o Abstraction of: - Inter-connection data between domains - Customer Endpoint data - The multiple levels/granularities of the abstraction of network resource (which is subject to policy and service need). - Any physical network constraints (such as SRLG, link distance, etc.) should be reflected in abstraction. - Domain preference and local policy (such as preferred peering point(s), preferred route, etc.), Domain network capability (e.g., support of push/pull model). 2.1.5 Multi-Tenant Virtual Network Operators Creation and operation of multi-tenant virtual networks that use the common core network resources is important to facilitate rapid deployment of new services, including more dynamic and elastic services, and improve overall network operations and scaling of existing services. The Internet-Draft [KUMAKI] discusses multi-tenant virtual networks that use the common core network resources, requirements include: o On-demand Virtual Network Service Creation o Domain Control Plane/Routing Layer Separation o Independent service Operation for Virtual Services from control of other domains o Multiple service level support for each VN (e.g., bandwidth and latency for each VN service). Lee & King Expires December 10, 2015 [Page 9] Internet-Draft ACTN PS June 2015 o VN diversity/survivability should be met in physical network mapping. o VN confidentiality and sharing constraint should be supported. 2.1.6 Virtual Network Operation for Multiple Domains in a Single Operator Network Virtual network operation for multiple domains in a single operator network is required. This would facilitate the application of virtual network abstractions to network operations. These abstractions will create a virtualized environment supporting the viewing and controlling different domains as a single virtualized network. This use case is discussed in more detail in [LOPEZ], requirements include: o Creation of a global abstraction of network topology: The VNO Coordinator assembles each domain level abstraction of network topology into a global abstraction of the end-to-end network. o End-to-end connection lifecycle management. o Invocation of path provisioning request to each domain (including optimization requests). o Invocation of path protection/reroute to the affected domain(s). o End-to-end network monitoring and fault management. This could imply potential KPIs and alarm correlation capabilities. o End-to-end accounting and generation of detailed records for resource usage. o End-to-end policy enforcement 2.1.7 Mobile Virtual Network Operation for Multiple Domains in a Single Operator Network The use-case for mobile virtual networks with single operator Networks is discuss edin [SHIN]. o Resource abstraction: operational mechanisms in mobile backhaul network to give the current network usage information for dynamic and elastic applications be provisioned dynamically with QoS guarantee. Lee & King Expires December 10, 2015 [Page 10] Internet-Draft ACTN PS June 2015 o Load balancing or for recovery, the selection of core DC location from edge constitutes a data center selection problem. o Multi-layer routing and optimization, coordination between these two layers. 2.1.8 Dynamic Service Control based on Performance Monitoring Transport networks support various performance monitoring mechanisms, such as traffic flow statistics, packet delay, delay variation, throughput and packet-loss rate for MPLS-TP and packet OTN networks, BER, FEC error correction counters for OTN and DWDM networks, etc. These mechanisms may be used to support dynamic service control of network resources based on the aforementioned performance monitoring. This use case is discussed in [XU], requirements include: o Dynamic Service Control Policy enforcement and Traffic/SLA Monitoring: - Customer service performance monitoring strategy, including the traffic monitoring object (the service need to be monitored) - monitoring parameters (e.g., transmitted and received bytes per unit time), - traffic monitoring cycle (e.g., 15 minutes, 24 hours), - threshold of traffic monitoring (e.g., high and low threshold), etc. 3. Relationship with Existing Technologies & Other Industry Initiatives 3.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; Lee & King Expires December 10, 2015 [Page 11] Internet-Draft ACTN PS June 2015 o Quality of Service (QoS) capabilities; 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. [RFC4847] describes virtual networks in terms of ITU-T [Y.1312] and [Y.1313]. Those Recommendations address both the data plane and control plane aspects of VPNs. Concepts of private and shared VPNs are described. 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. 3.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. 3.3. Other Industry Initiatives Lee & King Expires December 10, 2015 [Page 12] Internet-Draft ACTN PS June 2015 ONF Architecture [ONF-SDN-ARCH] describes various arrangements of SDN controllers. TM Forum's [TR215] and [TR225] addresses a common information model that can be applied to transport network in particular. ITU-T [Y.1312] and [Y.1313] are a good reference to review for Layer 1 VPN in terms of terminology and architecture. 4. Motivations for Additional Functionality 4.1. Business Objectives The 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 end-to-end services and content (i.e., web and email) to its customers. Other 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 Provider (ISP) which provides 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 10, 2015 [Page 13] Internet-Draft ACTN PS June 2015 o Offer new, much more flexible services to their customers; o Maximize network resource usage and efficiency. All aforementioned objectives have the capability to significantly 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. 4.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. 4.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. 4.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 Service Providers and users. 4.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 Lee & King Expires December 10, 2015 [Page 14] Internet-Draft ACTN PS June 2015 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. 5. ACTN Objectives The overall goal of enabling network abstraction and multiple concurrent virtual networks to coexist on a shared physical infrastructure comprised of multiple physical layers 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 transport metrics and constraints. Moreover, the model of the physical layer resources may need dynamic collection of the status and availability of the underlying transport network infrastructure. 5.1. Capability and Resource Visibility It may be necessary for the application or Customer to obtain Information about available capabilities and available network resources, for example, a view and control of abstracted resource. 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 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). Lee & King Expires December 10, 2015 [Page 15] Internet-Draft ACTN PS June 2015 o Information about the provider (i.e., informative data about the resource owner) o Geographical information about the resources to be consumed (i.e., geolocation of the resources for preventing legal concerns that could appear in the provision of some 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, recovery time, etc.). 5.2. Network Programmability 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. A programmable interface should provide customers with the capabilities to dynamically create, deploy, and operate services in response to customer and application demands. 5.3. Common Data Models The data model that describes the abstraction of the underlying transport network should be agnostic to each technology type within the ACTN framework. The model will provide a uniform structure which is extensible to support any future technologies. The model 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. The data model can be decomposed into the following elements. o Attributes o Metrics o Control Actions Lee & King Expires December 10, 2015 [Page 16] Internet-Draft ACTN PS June 2015 o Semantics o Administrative information (resource ownership) 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), Service Level Agreements (SLA) customization (e.g., the particularization of the collected metrics according to the customer interests), etc. 5.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 would be capable of employing appropriate scheduling algorithms in a centralized entity, or alternatively distributed across all of the network elements. 5.5. Slicing It should be possible for transport network infrastructure to be partitioned into multiple independent virtual networks through a process known as "slicing". This partitioning is based on provider service types, customers and application requirements. 5.6. Adaptability Adaptability of services would allow the Service Provider, user, and application to request modification of existing virtual network resources that have been assigned. This may include resizing of bandwidth, modification of the underlying topology, and adding/removing connectivity points to modify the virtual network topology itself. 5.7. Allocation Lee & King Expires December 10, 2015 [Page 17] Internet-Draft ACTN PS June 2015 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 times on a virtual node, and fixed loss and delay characteristics on the virtual links. This should be governed by SLAs and can have implications in the supportive transport technologies, and in the properties of the 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 the necesssary scheduling capability. 5.8. Isolation Isolation, both of physical underlay infrastructure and of co- existing virtual networks, is required for management and confidentiality reasons. Additionally there must be no leakage of traffic between different customers. Furthermore, there must be mechanisms that ensure that once network slices are assigned, Customer and Application services do not compete for the transport resources that support their virtual networks. Within their virtual networks, 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 of other coexisting virtual networks. It must also be possible for many virtual networks to share the underlying infrastructure (multi-tenant), without impacting the performance of applications utilizing the virtual networks. 5.9. Manageability A broad range of capabilities will need to be provided through a set of well-defined interfaces. These capabilities apply to the management of end-to-end services and include the ability to request, control, provisioning, monitoring, resilience, adapt,and re-optimize those services. Specifically it should be possible to provide the following funcitons. o Control of virtual network resources. This control must be capable of delivering end-to-end services with optimization of connectivity and virtual infrastructure. Such optimization is based on client interface and application demands, technology constraints (bandwidth, latency, jitter, function, etc.), and commercial constraints (energy, customer Lee & King Expires December 10, 2015 [Page 18] Internet-Draft ACTN PS June 2015 SLA, etc.). o Automation of virtual service and function requests and objectives, and providing on-demand and self-service network slicing subject to policy constraints set by the operators of the underlying physical networks, and under the control of commercial agreements between all parties. o Infrastructure elasticity to allow rapid provisioning, automatic scaling out, or in, of virtual resources. o Virtual resource monitoring o Control of bandwidth, energy consumption and quality of service/packet scheduling. 5.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 provider. The former case refers to the situation in which the customer requests specific resilience requirements on the offered transport service. For instance, the customer can request transport protection through the provision of disjoint paths 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. 5.11. Security Network programmability may introduce new security and misconfiguration vulnerabilities. These must be investigated and discussed, and then solved. ACTN-based networks must be resilient to existing, and new, faults and attacks. Lee & King Expires December 10, 2015 [Page 19] Internet-Draft ACTN PS June 2015 Failure or security breach in one ACTN slice should not impact another virtual network. It must also be possible to separate 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 are as follows. 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, authorization, logging, etc. 5.12. Policy To be discussed. 5.13. Technology Independence ACTN must support a variety of underlay transport technologies, providing the flexibility to manage a variety of heterogeneous network technologies. 5.14. Optimization The service provider must be able 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, re-utilization of vacant resources, etc.). 5.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 entities. 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 to give the customer the possibility of composing multi-provider transport services. 5.16. Architectural Principles Lee & King Expires December 10, 2015 [Page 20] Internet-Draft ACTN PS June 2015 5.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, spanning part or all of the underlying physical networks. 5.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. 5.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 is known as "recursion" or "nesting" of network slices. 5.16.4. Legacy Support and Interoperability The ability 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. 5.17. Other Related Work 5.17.1. Requirements for Automated (Configuration) Management Given the ever-increasing complexity of the configuration tasks 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. 5.17.2. Connectivity Provisioning Negotiation Protocol (CPNP) [I-D.boucadair-connectivity-provisioning-protocol] specifies the Connectivity Provisioning Negotiation Protocol (CPNP) which could be 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) Lee & King Expires December 10, 2015 [Page 21] Internet-Draft ACTN PS June 2015 connectivity provisioning services, storage facilities, CDN (Content Delivery Networks) footprint, etc. The generic Connectivity Provisioning Profile (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. 6. References 6.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 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] Lee & King Expires December 10, 2015 [Page 22] Internet-Draft ACTN PS June 2015 Boucadair, M. and C. Jacquenet, "Connectivity Provisioning Negotiation Protocol (CPNP)", draft- boucadair-connectivity-provisioning-protocol-09 (work in progress), March 2015. [I-D.boucadair-network-automation-requirements] Boucadair, M. and C. Jacquenet, "Requirements for Automated (Configuration) Management", draft- boucadair-network-automation-requirements-05 (work in progress), February 2015. [CHENG] W. Cheng, et. al., "ACTN Use-cases for Packet Transport Networks in Mobile Backhaul Networks", draft-cheng-actn- ptn-requirements, work in progress. [DHODY] D. Dhody, et. al., "Packet Optical Integration (POI) Use Cases for Abstraction and Control of Transport Networks (ACTN)", draft-dhody-actn-poi-use-case, work in progress. [FANG] L. Fang, "ACTN Use Case for Multi-domain Data Center Interconnect", draft-fang-actn-multidomain-dci, work in progress. [KLEE] K. Lee, H. Lee, R. Vilata, V. Lopez, "ACTN Use-case for On-demand E2E Connectivity Services in Multiple Vendor Domain Transport Networks", draft-klee-actn-connectivity- multi-vendor-domains, work in progress. [KUMAKI] K. Kumaki, T. Miyasaka, "ACTN : Use case for Multi Tenant VNO ", draft-kumaki-actn-multitenant-vno, work in progress. [LOPEZ] D. Lopez (Ed), "ACTN Use-case for Virtual Network Operation for Multiple Domains in a Single Operator Network", draft-lopez-actn-vno-multidomains, work in progress. [SHIN] J. Shin, R. Hwang, J. Lee, "ACTN Use-case for Mobile Virtual Network Operation for Multiple Domains in a Single Operator Network", draft-shin-actn-mvno-multi-domain, work in progress. [XU] Y. Xu, et. al., "Use Cases and Requirements of Dynamic Service Control based on Performance Monitoring in ACTN Architecture", draft-xu-actn-perf-dynamic-service-control, work in progress. [Y.1312] Y.1312 - Layer 1 Virtual Private Network Generic requirements and architecture elements, ITU-T Lee & King Expires December 10, 2015 [Page 23] Internet-Draft ACTN PS June 2015 Recommendation, September 2003, available from . [Y.1313] Y.1313 - Layer 1 Virtual Private Network service and network architectures, ITU-T Recommendation, July 2004, available from . [TR215] TM Forum TR251, Logical Resource Network Model Advancements and Insights, August 2014, . [TR225] TM Forum TR225, Logical Resource: Network Function Model, June 2015, . [ONF-SDN-ARCH] Software Defined Network Architcture, ONF TR-502, June 2014, . 7. Acknowledgements The authors wish to thank the contributions on the IETF ACTN mailing list. 8. IANA Considerations This problem statement document makes no requests for IANA action. 9. 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 Lee & King Expires December 10, 2015 [Page 24] Internet-Draft ACTN PS June 2015 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 10, 2015 [Page 25] Internet-Draft ACTN PS June 2015