Network Working Group G. Karagiannis Internet-Draft Huawei Technologies Intended status: Informational Q. Sun Expires: September 9, 2015 China Telecom Luis M. Contreras Telefonica P. Yegani Juniper Networks JF Tremblay Viagenie J.Bi Tsinghua University March 9, 2015 Problem Statement for Simplified Use of Policy Abstractions (SUPA) draft-karagiannis-supa-problem-statement-06 Abstract The increase in complexity of modern networks makes it challenging to deploy new services and to keep networks up to date whilst maintaining stability and availability for critical business services. This is a major challenge that network operators (service providers, SME, etc) face today. The operators aim of streamlining both operations and the deployment of new services, is being met by increasingly relying on programmatic control of network elements and by the use of various virtualization technologies. In this context, providing network operators with a set of standard generic YANG-based service and policy models that enable management and automation of services on their network is essential. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." Karagiannis, et al. Expires September 9, 2015 [Page 1] Internet-Draft SUPA Problem Statement March 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 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . .2 1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . .3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1 Inter Data Centers (IDC) . . . . . . . . . . . . . . . . . . 4 3.2 DTS (DC Traffic Schedule) . . . . . . . . . . . . . . . . . 4 3.3 Flexible VPN Set-Up in Campus Environments . . . . . . . . . 5 3.4 VPNs connecting VPCs (Virtual Private Clouds) and data centers . . . . . . . . . . . . . . . . . . . . . . . . 5 3.5 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Requirements/Challenges . . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 8.1 Normative References . . . . . . . . . . . . . . . . . . 7 8.2 Informative References . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction Network operators are faced with networks of increasing size and complexity while trying to improve their quality and availability, as more and more business services depend on them. Programmatic ways to configure networks, often called software-defined, are considered by many network operators an essential tool toward the management of that complexity. Providing means of exposing a view of the network to applications provides significant improvements in configuration agility, error detection and uptime for operators. Karagiannis, et al. Expires September 9, 2015 [Page 2] Internet-Draft SUPA Problem Statement March 2015 This document describes the problems that need to be addressed in order to equip service providers with the means, such as generic network service models and generic policy rule models, to quickly and dynamically manage their offering of network services. 1.1 Motivation The rapid increase in the complexity of managing virtual paths makes it significantly more challenging to operate and improve networks. In particular, the expansion and management of virtual connections, and the virtualization of networks and services using data centers are creating much more complex and dynamic networks. This is a significant challenge that network operators (service providers, SME, etc) face today. Three main mechanisms can be used to deal with this growing complexity: o) the use of software abstractions. This mechanism enables the construction of the simplified views of networks, which hides complexity from applications while allowing them to configure common functions within a domain. o) the increase in programmatic control over the configuration and operation of networks. This mechanism uses the software abstractions and control points to more quickly define and manage network services. o) apply generic policy models that enable network operators to craft their own policy rules. Combining these mechanisms provides additional and significant benefits in design and deployment agility. These main challenges can be addressed by developing a policy driven service management methodology that incorporates generic models, by which network services can be managed using standardized and generic policy rule models. 2. Terminology Network Service: the composition of network functions as defined by its functional and behavioral specification. A network service is characterized by performance, dependability, and security specifications. Furthermore, a network service is delivered by network service endpoints, which may be aggregations of multiple lower-layer technology specific endpoints. Network Element: a physical or virtual entity that implements one or more network function(s). NEs can interact with local or remote network controllers in order to exchange information, such as configuration information and status. Karagiannis, et al. Expires September 9, 2015 [Page 3] Internet-Draft SUPA Problem Statement March 2015 Service specific abstraction: an abstract view of the service topology, associated with a specific network service type, e.g., inter-datacenter communication services 3. Use Cases This section briefly describes the use cases that are associated with different types of network services. A more detailed description of these use cases is provided in [ID.draft-cheng-supa-ddc-use-cases]. 3.1 Inter Data Centers (IDC) A large-scale IDC (Inter Data Center) operator provides server hosting, bandwidth, and value-added services to enterprises and ISPs, and has more than 10 data centers and more than 1Tbs bandwidth in a capital city. In current IDC networks, traffic is routed by applying routing policies and adjusting route prioritization to prefer specific links. Link bandwidth in the data centers are often overprovisioned and therefore not efficiently utilized. Services usually have variable bandwidth requirements depending of the time of day, e.g. video ISP usually require more bandwidth at non-working hours but require less bandwidth at working hours. Some customers have high QoS requirement for their services, e.g. IM (Instant Messaging). Such scenarios are worth modeling because static bandwidth allocations and manual QoS provisioning for all services is not a cost-effective solution on the long term. Network operators will benefit from using the policy driven service management methodology that can be applied to design flexible adjustment policies for bandwidth allocations and dynamic QoS provisioning. 3.2 DTS (Datacenter Traffic Schedule) China Telecom is part of a group of operators testing and implementing a new management schema called Datacenter Traffic Schedule (DTS). Due to the rapid development of Internet services, each single datacenter location cannot meet all the requirements of a given service. A general model has been developed to host service instances in multiple collaborating datacenters. More specifically, client systems can request resources from a single virtual datacenter, making the service more flexible and scalable. This also provides for more reliability and security of services. As a result, inter datacenter traffic has increased dramatically during the last years. Service instances located in different datacenters will exchange large volume of data for backup and storage, which may occur at a fixed or variant times each day. In such an environment, a management system is able to monitor traffic volume on the links between datacenters and react accordingly to prevent synchronization and resource exhaustion. When the volume exceeds the threshold set by the system, it requests traffic schedules may be adjusted within bounds in a dynamic policy driven framework in order traffic to move overflowing traffic on other links. Such scenarios are well worth Karagiannis, et al. Expires September 9, 2015 [Page 4] Internet-Draft SUPA Problem Statement March 2015 modeling as operators need to design flexible adjustment of scheduling policies for optimizing the throughput of datacenter edge routers. 3.3 Flexible VPN Set-Up in Campus Environments There are requirements from campus network operators to flexibly manage traffic for multiple functions in a building, such as traffic for network operation, traffic for building monitoring network, traffic for professor working on test-bed/data for different research projects. Traditionally, the operation staffs manually set up VLANs for different users. However, the increasing number of projects/users makes it very hard to manually set up those different network/test-beds in the shared building LAN, because sometimes one office can have multiple access rights to access different networks/projects. Therefore, SUPA could potentially support the flexible VPN set up on the shared infrastructure (based on IP/MAC address, VLAN ID, etc.). In this case, a controller and standardized northbound APIs could serve for an operator's application to flexibly set up the access to different resources. In general, by providing a policy driven service management methodology, network operators will be able to define the network services for the different academic and administrative functions along with policy rules that govern the service instantiation, e.g., the dynamic creation and maintenance of VPNs. 3.4 VPNs connecting VPCs (Virtual Private Clouds) and data centers Currently, Virtual Private Clouds (VPCs) are used to provide capacity for various internal applications. The VPCs need to securely exchange data with the local data center, which is not exposed to the general Internet. Inter-site IPsec VPNs have been the mechanism of choice to secure these connections in the past. However the complexity of managing the VPNs increases exponentially as the number of VPCs and the data centers becomes larger. By providing a policy driven service management methodology enables network operators to model, monitor and manage such VPNs. 3.5 Conclusion SUPA aims at addressing the requirements imposed by these use cases. SUPA provides a policy driven service management methodology, by which network services can be managed using standardized and generic policy rule models. In particular, SUPA enables policies controlling network services, that can dynamically request the optimization of the traffic paths dynamically and have the ability to request load balancing between data centers and links, and direct customer traffic via standard, generic network management policies. Path optimization can be accomplished using data models or software programs routines to Karagiannis, et al. Expires September 9, 2015 [Page 5] Internet-Draft SUPA Problem Statement March 2015 differentiate customer based on their service class and/or QoS requirements. Moreover, when VPN tunnels are interconnecting datacenters, the policy driven service management methodology can be used to dynamically reconfigure these VPNs in order to avoid possible congested communication paths and improve end to end latency. 4. Requirements and Challenges In order to satisfy the requirements imposed by the use cases described in Section 3, a policy driven service management methodology needs to be developed to address the following main challenges: 1) in order to correctly execute, deploy and perform the network service in the physical and/or virtual topology, generic network service models that define the resources needed by the network service for correct operation are required. 2) the management of a network service and the dynamical mapping of the network service to the network topology and network resources requires the specification and implementation of generic policy rule models. Several working groups in IETF such as I2RS, BESS, TEAS, PCE focus on data models that describe the network element centric view. Furthermore, some published Individual Internet drafts associated with some of these IETF WGs focus on data models of physical and virtual network topology. However, none of these IETF WGs focus on a policy driven service management methodology that is able to provide: o) generic network service YANG based data models, [RFC6020], [RFC6991], that define the resources needed by the network service for correct operation, o) generic policy rule models that define how to manage the network service and its required resources and that dynamically map services to the network topology and resources. SUPA can address the above listed requirements/challenges by developing a policy driven service management, by which network services can be managed using standardized and generic policy rule models. In particular, a network service is defined by a network service topology. The network service topology data model can be seen as an extension of a generic YANG topology model supporting multiple topology layers and endpoint mapping functionality. The network service topology is then mapped to the underlying network topology. Using the policy driven service management methodology, a set of generic policy rule models is defined to manage the network service. In this approach, service specific policy models will be derived from a generic policy model, ensuring that policies have a common structure and can be easily interpreted and reused as managed Karagiannis, et al. Expires September 9, 2015 [Page 6] Internet-Draft SUPA Problem Statement March 2015 objects. 5. Security Considerations Security is a key aspect of any protocol that allows state installation and extracting detailed configuration states of network elements. This places additional security requirements on SUPA (e.g., authorization, and authentication of network services) that needs further investigation. Moreover, policy interpretation can lead to corner cases and side effects that should be carefully examined, e.g., in case policy rules are conflicting with each other. 6. IANA Considerations This document has no actions for IANA. 7. Acknowledgements The authors of this draft would like to thank the following persons for the provided valuable feedback and contributions: Diego Lopez, Spencer Dawkins, Jun Bi, Xing Li, Chongfeng Xie, Benoit Claise, Ian Farrer, Marc Blancet, Zhen Cao, Hosnieh Rafiee, Mehmet Ersue, Simon Perreault, Fernando Gont, Jose Saldana, Tom Taylor, Kostas Pentikousis, Juergen Schoenwaelder, John Strassner, Eric Voit, Scott O. Bradner, Marco Liebsch, Scott Cadzow, Marie-Jose Montpetit. Tina Tsou and Will Liu contributed to an early version of this draft. 8. References 8.1. Normative References 8.2. Informative References [ID.draft-cheng-supa-ddc-use-cases] Y. Cheng, JF. Tremblay, J. Bi, "Use Cases for Distributed Data Center Applications in SUPA", IETF Internet draft (Work in progress), draft-cheng-supa-ddc-use-cases-05, February 6, 2015 [RFC6020] M. Bjorklund, "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, October 2010. [RFC6991] J. Schoenwaelder, "Common YANG Data Types", RFC 6991, July 2013. Authors' Addresses Georgios Karagiannis Huawei Technologies Hansaallee 205, 40549 Dusseldorf, Germany Email: Georgios.Karagiannis@huawei.com Karagiannis, et al. Expires September 9, 2015 [Page 7] Internet-Draft SUPA Problem Statement March 2015 Qiong Sun China Telecom No.118 Xizhimennei street, Xicheng District Beijing 100035 P.R. China Email: sunqiong@ctbri.com.cn Luis M. Contreras Telefonica I+D Ronda de la Comunicacion, Sur-3 building, 3rd floor Madrid 28050 Spain Email: luismiguel.contrerasmurillo@telefonica.com URI: http://people.tid.es/LuisM.Contreras/ Parviz Yegani JUNIPER NETWORKS 1133 Innovation Way Sunnyvale, CA 94089 Email: pyegani@juniper.net Jean-Francois Tremblay Viagenie inc. Email: jean-francois.tremblay@viagenie.ca Jun Bi Tsinghua University Network Research Center, Tsinghua University Beijing 100084 China EMail: junbi@tsinghua.edu.cn Karagiannis, et al. Expires September 9, 2015 [Page 8]