Network Working Group C. Zhou Internet-Draft Huawei Technologies L. M. Contreras Intended status: Informational Telefonica Expires: July 15, 2015 Q. Sun China Telecom P. Yegani Juniper Networks January 15, 2015 The Framework of Shared Unified Policy Automation (SUPA) draft-zhou-supa-framework-00 Abstract Currently, there are a lot of network services that impose specific demands on a communication network, which makes it significantly more challenging to network management and service deployment. SUPA aims to provide a set of data models and a framework to simply the deployment and management of network services. This document describes the SUPA basic framework and its elements. The main SUPA framework entities are the Operation and Management Application (OAMA) and the Management Agent (MA). OAMA is a functional entity that creates and runs network services; MA is a functional entity which enables the generation, maintenance and release of network topologies and network service specific abstractions, and maps network service specific abstractions in combination with network topology and policy to detail network element configurations. 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 April 27, 2015. 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. Zhou, et al Expires July 5, 2015 Page 1 Internet-Draft SUPA Architecture January 2015 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. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Table of Content 1. INTRODUCTION ................................................... 2 2. TERMINOLOGY .................................................... 3 3. SUPA FRAMEWORK ................................................. 3 4. FRAMEWORK FUNCTIONAL ENTITIES .................................. 5 4.1. OPERATION AND MANAGEMENT APPLICATION ........................ 5 4.2. MANAGEMENT AGENT ............................................ 5 4.3. NETWORK ELEMENTS ............................................ 7 5. SECURITY CONSIDERATIONS ........................................ 7 6. IANA CONSIDERATIONS ............................................ 7 7. ACKNOWLEDGEMENTS ............................................... 7 8. NORMATIVE REFERENCES ........................................... 8 9. INFORMATIVE REFERENCES ......................................... 8 AUTHORS' ADDRESSES ................................................ 8 1. Introduction As the Internet grows, more and more new services keep on arising, and network traffic is rapidly increased, which makes network management and configuration more and more complicated, while on the other hand, dynamic and real-time configuration change is required, e.g. Inter-Data Center (DC) traffic steering and tunneling, based on real-time network status. Network applications can be used to automate the complicated and dynamic network configuration. For this goal, data models of network topology, data models of network services, data model of network service development policies are very necessary. Providing these data models to applications may Zhou, et al Expires July 5, 2015 Page 2 Internet-Draft SUPA Architecture January 2015 provide significant improvements in configuration agility, error detection and uptime for operators. However the real value behind these configuration schemes lies within the possible simplification through abstract models provided by such systems to applications and network services 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. An abstract view of a network infrastructure can be realized using network topology data model. The more accurate and detailed network topology contains the details Protocol Layer 0 to Protocol Layer 7 (L0-L7) of network topology of a network infrastructure. This is the case where resources across different layers including application layer (L7), IP/network layer (L3), and lower layers (L0-L2), e.g., MPLS, SDH, OTN, WDM). The network resources may include physical and/or virtual network node and links, e.g. routers, switches, and VPN, etc. Network service data model is service specific, and usually it relies on network topology data model. The network service contributes to the behavior of the higher layer service, which is characterized by at least performance, dependability, and security specifications. In order to automate service configuration, sometimes it is necessary to use a policy data model to tell the network Management Agent (MA) how to map network service data model in combination with topology data model into detail Network Element (NE) configuration, e.g. how to choose a path for VPN which will involve a set of NE's. The main goal of this document is to specify the SUPA reference framework, its elements and interfaces. The technology that can be used for this purpose is based on YANG information and data models, see [RFC6020], [RFC6991]. 2. Terminology The terminology used in the SUPA problem statement draft [ID.karagiannis-supa-problem-statement] applies also to this draft. NE Network Element MA Management Agent OAMA Operation and Management Application 3. SUPA Framework Zhou, et al Expires July 5, 2015 Page 3 Internet-Draft SUPA Architecture January 2015 +-------+ +-------+ | OAMA | | OAMA | +-------+ +-------+ | | <-----SUPA data models | | --------------------------------- BUS | | | | +-------------+ +-------------+ | Management | | Management | | Agent | | Agent | +-------------+ +-------------+ | | | | | | | | | | | | | | | | | | NE1 NE2 NEn NE1 NE2 NEn Figure 1: SUPA Framework This section provides an overview of the SUPA framework. An overview of the SUPA framework is given in Figure 1. The network entities used in this framework are: OAMA: Operation and Management Application, represents one or more network entities that are running and controlling network services. MA: Management Agent, represents one or more entities that are able to control the operation and management of a network infrastructure, e.g., a network topology that consists of Network Elements (NEs.) Network Element (NE): handles incoming packets based on the network management and controlling procedures. NEs can interact with local or remote MA in order to exchange information, such as configuration information, policy enforcement capabilities, and network status. BUS: there can be multiple OAMAs and MAs in a large scale network, either in a single administrative domain or in multiple administrative domains. The communication between OAMAs and MAs can make use of a BUS. A BUS can be a message queue service, or a dedicated (small) network or VPNs. MA exchanges configuration information with NEs and derive the actual and detailed network topology model. When an OAMA needs to use this network topology it applies NETCONF [RFC6241] or RESTCONF [ID.draft-ietf-netconf-restconf] and it sends a request to receive a service specific abstraction from the MA(s). Subsequently, the MA(s) provides a service specific abstraction of the network topology to the application, which should be able to meet the requirements imposed by this application. Various types of applications may get different service specific abstractions of the same network topology from MA. For example, for the same actual network topology, a VPN network service will receive a different service specific Zhou, et al Expires July 5, 2015 Page 4 Internet-Draft SUPA Architecture January 2015 abstraction of the network topology, than an inter-Data Center (DC) network service. For each network service instance a service specific abstraction network topology needs to be generated and maintained. A network service can use application based demands and policies, such as tunneling or traffic steering, and possibly update its associated service specific abstraction network topology. Moreover, by using such policies, the application can instruct MA to map the service specific abstractions to the actual (detailed) network topology and NE specific configuration. 4. Framework Functional Entities 4.1. Operation and Management Application There are a wide variety of communication services offered by service providers. For each network service instance a service specific abstraction network topology needs to be generated and maintained. The Operation and Management Application (OAMA) is a functional entity, residing at the Application layer, which enables network services, such as: o) Network service, e.g. L2VPN, L3VPN, etc. o) Application based policies o) Update network topologies associated with each application. As part of the SUPA operational procedures, OAMA performs the following functions: o) OAMA sends a request to MA to get service-specific information to create an abstract network topology for a given application. o) OAMA exchanges necessary information with MA regarding any update on the network topology for a given application along with service-related policy information (e.g., tunneling or traffic-steering policy rules). 4.2. Management Agent Zhou, et al Expires July 5, 2015 Page 5 Internet-Draft SUPA Architecture January 2015 | | to/from OAMA | +--------------------------+------------------------------+ |Management Agent Functional Block | | | | +----------+ +----------+ +---------+ +---------+ | | | Generic | | Network | | Policy | | Service | | | | Network | | Services | | Rules | | to | | | | Topology | | Specific | | For | | Network | | | | | | Topology | | Service | | Mapping | | | +----------+ +----------+ +---------+ +---------+ | | | | +---------------------+ +-------------------------+ | | | MA - OAMA Interface | | MA Management Interface | | | +---------------------+ +-------------------------+ | +---------------------------------------------------------+ Figure 2: MA Functional Blocks Management Agent (MA) is a functional entity that is able to generate, maintain and release: 1) Detailed network topology of a network infrastructure 2) Network service-specific network topology. Moreover, MA supports the SUPA northbound interface/protocol. It also supports a software repository, which stores the information associated with each NE. By using application-based demands & policies received from the OAMA it can map the service-specific network topology and feature specific YANG models to the target NE(s). This framework was enhanced to satisfy the demands of the SUPA use cases. The MA function provides a set of functions, including: o) Detailed network topology: maintains an up to date description of a detailed network topology that models the topology and configuration of the network infrastructure. Moreover, it can use existing network management and signaling protocols, such as I2RS [I2RS], NETCONF [NETCONF], RESTCONF [ID.draft-ietf-netconf-restconf], etc., to request the implementation of the changes into the network status/configurations. o) Network service specific topology: maintains an up to date service specific abstraction of the topology of the network infrastructure, e.g. VPN service. o) Policy Rules for Network Service: the policies can help to automate service deployment and management, e.g. a policy when the traffic load on a link exceeds a threshold, MA will configure an extra link and perform load-balance. MA will maintain a repository of policy rules. o) Application to Network Mapping: using the application-based demands and policy data model received from the OAMA it maps service specific network topology to the actual/detailed network Zhou, et al Expires July 5, 2015 Page 6 Internet-Draft SUPA Architecture January 2015 topology. Moreover, this functional block provides the mapping of the actual/detailed network topology to NE/feature-specific YANG models. o) MA to network management system interface: provides the interface with existing network management system, I2RS [I2RS] NETCONF, etc. protocols to request and negotiate the implementation of the changes into the network status/configuration. o) MA to OAMA interface: used to support the communication between the OAMA and MA. The candidate protocols used for this purpose could be either NETCONF [RFC6241] or RESTCONF [ID.draft- ietf-netconf-restconf]. 4.3. Network Elements The Network Element (NE) handles incoming packets based on the policy information communicated with MA and makes corresponding policy enforcement, which is based on existing network management policies. An NE may be a physical entity or a virtual entity and is locally managed, via CLI, SNMP, or NETCONF. SUPA will specify mechanisms, in order to enable the NEs to interact with either local or remote network management system in order to exchange information, such as configuration and status information. The NEs will be able to push this information in an event or periodic basis towards the network controller or provide it after receiving a request from the network controller. 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. 6. IANA Considerations No IANA considerations. 7. Acknowledgements The authors of this draft would like to thank the following persons for the provided valuable feedback: Diego Lopez, Jose Saldana, Spencer Dawkins, Jun Bi, Xing Li, Chongfeng Xie, Benoit Claise, Ian Farrer, Marc Blancet, Zhen Cao, Hosnieh Rafiee, Mehmet Ersue, Zhou, et al Expires July 5, 2015 Page 7 Internet-Draft SUPA Architecture January 2015 Mohamed Boucadair, Jean Francois Tremblay, Tom Taylor, Tina Tsou, Georgios Karagiannis. Early version of this draft can be found here: https://tools.ietf.org/html/draft-zhou-supa-architecture-00 At the early stage of SUPA, we think quite some issue are left open, it is not so suitable to call this draft as "architecture". we would like to rename it to "framework". Later there may be dedicated architecture document. 8. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 9. Informative References [I2RS] Interface to the Routing System (i2rs) charter, http://datatracker.ietf.org/wg/i2rs/charter/ [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-03, October 2014 [ID.karagiannis-supa-problem-statement] G. Karagiannis, Q. Sun, L. M. Contreras, P. Yegani, JF Tremblay, "Problem Statement for Shared Unified Policy Automation (SUPA) " IETF Internet Draft (work in progress)", draft-karagiannis-supa-problem-statement-02,October 2014. [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-01, October 2014 [NETCONF] Network Configuration (netconf) charter, http://datatracker.ietf.org/wg/netconf/charter/ [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. [RFC6241] R. Enns, M. Bjorklund, J. Schoenwaelder, A. Bierman, "Network Configuration Protocol (NETCONF)", RFC 6241, June 2011. Authors' Addresses Zhou, et al Expires July 5, 2015 Page 8 Internet-Draft SUPA Architecture January 2015 Cathy Zhou Huawei Technologies Bantian, Longgang District Shenzhen 518129 P.R. China Email: cathy.zhou@huawei.com 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/ Qiong Sun China Telecom No.118 Xizhimennei street, Xicheng District Beijing 100035 P.R. China Email: sunqiong@ctbri.com.cn Parviz Yegani JUNIPER NETWORKS 1133 Innovation Way Sunnyvale, CA 94089 Email: pyegani@juniper.net Zhou, et al Expires July 5, 2015 Page 9