Network Working Group G. Karagiannis Internet-Draft W. Liu Intended status: Informational T. Tsou Expires: March 20, 2015 Huawei Technologies Q. Sun China Telecom D. Lopez Telefonica P. Yegani Juniper Networks JF Tremblay Viagenie September 20, 2014 Problem Statement for Shared Unified Policy Automation (SUPA) draft-karagiannis-supa-problem-statement-00 Abstract As modern network management applications grow in scale and complexity, their demands and requirements on the supporting communication network increase. In particular, network operators are challenged to create a simplified view of their network infrastructure and help service developers on using and programming this simplified view rather than manipulating individual devices. In this context, providing service developers with a set of standard interfaces to configure and set policies on the network is essential. This document describes what has to be addressed in order to equip service providers with standardized application-based interfaces used to expose and define policies and a simplified view of network infrastructure. 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." This Internet-Draft will expire on March 20, 2015. Karagiannis, et al. Expires March 20, 2015 [Page 1] Internet-Draft SUPA Problem Statement September 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 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 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Requirements/Objectives . . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 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 services depend on them. Programmatic ways to configure networks, often called software-defined, are considered by many network operators in order to shift the balance in their favor. Currently, the separation of development and operation of network technologies leads to slow deployment of network functions/devices and poor user experiences. Automating the way of exposing a view of the network to applications may provide significant improvements in configuration agility, error detection and uptime for operators. Karagiannis, et al. Expires March 20, 2015 [Page 2] Internet-Draft SUPA Problem Statement September 2014 However the real value behind central configuration schemes lies within the possible simplification through simplified models provided by such systems to applications and network zervices running above them (on the so-called northbound side). Well-designed simplified models are able to provide a wide range of granularity for various applications and network services needs, from the lower-level physical network to high-level application services. 1.1 Motivation Although several organizations outside of the IETF have defined various schemes for the configuration of network devices and specific network controllers, none of them offer a vendor-neutral standardized way for applications and network services to transmit their needs to controllers. The SUPA (Shared Unified Policy Automation) working group will work on the definition of such as standardized interface for applications and network services to communicate with network controllers of all types. The specification of the interface towards end user apllications is initially not in the scope of SUPA. In particular, as starting point, SUPA will only focus on network services, which are enhanced Operational Support System (OSS) like services that help a communication service provider to monitor, control, analyze and manage a communication network. The systems that are runniung such network services are denoted in this document as Network Service Systems (NSS). Each network service can be represented by a classified application based POLICY model, since it can model the group of demands which are SHARED and UNIFIED and are coming from a bundle of applications that impose similar requirements on the communication network. Although some IETF working groups have started work relating to the description of various topologies such as I2RS (L3and routing topologies), ALTO (cost maps), SFC (service chain), none of these groups aim at offering truly generic topology models for the standard northbound interface. An example of a YANG based data model for network topologies is provided in [ID. draft-contreras-supa-yang-network-topo]. SUPA will work on defining interfaces based on the concept of network graph, an entity describing an arbitrary topology of nodes and links at any level of granularity. Such a graph may describe, for example, a physical topology, a service topology or the relationships between datacenters. Any network topology data models or policy models that have been defined (or are being defined) within the IETF will be reused in SUPA as much as possible. In addition to the above, policies may be defined and applied to a network graph. These application based policies are actions or constraints generated by network service systems. They are then mapped from the network graph instance into specific network management policies toward network components. Such application based demands are of the following types: Karagiannis, et al. Expires March 20, 2015 [Page 3] Internet-Draft SUPA Problem Statement September 2014 *) Configuration requests: o) Dynamically configure e.g., a L3VPN inter-connecting DCs, a service topology, the relationships between datacentres *) Data plane requests: o) Traffic flow steering o) Traffic flow prioritizing o) Encapsulate/de-capsulate a traffic flow o) Block or admit a traffic flow *) Control plane / Routing plane requests: o) Change the routing state on a service or network function In this context, network services can be used to provide the required configuration and application programming interfaces to such service developers. Subsequently, a network service can use the application based demands and possibly update its associated network service attributes. For each network service instance a network graph needs to be generated and maintained. The up-to-date network graph needs to be communicated between the network service systems and the network management and controlling systems. The attributes of the network graph need to be mapped into specific network management policies, i.e., device level configuration models. The main goal of SUPA is to provide a way for applications and for network services to specify SHARED application based POLICIES to the network infrastructure using a simplified view of the network. This can be realized by: (1) modeling the network infrastructure as a simplified network graph using a modeling language such as YANG [RFC6020], [RFC6991], (2) transporting model instances either using NETCONF [RFC6241] or RESTCONF [ID.draft-ietf-netconf-restconf] and (3) providing guidelines on AUTOMATICALLY mapping policies to attributes of the network graphs. Figure 1 shows the SUPA goal and scope. This document is organized as follows. Section 2 presents the terminology. Section 3 provides a brief overview of the use cases associated with SUPA. The requirements/objectives are provided in Section 4. Section 5 provides the security considerations. The IANA considerations are given in Section 6. Section 7 gives the acknowledgements and Section 8 lists the used references. Karagiannis, et al. Expires March 20, 2015 [Page 4] Internet-Draft SUPA Problem Statement September 2014 +--------------+ +--------------+ | Applications | | Applications | +--------------+ +--------------+ | | +--------------------------+ +--------------------------+ - | +-----------------+ | | +-----------------+ | ^ | | Network service | | | | Network service | | | | +-----------------+ | | +-----------------+ | | | | Network Graph | ... | | | Network Graph | | | | | | | | | | | | | +-----------------+ | ... | +-----------------+ | | | | | | | | | | | | | | | | | | Network service | | Network service | | | system | | system | | +----------^---------------+ +----------^---------------+ | | | | +-----------------+--------------------+ SUPA | scope | | | NETCONF/RESTCONF/YANG | | +----------------------+ | | | Network Graph | | | +----------------------+ | +---------v--------------+ | | Network management & | | | control systems | | | | | | | | | | | | | V +--------------^---------+ ----- | +-------------------+------------------+ | | | | | | +-------------v---------------+ +------------v-------------+ | | | | | | ... | | | Network Element | | Network Element | +-----------------------------+ +--------------------------+ Figure 1: SUPA goal and scope 2. Terminology Device level configuration model: supports the description of the network management policies and it describes the configuration details at the device level. Network service dependencies: dependencies between different service functions/nodes. Karagiannis, et al. Expires March 20, 2015 [Page 5] Internet-Draft SUPA Problem Statement September 2014 Network Service: enhanced Operational Support System (OSS) like service that help a communication service provider to monitor, control, analyze and manage a communication network. Each network service can be represented by a classified application based policy model, since it can model the group of demands coming from a bundle of end user applications that impose similar requirements on the communication network. Network service systems: Systems or platforms that run the network service. The interface between NSS and end user applications is out of the scope of this document. Network configuration model: provides a declarative configuration of the network Network topology model: describes the topology of a multi-layer network. Network graph: an entity describing an arbitrary topology of nodes and links at any level of granularity. Such a graph may describe, for example, a physical topology, a L2 network, a service topology or the relationships between datacenters. Network element: a physical entity or a virtual entity that can be locally managed and operated. 3. Use Cases This section briefly describes the use cases that are associated with different types of network services. The detailed description of these use cases is provided in other Internet draft(s). 3.1 Distributed Data Center 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 network, traffic is routed by configuring policy routes and adjusting routes prioritization to choose an outgoing link. This type of static provisioning comes with high costs and poor operability. Furthermore, the link bandwidth resources in the data centers are not efficiently utilized. Services usually do not have consistent bandwidth requirements at all times of a day, e.g. video ISP usually require more Karagiannis, et al. Expires March 20, 2015 [Page 6] Internet-Draft SUPA Problem Statement September 2014 bandwidth at non-working hours but require less bandwidth at working hours. Some customers have relative high QoS requirement for their services, e.g. IM (Instant Messaging). Static bandwidth and QoS provisioning for all the customers and services is not reasonable and not a cost-effective solution. SUPA can be used to request the optimization of the traffic paths dynamically and have the ability to request the load balance between data centers and links, and direct customer traffic via network management policies (e.g., models, software programs routines) based on customer grade and QoS requirements. A detailed description of this use case is provided in [ID.draft-cheng-supa-ddc-use-cases]. 3.2 Mobile Networks GiLAN is another important application of network function virtualization. In mobile core networks, it is preferable that QoS provisioning and network function requirements are different for subscribers with different profiles. In such scenarios, specialized network services such as BSS/OSS can send application based demands to a policy decision point, which further map these application based demands to GiLAN specific policies, and realize the required QoS and with appropriate network functions, for example, for dynamic path reconfiguration. A detailed description of this use case is provided in [ID.draft-huang-aponf-use-cases]. 4. Requirements/Objectives The requirements/objectives that need to be supported by the SUPA methods, models and protocol solutions are the following ones: Work items for SUPA include: o) The definition of a standardized model for a network graph, using YANG. This model may be used to describe topologies at any functional layer, from physical networks to network services. Any network topology data models or policy models that have been defined (or are being defined) within the IETF will be reused in SUPA as much as possible. o) The definition and standardization of a number of basic policy and data models using network graphs. These might include, but are not limited to L3VPNs, datacenters, traffic engineering, implementation of IPv6 transition mechanism and their enforcement to users. o) Guidelines on how to use NETCONF (or RESTCONF) authentication and authorization mechanisms to achieve protection and isolation o) Guidelines for automatic mapping policies to attributes of the network graphs. Karagiannis, et al. Expires March 20, 2015 [Page 7] Internet-Draft SUPA Problem Statement September 2014 The following items are out of the SUPA scope: o) specification of the network management and controlling policies and their associated device configuration models 5. Security Considerations Security is a key aspect of any protocol that allows state installation and extracting of detailed configuration states. More investigation remains to fully define the security requirements, such as authorization and authentication levels. SUPA document how to use either the NETCONF or RESTCONF authentication and authorization mechanisms to achieve necessary security protection and isolation 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. 8. References 8.1. Normative References 8.2. Informative References [ID.draft-cheng-supa-ddc-use-cases] Y. Cheng, C. Zhou, G. Karagiannis, JF. Tremblay, "Use Cases for Distributed Data Center Applicatinos in APONF", IETF Internet draft (Work in progress), draft-cheng-supa-ddc-use-cases-00, September 17, 2014 [ID. draft-contreras-supa-yang-network-topo] L.Contreras, Andrew Qu, "A YANG Data Model for Network Topologies", IETF draft (work in progress), draft-contreras-supa-yang-network-topo, September 18, 2004. [ID.draft-huang-aponf-use-cases] C. Huang, Jiafeng Zhu, Peng He, Shucheng (Will) Liu, G. Karagiannis, "Use Cases on Application- centric Network Management and Service Provision" IETF Internet draft (Work in progress), draft-huang-aponf-use-cases-01, Juy 2014 [ID.draft-ietf-netconf-restconf] A. Bierman, M. Bjorklund, K. Watsen, R. Fernando, "RESTCONF Protocol", IETF Internet draft (work in progress), draft-ietf-netconf-restconf-01, July 2014 Karagiannis, et al. Expires March 20, 2015 [Page 8] Internet-Draft SUPA Problem Statement September 2014 [NIST SP 800-146] Badger et al.: "Draft Cloud Computing Synopsis and recommendations", NIST specifications, May 2011. [RFC6020] M. Bjorklund, "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, October 2010. [RFC6241] R. Enns, M. Bjorklund, J. Schoenwaelder, A. Bierman, "Network Configuration Protocol (NETCONF)", RFC 6241, June 2011. [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 Will(Shucheng) Liu Huawei Technologies Bantian, Longgang District Shenzhen 518129 P.R. China Email: liushucheng@huawei.com Tina Tsou Huawei Technologies Bantian, Longgang District Shenzhen 518129 P.R. China Email: Tina.Tsou.Zouting@huawei.com Qiong Sun China Telecom No.118 Xizhimennei street, Xicheng District Beijing 100035 P.R. China Email: sunqiong@ctbri.com.cn Diego Lopez Telefonica Email: diego@tid.es Parviz Yegani Juniper Networks 1194 North Mathilda Ave. Sunnyvale, California 94089 U.S.A Phone: +1 408-759-1973 Email: pyegani@juniper.net Karagiannis, et al. Expires March 20, 2015 [Page 9] Internet-Draft SUPA Problem Statement September 2014 Jean-Francois Tremblay Viagenie inc. Email: jean-francois.tremblay@viagenie.ca Karagiannis, et al. Expires March 20, 2015 [Page 10]