Network Working Group Young Lee Internet Draft Huawei Daniel King Intended status: Informational Lancaster University Expires: August 5,2014 February 5, 2014 Problem Statement for Abstraction and Control of Transport Networks draft-leeking-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 on August 5, 2014. Copyright Notice 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 Lee and King Expires August 5, 2014 [Page 1] Internet-Draft ACTN Problem Statement February 2014 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 customer demands and evolving Internet applications By combining the aforementioned capabilities with network resource virtualization and abstraction mechanisms, available via well- defined customer interfaces, providing significant operational benefits to meet the growing demands from customers 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 network resource virtualization and resource slicing for customers and applications, across Service Provider and Network Provider transport network infrastructure. Table of Contents 1. Introduction...................................................3 1.1. Terminology...............................................4 2. Relationship with Existing Technologies........................6 2.1. Virtual Private Networks..................................6 2.2. Overlay Networks..........................................7 3. Motivations for Additional Functionality.......................7 3.1. Business Objectives.......................................7 3.2. Network Resource Recursiveness............................8 3.3. Customer-Initiated Programmability........................8 Lee & King Expires August 5, 2014 [Page 2] Internet-Draft ACTN Problem Statement February 2014 3.4. Resource Partitioning.....................................8 3.5. Service Orchestration.....................................9 4. ACTN Objectives and Requirements...............................9 4.1. Capability and Resource Discovery.........................9 4.2. Network Programmability..................................10 4.3. Common Data Models.......................................10 4.4. Scheduling and Allocation................................11 4.5. Adaptability.............................................11 4.6. Slicing..................................................11 4.7. Isolation................................................11 4.8. Manageability............................................12 4.9. Resilience...............................................12 4.10. Security................................................13 4.11. Policy..................................................13 4.12. Technology Independence.................................13 4.13. Architecture Principles.................................13 4.13.1. Network Partitioning...............................13 4.13.2. Orchestration......................................13 4.13.3. Recursion..........................................13 4.13.4. Legacy Support.....................................14 5. References....................................................14 5.1. Informative References...................................14 6. Contributors........................Error! Bookmark not defined. Authors' Addresses...............................................15 Intellectual Property Statement..................................15 Disclaimer of Validity...........................................15 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 Providers 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 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 Lee & King Expires August 5, 2014 [Page 3] Internet-Draft ACTN Problem Statement February 2014 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 and services. Further development is required to allow customers to create, modify, and delete virtual network services dynamically. 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 Abstraction of underlying network resources to higher-layer applications and customers; o Slicing of network resources to meet specific application and customer requirements; o Provision of a computation scheme and virtual control capability, via an data model, to customers who request virtual network services; o Coordination of underlying transport layers and presentation as an abstracted topology to the customer. This document provides an ACTN problem description and scope of work, and outlines the core requirements to facilitate network resource virtualization and resource slicing for Network Providers, Service Providers, Customers, and applications. 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 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. Lee & King Expires August 5, 2014 [Page 4] Internet-Draft ACTN Problem Statement February 2014 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 own no physical equipment or infrastructure, 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 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. Lee & King Expires August 5, 2014 [Page 5] Internet-Draft ACTN Problem Statement February 2014 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; 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. Lee & King Expires August 5, 2014 [Page 6] Internet-Draft ACTN Problem Statement February 2014 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. 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 uses; 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: Lee & King Expires August 5, 2014 [Page 7] Internet-Draft ACTN Problem Statement February 2014 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; 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 Service Providers and users. Lee & King Expires August 5, 2014 [Page 8] Internet-Draft ACTN Problem Statement February 2014 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 transport appropriate 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 Discovery It may be necessary for the application or Customer to discover available capabilities and available network resources, for example, abstracted resource view and control. 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 August 5, 2014 [Page 9] Internet-Draft ACTN Problem Statement February 2014 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 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 distributed computing objects 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: o Attributes o Metrics o Control Actions o Semantics 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. Lee & King Expires August 5, 2014 [Page 10] Internet-Draft ACTN Problem Statement February 2014 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. 4.4. Scheduling and Allocation When requesting network slices it should be possible to request an immediate or scheduled service. 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. To provide such guarantees and to create an illusion of an isolated and dedicated network slice to each customer, Network Providers must employ appropriate scheduling algorithms in all of the network elements. 4.5. 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.6. 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.7. 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 independent transport resources. Lee & King Expires August 5, 2014 [Page 11] Internet-Draft ACTN Problem Statement February 2014 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 performance of applications utilizing the virtual networks. 4.8. Manageability A broad range of capabilities, including: request, control, provisioning, monitoring, resilience, adaptation and re-optimisation 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-en 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.9. Resilience [To be discussed.] Lee & King Expires August 5, 2014 [Page 12] Internet-Draft ACTN Problem Statement February 2014 4.10. 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. 4.11. Policy [To be discussed.] 4.12. Technology Independence ACTN must support a variety of underlay transport technologies, providing the flexibility to manage a variety of heterogeneous network technologies. 4.13. Architecture Principles 4.13.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.13.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.13.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. Lee & King Expires August 5, 2014 [Page 13] Internet-Draft ACTN Problem Statement February 2014 4.13.4. Legacy Support Capability to deploy ACTN should be transparent to existing physical network control and management mechanisms and protocols. 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 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. [RFC4664] L. Andersson, and E. Rosen, Eds., "Framework for Layer 2 Virtual Private Networks (L2VPNs)", RFC 4664, Sep 2006. [RFC4665] W. Augustyn, Ed. and Y. Serbest, Ed., "Service Requirements for Layer 2 Provider-Provisioned Virtual Private Networks", RFC 4665, September 2006. [RFC5440] JP. Vasseur, Ed. And JL. Le Roux, Ed. "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009. 6. Acknowledgements The authors wish to thank the contributions on the IETF ACTN mailing list. Lee & King Expires August 5, 2014 [Page 14] Internet-Draft ACTN Problem Statement February 2014 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 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 Lee & King Expires August 5, 2014 [Page 15] Internet-Draft ACTN Problem Statement February 2014 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 Internet Society. Lee & King Expires August 5, 2014 [Page 16]