Network Working Group G. Karagiannis Internet-Draft W. Liu Intended status: Informational T. Tsou Expires: March 25, 2015 Huawei Technologies Q. Sun China Telecom D. Lopez Telefonica P. Yegani Juniper Networks JF Tremblay Viagenie September 25, 2014 Problem Statement for Shared Unified Policy Automation (SUPA) draft-karagiannis-supa-problem-statement-01 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 a vendor neutral standardized application- based interfaces used to expose and define policies and n abstract 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 25, 2015. Karagiannis, et al. Expires March 25, 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Requirements/Objectives . . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 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. However the real value behind central configuration schemes lies within the possible simplification through abstract 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. Karagiannis, et al. Expires March 25, 2015 [Page 2] Internet-Draft SUPA Problem Statement September 2014 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 network 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. Moreover, 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 none of these groups aim (1) at offering truly generic topology models for the standard northbound interface, and (2) that an application can communicate with network boxes, such as network controllers, and NEs, developed by different vendors. SUPA will work on defining vendor-neutral standardized 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 network graph describes (1) topologies at different levels of abstraction, (2) the relationships between the abstraction levels and (3) applied service based policy, which are actions and constraints applied on these topologies. SUPA may also define any mappings to any other network topology data models defined within the IETF. Examples of YANG based data models for network topologies are provided in [ID.draft-contreras-supa-yang-network-topo]. A YANG Data model for SUPA configuration is provided in [ID.draft-zaalouk-supa-configuration-model]. The document [ID.draft-pentikousis-supa-mapping] describes guidelines for mapping configuration and policy into device-level configuration. In particular, SUPA will focus on service specific models that allow applications to request certain network services to be created/deleted/modified. A network service can for example be a virtual link between two endpoints that uses certain properties, traffic engineering, implementation of IPv6 transition mechanism and their enforcement to users. Each network service can be represented by a service based POLICY Karagiannis, et al. Expires March 25, 2015 [Page 3] Internet-Draft SUPA Problem Statement September 2014 model that can model a group of demands (i.e., actions and constraints) that are being initiated by applications that impose similar requirements on the communication network. The terms "UNIFIED" and "SHARED" used in the SUPA abbreviation, relate to the way of how the service policy model is generated, since it groups, unifies and shares the similar requirements imposed by a bulk of applications. SUPA will provide guidelines for mechanisms that can dynamically and on an interoperable manner, AUTOMATICALLY map services and policies defined on an abstract topology graph down to more detailed network graphs and specific network management and controlling policies. 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 service based demands and possibly update its associated network service attributes. For each network service instance a network graph needs to be generated and maintained up to date. The up-to-date network graph needs to be communicated between "Applications", see Figure 1, and the "Management and Control" system. Applications" represent an entity that generates and maintains network services and is administrated by a communication service provider. The "Management and Control" represents a controller that supports the management and control of a communication network. The services and policies defined on an abstract topology graph are automatically mapped down to more detailed network graphs and specific network management and controlling policies. The main goal of SUPA is to provide service specific models that allow applications to request network services to be created/deleted/modified. This can be realized by: o) use YANG [RFC6020], [RFC6991] to model multiple topologies at different levels of abstraction using a network graph, o) use YANG to model the relationships between the abstraction levels. o) transporting model instances using either NETCONF [RFC6241] or RESTCONF [ID.draft-ietf-netconf-restconf]. 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 25, 2015 [Page 4] Internet-Draft SUPA Problem Statement September 2014 --------------------------------------- | Applications | --------------------------------------- | | <-------------- network service | YANG models /NETCONF northbound interface --------------------------------------| | | | Controller | | (Management and Control) | <--- mapping | | network services to | | topology -------------------------------------- | | | | | | <------------ device/feature | | | specific YANG | | | models / NETCONF southbound interface NE1 NE2 NEn Figure 1: SUPA architecture 2. Terminology Network graph: a graph that describes (1) topologies at different levels of abstraction, (2) the relationships between the abstraction levels and (3) applied service based policy, which are actions and constraints applied on these topologies. Network Service: a service, that helps a communication service provider to monitor, control, analyze and manage a communication network. Network topology model: describes the topology of a multi-layer network. Network graph: entity describing an arbitrary topology of nodes and links at any level of granularity. Such a network graph describes (1) topologies at different levels of abstraction, (2) the relationships between the abstraction levels and (3) applied service based policy, which are actions and constraints applied on these topologies. 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). Karagiannis, et al. Expires March 25, 2015 [Page 5] Internet-Draft SUPA Problem Statement September 2014 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 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]. 3.3 IPv6 transition The IPv6 transition has been an ongoing process throughout the world due to the exhaustion of the IPv4 address space. However, this transition leads to costly end-to-end network upgrades and poses new challenges of managing a large number of devices with a variety of transitioning protocols. While IPv6 transition tools exist, there are still new challenges to be solved. Operators may need various types of IPv6 transition technologies depending on performance requirements, deployment scenarios, etc. To address these difficulties, SUPA can be used as the software Karagiannis, et al. Expires March 25, 2015 [Page 6] Internet-Draft SUPA Problem Statement September 2014 defined unifying approach that can provide a unified way to deploy IPv6 in a cost-effective, flexible manner. A detailed description of this use case is provided in [ID.draft-sun-supa-openv6-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. 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: Spencer Dawkins, Jun Bi, Xing Li, Chongfeng Xie, Benoit Claise, Ian Farrer, Marc Blancet, Zhen Cao, Hosnieh Rafiee, Mehmet Karagiannis, et al. Expires March 25, 2015 [Page 7] Internet-Draft SUPA Problem Statement September 2014 Ersue, Simon Perreault, Fernando Gont, Jose Saldana, Tom Taylor, Kostas Pentikousis, Juergen Schoenwaelder. 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-sun-supa-openv6-use-cases] C. Xie, Q. Sun, JF. Tremblay, "Use case of IPv6 transition in SUPA", IETF draft, draft-sun-supa- openv6-use-cases-00, 25 September 2014. [ID. draft-pentikousis-supa-mapping] K. Pentikousis, Junru Lin, Yiyong Zha, "SUPA Configuration and Policy Mapping", IETF Internet draft, draft-pentikousis-supa-mapping-00, September 23, 2014 [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-zaalouk-supa-configuration-model] A. Zaalouk, K. Pentikousis, W. Liu, "YANG Data Model for Configuration of Shared Unified Policy Automation (SUPA)", IETF draft, draft-zaalouk-supa- configuration-model-00, 22 September, 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 [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. Karagiannis, et al. Expires March 25, 2015 [Page 8] Internet-Draft SUPA Problem Statement September 2014 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 1133 Innovation Way Sunnyvale, CA 94089 Email: pyegani@juniper.net Jean-Francois Tremblay Viagenie inc. Email: jean-francois.tremblay@viagenie.ca Karagiannis, et al. Expires March 25, 2015 [Page 9]