Network Working Group C. Zhou Internet-Draft Huawei Technologies L. M. Contreras Intended status: Informational Telefonica Expires: August 06, 2015 Q. Sun China Telecom P. Yegani Juniper Networks February 06, 2015 The Framework of Simplified Use of Policy Abstractions (SUPA) draft-zhou-supa-framework-01 Abstract Currently, there are network services that impose specific demands on a communication network. This document describes the SUPA basic architecture, its elements and interfaces. The main SUPA architecture entities are the Service Management (SM) and the Network Manager/Controller (NM/NC). The SM is a functional entity that creates and runs network services by using a set of NM/NCs. The NM/NC is a functional entity that provides one or more of the following functions: (1) the generation, maintenance and release of network topologies, (2) the generation, maintenance, and release of network service-specific abstractions, (3) the mapping between network service-specific abstractions and the network topology, and (4) the mapping between network service-specific abstractions and network device configuration. Both the SM and the NM/NC may be made up of multiple distinct entities that collectively perform their functions. 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 August 06, 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 .............................................. 4 4. FRAMEWORK FUNCTIONAL ENTITIES ............................... 5 4.1. SERVICE MANAGEMENT ....................................... 5 4.2. NETWORK MANAGER/CONTROLLER ............................... 6 4.3. NETWORK ELEMENTS ......................................... 7 5. SECURITY CONSIDERATIONS ..................................... 7 6. IANA CONSIDERATIONS ......................................... 8 7. ACKNOWLEDGEMENTS ............................................ 8 8. NORMATIVE REFERENCES ........................................ 8 9. INFORMATIVE REFERENCES ...................................... 8 AUTHORS' ADDRESSES ............................................. 9 1. Introduction As the Internet grows, new services are created, new devices are connected, and new users use the Internet. These and other factors contribute to the significant increase in the amount and type of network traffic. This in turn makes network management and configuration more and more complicated. However, the need for dynamic and real-time configuration changes is required. One example is Inter-Data Center (DC) traffic steering and tunneling, based on real-time network status. Dedicated network management applications are required to automate the complicated and Zhou, et al Expires July 5, 2015 Page 2 Internet-Draft SUPA Architecture January 2015 dynamic network configuration present in today's systems. Such applications need interoperable data models of network topology, network services, and policy rules to support the design, deployment, and maintenance of network services. Providing these data models to network management applications may provide significant improvements in configuration agility, error detection, and uptime for operators. However, in order to scale and to ensure configuration change consistency, existing network configuration schemes must be simplified through the use of abstraction. This increases the programmatic control over such systems. 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 one or more network topology data models. Each such topology model, whether physical or logical, may be used as its own reusable managed object. This enables existing topologies to be reused to create new topologies. This applies to models of different layers, including the application layer (L7), IP/network layer (L3), and lower layers (L0-L2, such as MPLS, SDH, OTN, WDM). The network resources may include physical and/or virtual network nodes and links. A network service data model is service specific, and usually relies on a network topology data model. The network service data model defines the behavior of the network service, which is characterized by one or more metrics that include performance, dependability, and security specifications. One method to automate service configuration is to use a policy data model. Policy, in conjunction with network service and device data models, can be used to tell the Network Manager/Controller (NM/NC) how to generate Network Element (NE) configurations using network service data models in combination with topology data models. For example, this process can be used 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 architecture, its elements, and its interfaces. YANG data models (e.g., see [RFC6020], [RFC6991]) can be used for representing service and topology models. 2. Terminology The terminology used in the SUPA problem statement draft [ID.karagiannis-supa-problem-statement] also applies to this draft. NE Network Element NC Network Controller NM Network Manager Zhou, et al Expires July 5, 2015 Page 3 Internet-Draft SUPA Architecture January 2015 NM/NC Network Manager/Controller SM Service Management 3. SUPA Framework +------------------------+ | Service Management | | +--------------------+ | | | Policy Data Model | | | +--------------------+ | | +--------------------+ | | | Service Management | | | | Data Model | | | +--------------------+ | +------------------------+ | | | NETCONF/RESTCONF ----------------------------------------------- | | | | +----------------------------+ +----------------------------+ | Network Manager/Controller | | Network Manager/Controller | | +------------------------+ | | +------------------------+ | | | Network Resource | | | | Network Resource | | | | Data Model | | | | Data Model | | | +------------------------+ | | +------------------------+ | +----------------------------+ +----------------------------+ | | | | | | | | | | | | | | | | | | NE1 NE2 NEn NE1 NE2 NEn Figure 1 SUPA Framework An overview of the SUPA framework is shown in Figure 1. The network entities used in this framework are: SM: Service Management, which represents one or more network entities that are running and controlling network services. Policy Data Model Model of policy rules for managing the network service and mapping services dynamically to the network topology and network resources. Example of policy data model can be found in [TBD]. There can be various types of policies, including service specific policies and network-wide policies. There can be a centralized entity managing the network-wide policies, which may be called as policy manager. The policy manager can be located in the SM or in a separate location. Zhou, et al Expires July 5, 2015 Page 4 Internet-Draft SUPA Architecture January 2015 Service Management Data Model Model of the network service (e.g., VPNs) and the network resources required by the network service to be correctly deployed and executed on the physical and/or virtual topology. Example of service management data model can be found in [ID.draft-adel-vpn-service-management-model]. NM/NC: Network Manager / Controller, which 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 Resource Data Model Model of the physical and virtual network topology including the resource attributes (e.g., data rate or latency of links) and operational parameters needed to support service deployment over the network topology. Example of network resource data model can be found in [ID.draft-contreras-supa-yang-network-topo] Network Element (NE), which handles packets based on the network management and controlling procedures. NEs can interact with local or remote NM/NC in order to exchange information, such as configuration information, policy enforcement capabilities, and network status. Service Management (SM) communicates with Network Manager/Controller (NM/NC) using an appropriate protocol, such as NETCONF [RFC6241] or RESTCONF [ID.draft-ietf-netconf-restconf]. NM/NC exchanges configuration information with NEs and derives the current network topology that contains the NEs, and also the capabilities and status of NEs, which will be stored in network resource data model. NM/NC may also communication with traditional network management system to retrieve the above information. It can use existing network management and signaling protocols, such as I2RS [I2RS], NETCONF [NETCONF], RESTCONF [ID.draft-ietf-netconf- restconf], etc. Service Management (SM) will send policy data model and service management data model, which will in conjunction with network resource data model be mapped to detail NEs' configurations by network manager / controller. 4. Framework Functional Entities 4.1. Service Management Zhou, et al Expires July 5, 2015 Page 5 Internet-Draft SUPA Architecture January 2015 There are a wide variety of communication services offered by service providers. The Service Management (SM) is a functional entity, residing at the Application layer, which enables network services, such as: o) Network services (e.g., L2VPN, L3VPN, etc.) o) application-specific policies SM will push service management data model and policy data model to NM/NC for service deployment. 4.2. Network Manager/Controller | | to/from Service Management | +--------------------------+----------------------------------------+ | Network Manager/Controller Functional Block | | +-------------------------------+ +---------------------------+ | | | | | mapping: Policy Data | | | | Network Resource Data Model | | Model + Network Resource | | | | | | Data Model to Service | | | +-------------------------------+ | Specific Topology | | | +---------------------------+ | | +-------------------------------+ +---------------------------+ | | | NM/NC to SM Interface | | mapping: Service Data | | | +-------------------------------+ | Model + Service Specific | | | +-------------------------------+ | Topology to Detail NEs' | | | | NM/NC to NE Interface | | Configurations | | | +-------------------------------+ +---------------------------+ | +-------------------------------------------------------------------+ Figure 2 NM/NC Functional Blocks Network Manager/Controller (NM/NC) is a functional entity that is able to generate and maintain desired and current topologies of the network infrastructure. As part of this process, it is also responsible for reserving and releasing network resources that are required to support network services in a given network infrastructure. The NM/NC contains a set of data models, functions and APIs, including: o) Network Resource Data Model Maintain an up to date topology of the network infrastructure, including capabilities and current status of NEs. o) Mapping: service specific topology This mapping procedure will combine the policy data model and service management data model and generate a specific topology. o) Mapping: target NE(s) detail configurations Zhou, et al Expires July 5, 2015 Page 6 Internet-Draft SUPA Architecture January 2015 This mapping procedure will use the service specific topology generated in the previous procedure and the service management data model to generate detail NE(s) configurations. o) NM/NC to traditional network management system interface: provides the interface with existing network management system protocols (e.g., I2RS [I2RS], NETCONF, etc.) to request configuration and status information, and push configuration changes to NEs. o) NM/NC to SM interface: used to support the communication between the SM and NM/NC. The candidate protocols used for this purpose could be either NETCONF [RFC6241] or RESTCONF [ID.draft-ietf- netconf-restconf]. An example of the mapping procedures can be that, a service requires that a link from A to B is created; and the policy requires that the hops of this link should not exceed N. Then when NM/NC receives the policy data model and service management data model from SM, it will first apply the policy data model to the network resource data model and get a sub-set topology which can fulfill the hops limit requirements. Then NM/NC will further generate detail configurations for target NE(s). The mapping procedures can be enforced by functional entity called policy agent. After the service is deployed, if there is a network topology change, network configurations for this service may need to be updated accordingly. A possible solution is to repeat the mapping procedures, and generate configurations for NEs (maybe another set of NEs). This requires that NM/NC maintains a copy of the service management data models and policy data models. For more detail about mapping mechanisms, please refer to [ID.draft- pentikousis-supa-mapping]. 4.3. Network Elements The Network Element (NE) responds to requests and commands from the NM/NC and makes corresponding configuration changes. An NE may be a physical or a virtual entity, and is locally managed (e.g., via CLI, SNMP, or NETCONF). SUPA will specify mechanisms, in order to enable the NEs to interact with either local or remote network management systems. The interaction may include the exchange of information, such as configuration and status information. The NEs will be able to push this information in an event that the NM/NC can subscribe to, and/or provide this information after receiving a request from the NM/NC. 5. Security Considerations Security is a key aspect of any protocol that allows state installation and extracting of detailed configuration states. More Zhou, et al Expires July 5, 2015 Page 7 Internet-Draft SUPA Architecture January 2015 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, Mohamed Boucadair, Jean Francois Tremblay, Tom Taylor, Tina Tsou, Georgios Karagiannis, John Strassner, Raghav Rao. 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 issues 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 a 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 Zhou, et al Expires July 5, 2015 Page 8 Internet-Draft SUPA Architecture January 2015 [ID.draft-contreras-supa-yang-network-topo] L.Contreras, Andrew Qu, Yiyong Zha, "A YANG Data Model for Network Topologies", IETF Internet draft (Work in progress), draft-contreras-supa-yang- network-topo-02, January 2015 [ID.draft-adel-vpn-service-management-model] D. Zhang, A. Zaalouk, K. Pentikousis, "VPN Service Management YANG Data Model", IETF Internet draft (Work in progress), draft-adel-vpn-service-management-model-00, January 2015 [ID.draft-pentikousis-supa-mapping] K. Pentikousis, D. Zhang, "Shared Unified Policy Automation (SUPA): Configuration and Policy Mapping", IETF Internet draft (Work in progress), draft-pentikousis- supa-mapping-02, January 2015 [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 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 Zhou, et al Expires July 5, 2015 Page 9 Internet-Draft SUPA Architecture January 2015 Parviz Yegani JUNIPER NETWORKS 1133 Innovation Way Sunnyvale, CA 94089 Email: pyegani@juniper.net Zhou, et al Expires July 5, 2015 Page 10