Network Working Group C. Zhou Internet-Draft T. Tsou G. Karagiannis Intended status: Informational Huawei Technologies Expires: April 27, 2015 L. M. Contreras Telefonica Q. Sun China Telecom P. Yegani Juniper Networks October 27, 2014 The Architecture for Shared Unified Policy Automation (SUPA) draft-zhou-supa-architecture-00 Abstract Currently, there are network services that impose specific demands on a communication network. SUPA considers two types of network services, the inter Data Center (DC) communication and Virtual Private Networks (VPN). This document describes the SUPA basic architecture, its elements and interfaces. The main SUPA architecture entities are the Network Service Agent (NSA) and the Application-based Policy Decision (ABPD). NSA is a functional entity that creates and runs network services/ ABPD is a functional entity, which 1) enables the generation, maintenance and release of i) actual/detailed network topologies and ii) VPN and inter DC service specific abstractions and 2) mapping between the VPN and inter DC service service specific abstractions and the network topology and configuration. 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 October 27, 2015 [Page 1] Internet-Draft SUPA Architecture October 2014 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 Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. SUPA Architecture . . . . . . . . . . . . . . . . . . . . . . 3 4. Architecture Functional Entities . . . . . . . . . . . . . . . 5 5. Network Elements . . . . . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 9. Normative References . . . . . . . . . . . . . . . . . . . . . 9 10. Informative References . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 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. Providing means 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 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. Zhou, et al. Expires April 27, 2015 [Page 2] Internet-Draft SUPA Architecture October 2014 An abstract view of a network infrastructure can be realized using a network graph, which describes the topology and configuration of a network. In the context of SUPA three types of network graphs are used. The more accurate and detailed network graph type contains the details Protocol Layer 0 to Protocol Layer 7 (L0-L7) of network topology and the configuration 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) managed by the entities involved in the operations of the SUPA functional architecture. The network resources may include routers, switches, and communication links providing connectivity services for the end user application. The second type of network graphs describes the topology and configuration of a VPN service specific abstraction, while the third type of network graphs describes the topology and configuration of a Inter-DC connectivity service specific abstraction. The technology that can be used for this purpose is based on YANG information and data models, see [RFC6020], [RFC6991]. Network service is the composition of network functions and defined by its functional and behavioral specification. The network service contributes to the behavior of the higher layer service, which is characterized by at least performance, dependability, and security specifications. The main goal of this document is to specify the SUPA reference architecture, its elements and interfaces. 2. Terminology The terminology used in the SUPA problem statement draft [ID.karagiannis-supa-problem-statement] applies also to this draft. 3. SUPA Architecture This section provides an overview of the SUPA architecture. An overview of the SUPA architecture is given in Figure 1. The network entities used in this architecture are: Applications: represent one or more network entities that are running and controlling network services. Controller: 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.) Zhou, et al. Expires April 27, 2015 [Page 3] Internet-Draft SUPA Architecture October 2014 Network Element (NE): handles incoming packets based on the network management and controlling procedures. NEs can interact with local or remote network controllers in order to exchange information, such as configuration information, policy enforcement capabilities, and network status. ------------------------------------------------ | +-----------+ +-----------+ +--------------+ | | | L2VPN App | | L3VPN App | | Inter-DC App | | | +-----------+ +-----------+ +--------------+ | | | | +-------------------------------------+ | | | Network Service Agent (NSA) | | | +-------------------------------------+ | | | | Applications | ------------------------------------------------ | \ | | \ | <- service specific | \ | YANG models /NETCONF/RESTCONF | \ | northbound interface | \ | ------------- -------------- | | | | <--- mapping | +------+ | | +------+ | service specific | | ABPD | | | | ABPD | | abstractions to | +------+ | | +------+ | network topology and | | | | configuration | Controller | | Controller | | | | | --------------- ------------- | | | | | | | | | | | | <------- NE/feature | | | | | | specific YANG | | | | | | models / NETCONF | | | | | | southbound interface NE1 NE2 NEn NE1 NE2 NEn Figure 1: SUPA architecture The SUPA architecture functional entities include the Network Service Agent (NSA) and the Application-based Policy Decision (ABPD), as shown in Figure 1. As the figure indicates support for VPN services (L2VPN & L3VPN)and Inter-DC network services are in scope for this release of the architecture. Support for other services and use cases are for further study. Network controllers, exchange configuration information with NEs and derive the actual and detailed network topology model. When an application 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 network controller(s). Subsequently, the network controller(s) provides, a Zhou, et al. Expires April 27, 2015 [Page 4] Internet-Draft SUPA Architecture October 2014 service specific abstraction of the network topology to the application, which should be able to meet the requirements imposed by this application. Different types of applications may get different service specific abstractions of the same network topology from the network controller(s). For example, for the same actual network topology, a VPN network service will receive a different service specific abstraction of the network topology, than an inter-Data Center (DC) network service. For each network service instance a service specific abstraction network graph 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 graph. Moreover, by using such policies, the application can instruct the network controller(s) to map the service specific abstractions to the actual (detailed) network topology and NE specific configuration. 4. Architecture Functional Entities In this document the SUPA architecture is expected to support two sue cases; the VPN and Inter-DC network services, see [ID.draft-cheng-supa-ddc-use-cases] for details. 4.1. Network Service Agent (NSA) Network services can be used to provide the required configuration and application programming interfaces to support a wide variety of communication services offered by service providers. SUPA considers two types of network services, the inter-Data Center (DC) communication and Virtual Private Networks (VPN).For each network service instance a service specific abstraction network graph needs to be generated and maintained. The Network Service Agent (NSA) is a functional entity, residing at the Application layer, that enables network services, such as: o) L2VPN, L3VPN, Inter-DC connectivity, and o) request application based policies and optionally o) update the network graphs associated with each application. As part of the SUPA architecture operational procedures the NSA performs the following functions: O) The NSA sends a request to the ABPD to get the service-specific information to create an abstract network graph for a given application, o) The NSA exchanges necessary information with the ABPD regarding any update on the network graph for a given application along with service-related policy information (e.g., tunneling or traffic- steering policy rules). Zhou, et al. Expires April 27, 2015 [Page 5] Internet-Draft SUPA Architecture October 2014 The internal structure of the NSA is depicted in Figure 2. As the figure shows the sub-functions implemented by each module includes: o) Request Creation/Update service specific network graphs: This sub- function is used to request the information needed to create a new network graph or send an update about an existing graph. Each of the events associated with these operations are trigged via proper signaling exchange with the ABPD, o) NSA - Network Service Interaction: this sub-function is used to provide and receive information, to/from the network service module. The main information received from the network service module is: 1) events that can trigger the request or update of a service specific network graph, or 2) application-based demands. o) "NSA - ABPD interface": this is the interface used to support the signaling protocol exchanges between the NSA and the ABPD. Candidate protocols for such interactions are NETCONF [RFC6241] or RESTCONF [ID.draft-ietf-netconf-restconf]. +----------------------------------------------+ |NSA | | | | +----------------+ | | | Request | | | |Creation/Update | | | | network graph | | | +----------------+ | | | | | | +---------------+ +-----------------+ | | | NSA - Network | | NSA - ABPD | | | | Service | | | | | | Interaction | | Interface | | | +---------------+ +-----------------+ | +----------------------------------------------+ Figure 2: NSA Internal Structure 4.2. Application Based Policy Decision (ABPD) The Application Based Policy Decision (ABPD), is a functional entity located in network controller(s) that is able to generate, maintain and release: 1) actual detailed network graph of a network infrastructure, 2) VPN and Inter-DC service-specific network graphs. Moreover, the ABPD, 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 NSA it can map the service-specific network graphs to the target NE and feature specific YANG models. Figure 3 illustrates the ABPD functionality block diagram, which is Zhou, et al. Expires April 27, 2015 [Page 6] Internet-Draft SUPA Architecture October 2014 based on the ABNO framework specified in [ID.farrkingel-pce-abno-architecture]. This framework was enhanced to satisfy the demands of the SUPA use cases. Note that the realization of the functional architecture defined in [ID.farrkingel-pce-abno-architecture] is out of the scope of SUPA. However, the capabilities provided by the "Provisioning manager" can be combined with capabilities provided by the SUPA defined "ABPD Network Management Interface". The Application Based Policy Decision (ABPD) functions provides a superset of all the ABNO capabilities provided in Figure 1 of [ID.farrkingel-pce-abno-architecture]. Additional functions provided by the ABPD include: o) Actual/detailed network service graph: maintains an up to date description of an actual/detailed network graph that models the topology and configuration of the network infrastructure controlled by the ABPD. If needed than it requests to update all databases, see Section 2.3.1.8 of [ID.farrkingel-pce-abno-architecture] for details. 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) VPN service specific network service graph: maintains an up to date VPN service specific abstraction of the topology and configuration of the network infrastructure controlled by the ABPD. o) inter-DC service-specific network graph: maintains an up to date Inter-DC service specific abstraction of the topology and configuration of the network infrastructure controlled by the ABPD. o) Application to Network Mapping: using the application-based demands and policies received from the NSA it maps the VPN and/or Inter-DC service network graph to the actual/detailed network graph, i.e., it maps the service-specific abstractions to network topology and configuration. Moreover, this functional block provides the mapping of the actual/detailed network graph to NE/feature-specific YANG models. o) ABPD Network Management Interface: provides the interface with existing network management, I2RS [I2RS] NETCONF, etc. protocols to request and negotiate the implementation of the changes into the network status/configuration. o) ABPD-NSA interface: used to support the communication between the NSA and the ABPD. The candidate protocols used for this purpose could be either NETCONF [RFC6241] or RESTCONF [ID.draft-ietf-netconf-restconf]. Zhou, et al. Expires April 27, 2015 [Page 7] Internet-Draft SUPA Architecture October 2014 5. Network Elements The Network Element (NE) handles incoming packets based on the policy information communicated with the ABPD and makes corresponding policy enforcement, which is based on existing network management policies, see Section 5. An NE may be a physical entity or a virtual entity and is locally managed, whether via CLI, SNMP, or NETCONF. | | to/from NSA | +-------------------------------+--------------------------------+ |ABPD Block | | +--------------------------+ | | | ABPD Management Interface| | | +--------+-----------------+ | | +---------- + | +--------+ +----------+ +---------| | | | ABPD-NSA | | | Actual | | VPN / | | Appl. | | | | Interface | | | network| | Inter-DC | | to | | | | | | | graph | | specific | | Network | | | | | | | | | service | | Mapping | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +---------- + | +--+-----+ +---+------+ +--+------+ | | | | | | | | | | | | | | | | +-+-+----+-----------+-------+-+ | | +------+ | | +-------+ | | |Policy+--+ ABPD Controller +----+ | | | |Agent | | +-+ | OAM | | | +-+--+-+ +-+-------------+----------+- + | |Handler| | | | | | | | | | | | | +-----++ | +---+ -+ +-------+-------+ | | +-------+ | | |ALTO | +-+ VNTM |--+ | | | | | |Server| +--+-+-+ | | | +---+--------+ | | +--+---+ | | | PCE | | |I2RS client | | | | +-------+ | | | | | | | | | | | | | | +------------+ | | +------+--+-+ | | | | | | | Databases +-------:----+ | | | | | TED | | +-+---+----+----+ | | | | LSP-DB + | | | | | | | +-----+--+--+ +-+---------------+-------+-+ | | | Provisioning Manager | | | +---------------------------+ | +----------------------------------------------------------------+ Figure 3: ABPD Internal Structure, based on [ID.farrkingel-pce-abno-architecture]. Zhou, et al. Expires April 27, 2015 [Page 8] Internet-Draft SUPA Architecture October 2014 SUPA will specify mechanisms, in order to enable the NEs to interact with either local or remote network controllers 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. 6. 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. 7. IANA Considerations No IANA considerations. 8. 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, Mohamed Boucadair, Jean Francois Tremblay, Tom Taylor. Special thanks are expressed to the authors of the ID [ID.farrkingel-pce-abno-architecture], since a significant part of the ABPD functional blocks are based on the architecture described in [ID.farrkingel-pce-abno-architecture]. 9. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 10. 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.farrkingel-pce-abno-architecture] King, D. and A. Farrel, "A PCE-based Architecture for Application-based Network Operations", IETF Internet draft (Work in progress), October 2014. Zhou, et al. Expires April 27, 2015 [Page 9] Internet-Draft SUPA Architecture October 2014 [ID.karagiannis-supa-problem-statement] G. Karagiannis, W. Liu, T. Tsou, Q. Sun, L. M. Contreras, P. Yegani, JF Tremblay, "Problem Statement for Shared Unified Policy Automation (SUPA) " IETF Internet Draft (work in progress)", 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 Cathy Zhou Huawei Technologies Bantian, Longgang District Shenzhen 518129 P.R. China Email: cathy.zhou@huawei.com Tina Tsou Huawei Technologies Bantian, Longgang District Shenzhen 518129 P.R. China Email: Tina.Tsou.Zouting@huawei.com Georgios Karagiannis Huawei Technologies Hansaallee 205, 40549 Dusseldorf, Germany Email: Georgios.Karagiannis@huawei.com Zhou, et al. Expires April 27, 2015 [Page 10] Internet-Draft SUPA Architecture October 2014 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 April 27, 2015 [Page 11]