Network Working Group K. Pentikousis Internet-Draft EICT GmbH Intended status: Informational D. Zhang Expires: September 10, 2015 Alibaba March 9, 2015 Simplified Use of Policy Abstractions (SUPA): Configuration and Policy Mapping draft-pentikousis-supa-mapping-04 Abstract Nowadays, the underlying network infrastructure grows in scale and complexity, which make it challenging for network operators to manage and configure the network. Deploying policy or configuration based on an abstract view of the underlying network is much better than manipulating each individual network element, however, in this case, the policy and configuration cannot be recognized by the network elements. This document describes guidelines for mapping said abstract configuration and policy into device-level configuration and the way in which such models will be processed by software to produce configuration details for actual devices. The Simplified Use of Policy Abstractions (SUPA) framework overview and primary procedures of mapping are described. Moreover, an exemplary mapping scenario is provided to illustrate the defined mechanism. 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 September 10, 2015. Pentikousis & Zhang Expires September 10, 2015 [Page 1] Internet-Draft SUPA Configuration and Policy Mapping March 2015 Copyright Notice Copyright (c) 2015 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. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Configuration and Policy Mapping . . . . . . . . . . . . . . 3 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3 4.2. Mapping Procedure . . . . . . . . . . . . . . . . . . . . 5 4.3. SUPA Mapping Example . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 8.1. Normative References . . . . . . . . . . . . . . . . . . 13 8.2. informative References . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 1. Introduction As the underlying network infrastructure grows, new services are introduced, and traffic volumes increase rapidly, it becomes significantly more challenging and complicated to maintain the network and deploy new services than in the past. Configuration automation can provide significant benefits in deployment agility. Simplified Use of Policy Abstractions (SUPA) [I-D.zhou-supa-framework] aims to improve configuration automation by introducing multi-level abstractions. In SUPA, the definition of a standardized model for a network topology graph, which could be used to describe topologies at any functional layer, and information models of various network services and network service development policies allow network operators to manipulate their infrastructure as a whole rather than individual devices. Well-designed abstractions are able to provide a wide range of granularity for Pentikousis & Zhang Expires September 10, 2015 [Page 2] Internet-Draft SUPA Configuration and Policy Mapping March 2015 various applications needs, from the lower-level physical network to high-level network services. However, these information models cannot be directly utilized by network elements, thus a mapping mechanism is necessary to bridge the gap between these information models and network element-recognized configuration. SUPA employs Network Manager/Controller. Network Manager/Controllers represent one or more entities that are able to control the operation and management of a network infrastructure and mediate between the Service Management and the network elements to provide, maintain and deploy network services and policies. Each Network Manager/ Controller supports the SUPA interface/protocol and is a software repository, which stores the information associated with each network element. The mapping mechanism could be part of the Network Manager/ Controller implementation in order to map the SUPA model(s) into specified configuration models (or so-called southbound interfaces), which can be recognized by the network element(s). 2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "Network Manager/ControllerY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Terminology This document uses the following terms: Network element (NE): a physical or virtual entity that can be locally managed and operated SUPA: Simplified Use of Policy Abstractions 4. Configuration and Policy Mapping This section introduces a framework for mapping configuration and policy in the context of a network with several network elements and one or more Service Managements. 4.1. Overview The SUPA framework for mapping network-level configuration into specific network management and controlling policies is illustrated in Figure 1. It consists of i) Service Management, ii) Network Manager/Controller and iii) NEs. Pentikousis & Zhang Expires September 10, 2015 [Page 3] Internet-Draft SUPA Configuration and Policy Mapping March 2015 +------------------------+ ------------------------- | Service Management | | | +--------------------+ | | | | Policy | | | | +--------------------+ | | | +--------------------+ | | | | Service Management | | | | | | | | | +--------------------+ | | +------------------------+ | | NetConf/RestConf | | Network +-----------------v--------------+ Level | +------------------------+ | | | | Network Resource | | | | | | | | | +------------------------+ | | | Network | | | Management/Controller ------------------------- | +-----------------+ | | | |protocol-specific| | | | | configuration | | | | +-----------------+ | | +-----------------^--------------+ Device | Level +-----------------+--------------------+ | CLI/I2RS | | CLI/I2RS | | | | | | | +---------------+ +---------------+ | | | | | | | NE | ... | NE | | | | | | | +---------------+ +---------------+---------- Figure 1: SUPA configuration and policy mapping overview Service Management manages and programs the underlying network elements indirectly based on the abstract view of the network infrastructure. In practice, this means that Service Management can, among others, configure the underlying network as a whole rather than as a set of individual network elements. As a result, the diversity of the actual network elements in active operation is abstracted, which allows Service Management to manage and program the network in a simpler, more maintainable and efficient manner. On the other end Pentikousis & Zhang Expires September 10, 2015 [Page 4] Internet-Draft SUPA Configuration and Policy Mapping March 2015 of the spectrum, the NEs can continue their regular operation without having to become cognizant of the fact that configuration is applied at the network level. In order to bridge the gap between configuration set by Service Management and that required by the NEs, the Network Manager/ Controller has to provide a mapping mechanism which translates the configuration settings from the network level to the device level. This document considers three modules in the SUPA framework to support such a mapping mechanism, as follows. First, a network resource module maintains the resource of the infrastracture, such as topology of the network, and provides the information of the resouce to Service Management. It also provides the necessary information of each network element when mapping configuration from the network-level to device-level. Second, the service management and policy module, which is responsible for transmitging (send/receive) and process the network-level configuration. Third, the protocol-specific configuration produces the output of the mapping mechanism and is responsible for distributing the device- level configuration to the corresponding network elements. In this framework, one would expect the introduction and use of algorithms/strategies for specific network services which can automatically generate device-level configuration based on the Service Management policies/configurations. Note, however, that said algorithms and strategies are out of the scope of this document. 4.2. Mapping Procedure From the view point of Service Management: Firstly, Service Management needs some context of the underlying network, especially the infrastructure (physical or logical) of the network, before it deploys a policy/service to the network. For example, if Service Management attempts to steer traffic from one path to another, it should have the information of the existing paths first. Service Management requests this context information from Network Manager/Controller, and the information is provided with the topology model. This procedure does not have to be processed every time Service Management deploys a policy/service. Secondly, Service Management can obtain the current status of a service for reference before it deploys a new policy. In such cases, Service Management sends a "GET" request to the Network Manager/ Controller, and the Network Manager/Controller encapsulates this Pentikousis & Zhang Expires September 10, 2015 [Page 5] Internet-Draft SUPA Configuration and Policy Mapping March 2015 information with the models specified by SUPA network service models models. Thirdly, Based on the service and policy configuration, and also service/network status if neccessary, Service Management deploys the action of the policy by sending a "POST" request to the Network Manager/Controller. From the view point of Network Manager/Controller: Firstly, the Network Manager/Controller is responsible for maintaining the infrastructure information, and it provides information to Service Managements with the network resource models, such as topology information model. Secondly, once the Network Manager/Controller receives actions of a policy from Service Managements, it maps these actions to protocol- specific models. The intelligence/algorithms of how to do the mapping is implementation-specific and out of the scope of this specification, as are the protocol-specific models. Thirdly, with the protocol-specific models, the device-level configurations for heterogeneous devices can be generated and conveyed by the Network Manager/Controller using, for example, [RFC6020], [I-D.bierman-netconf-restconf], [I-D.atlas-i2rs-architecture] and CLI, to the corresponding NEs. 4.3. SUPA Mapping Example Pentikousis & Zhang Expires September 10, 2015 [Page 6] Internet-Draft SUPA Configuration and Policy Mapping March 2015 +-----------------------+ | +---------+ | | |TE Policy| | | +---------+ | | Service Management | +----------^------------+ | | NETCONF/RESTCONF | +--------------v---------------+ | | | Network Manager/Controller | | | +--------------^---- ----------+ | CLI/I2RS/NETCONF | +----------------v--------------------+ | | 192.0.2.1 192.0.2.2 +------+ +------+ +------+ | A +----------+ C +------------+ B +-----+ +-+--+-+ +------+ +---+--+ | | | 192.0.2.3 | | ++ | | | | | | +---+--+ | | | | G | +---+--+| | +---+--+ | F || | | +------+| +--+---+ +---+--+ | +-------+ D +-----------------+ E +-----+ +------+ +------+ 192.0.2.4 192.0.2.5 Figure 2: Bandwidth use optimization for DC Interconnection Figure 2 illustrates a simple example in which interoperability between Service Management and Network Manager/Controller in an inter-data center (inter-DC) environment is considered. For the purposes of this example, let us focus on the dynamic configuration of the IP path between the seven illustrated DCs, labeled A, B, C, D, E, F and G, based on the policies. First of all, we would like the IP path to be created based on certain constraints. Secondly, we would like to map it to the device-level connections. In this scenario, there are two paths from DC A to DC B. Typical IP shortest-path routing would choose path A(192.0.2.1)-C(192.0.2.3) > Pentikousis & Zhang Expires September 10, 2015 [Page 7] Internet-Draft SUPA Configuration and Policy Mapping March 2015 B(192.0.2.2). However, under certain conditions, such as, for instance, when the bandwidth utiliaztion between A and B is beyond 80 percents, the Service Management can decide that is better to steer traffic from path (A, C, B) to a new path which goes through a specific node. Figure 2 depicts the layer 3 topology of the underlying network. First, Service Management needs some information about A, B, C, D and the links between them. This information can be obtained from Network Manager/Controller, and it is listed in the fragment below. This information is derived from the Topology YANG model described in [I-D.contreras-supa-yang-network-topo]. 1111111100000000 mapping_topo ip 192.0.2.1 A physical adminUp up 1111111100000000 192.0.2.2 B physical adminUp up 1111111100000000 ... skip ... 192.0.2.3 C physical adminUp up 1111111100000000 Pentikousis & Zhang Expires September 10, 2015 [Page 8] Internet-Draft SUPA Configuration and Policy Mapping March 2015 1 A2C telink bidrectional adminUp up 192.0.2.1 192.0.2.3 1111111100000000 2000 ... skip ... 2 C2B telink bidrectional adminUp up 192.0.2.3 192.0.2.2 1111111100000000 50000 Figure 3: Information of the underlying network Secondly, Service Management defines the policy using policy policy models defined in SUPA, and then sends the steering information derived from service and policy information to Network Manager/ Controller using a protocol such as [RFC6020], and [I-D.bierman-netconf-restconf]. Figure 4 presents the policy for traffic steering: the traffic (supaflow) with destination IP address 192.0.2.11/24 needs to be steered to DC B, the new path must go through DC D. This configuration is derived from the YANG model Pentikousis & Zhang Expires September 10, 2015 [Page 9] Internet-Draft SUPA Configuration and Policy Mapping March 2015 described in [I-D.bi-supa-policy-model]. An example of the steering information is list in Figure 5, it specfies the traffic flow which will be steered, and the constrains of the new path. supa_vpn L3VPN supa_flow utilization 80 above 192.0.2.4 pass Figure 4: Example traffic steering policy Pentikousis & Zhang Expires September 10, 2015 [Page 10] Internet-Draft SUPA Configuration and Policy Mapping March 2015 supa_flow 10000 192.0.2.0 24 path_1 auto 192.0.2.1 ingress 1 192.0.2.5 transit 2 192.0.2.2 egress 3 Figure 5: Example traffic steering information Based on the steering information, the Network Manager/Controller generates a path which meets the requirements: in this example, the computed path is (A, D, E, B). Network Manager/Controller also has to configure each device on the new path, not only the devices specified by the configuration such as node D, but also the devices in the underlying network which must be reconfigured, such as node E. The topology information is also necessary when Network Manager/ Controller decides which device ought to be configured. With the assistance of other information in Network Manager/ Controller, such as topology information, service/policy Pentikousis & Zhang Expires September 10, 2015 [Page 11] Internet-Draft SUPA Configuration and Policy Mapping March 2015 configuration can be translated into protocol-specific yang models (or southbound interface) first. Taking node D as an example, the configuration expressed in the YANG model defined in [I-D.lhotka-netmod-routing-cfg]could be as follows: rtr0 Router D rt:static st0 Static routing is used for the internal network. 192.0.2.0/24 192.0.2.5 Figure 6: Example traffic steering requirements The configuration of other nodes is similar. Based on this vendor- neutral device-level configuration and the features of each NE, the NE-specific configuration can be generated. Once nodes A, C, D and E have received their respective NE-specific configurations, the device-level configuration could be deployed and then, the traffic is steered as Service Management specified. Pentikousis & Zhang Expires September 10, 2015 [Page 12] Internet-Draft SUPA Configuration and Policy Mapping March 2015 5. Security Considerations Security considerations will be discussed in an upcoming revision of this document. 6. IANA Considerations TBD 7. Acknowledgements This document has benefited comments, suggestions, and proposed text provided by Cathy Zhou and Will Liu (listed in alphabetical order). Junru Lin and Zhayiyong contributed to an earlier version of this draft. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, October 2010. 8.2. informative References [I-D.atlas-i2rs-architecture] Atlas, A., Halpern, J., Hares, S., Ward, D., and T. Nadeau, "An Architecture for the Interface to the Routing System", draft-atlas-i2rs-architecture-02 (work in progress), August 2013. [I-D.bi-supa-policy-model] Bi, J., Tadepalli, R., and M. Hayashi, "DDC Service Policy YANG Data Model", draft-bi-supa-policy-model-00 (work in progress), February 2015. [I-D.bierman-netconf-restconf] Bierman, A., Bjorklund, M., Watsen, K., and R. Fernando, "RESTCONF Protocol", draft-bierman-netconf-restconf-04 (work in progress), February 2014. Pentikousis & Zhang Expires September 10, 2015 [Page 13] Internet-Draft SUPA Configuration and Policy Mapping March 2015 [I-D.contreras-supa-yang-network-topo] Contreras, L., Qu, A., and Y. Zha, "A YANG Data Model for Network Topologies", draft-contreras-supa-yang-network- topo-02 (work in progress), January 2015. [I-D.lhotka-netmod-routing-cfg] Lhotka, L., "A YANG Data Model for Routing Configuration", draft-lhotka-netmod-routing-cfg-00 (work in progress), March 2011. [I-D.zhou-supa-framework] Zhou, C., Contreras, L., Qiong, Q., and P. Yegani, "The Framework of Shared Unified Policy Automation (SUPA)", draft-zhou-supa-framework-00 (work in progress), January 2015. Authors' Addresses Kostas Pentikousis EICT GmbH Torgauer Strasse 12-15 Berlin 10829 Germany Email: k.pentikousis@eict.de Dacheng Zhang Alibaba Chaoyang Dist Beijing 100000 P.R. China Email: Dacheng.zdc@alibaba-inc.com Pentikousis & Zhang Expires September 10, 2015 [Page 14]