Internet Working Group K. Pentikousis, Ed. Internet Draft EICT Intended status: Informational Junru Lin Expires: March 27, 2015 Yiyong Zha Huawei Technologies September 23, 2014 SUPA Configuration and Policy Mapping draft-pentikousis-supa-mapping-00 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 devices. This document describes guidelines for mapping configuration and policy into device-level configuration. The SUPA framework overview and primary procedures of mapping are proposed. Moreover, an exemplary mapping scenario is provided to illustrate the mechanism involved. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on March 27, 2014. Pentikousis, et al. Expires March 27, 2015 [Page 1] Internet-Draft SUPA Configuration and Policy Mapping 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 .............................................. 3 3. Configuration and Policy Mapping.......................... 3 3.1. Overview .............................................. 4 3.2. Mapping Procedure...................................... 5 3.3. SUPA Mapping Example................................... 6 4. Security Considerations.................................. 10 5. IANA Considerations...................................... 10 6. References .............................................. 10 6.1. Normative References.................................. 10 6.2. Informative References................................ 11 7. Acknowledgements ........................................ 11 1. Introduction As the underlying network infrastructure grows, and new services and traffic are rapidly increased, it becomes significantly more challenging than in the past to maintain the network and deploy new services. Configuration automation can provide significant benefits in deployment agility. Shared Unified Policy Automation (SUPA) [draft-zhou-supa-architecture-00] attempts to achieve this 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 model of various application services and functions allow the network operators to manipulate the network infrastructure as a whole rather than individual devices. Well- designed abstractions are able to provide a wide range of granularity Pentikousis, et al. Expires March 27, 2015 [Page 2] Internet-Draft SUPA Configuration and Policy Mapping September 2014 for various applications needs, from the lower-level physical network to high-level application 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 the Application-Based Policy Decision (ABPD) block, an entity used between the network services and the network elements to provide and maintain the application-based policies. ABPD 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 ABPD to help ABPD to map the classified application based models, which include the classified application based policies, into specific network management policies, i.e., device-level configuration models, which are used by the communication network. 2. Terminology This document uses the following terms: Network element: a physical or virtual entity that can be locally managed and operated. Network service system (NSS): enhanced Operational Support System (OSS) which runs services that enable a provider to monitor, control, analyze and manage the services in a communication network. SUPA: Shared Unified Policy Automation 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 [RFC2119]. 3. 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 network service systems. Pentikousis, et al. Expires March 27, 2015 [Page 3] Internet-Draft SUPA Configuration and Policy Mapping September 2014 3.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) network service systems, ii) a network management & control system and iii) network elements. +-------------------------+ +-------------------------+ --- | +-----------------+ | | +-----------------+ | | | | Network Service | | | | Network Service | | | | +-----------------+ | | +-----------------+ | | | | Network Level | ... | | | Network Level | ... | | | | Configuration | | | | Configuration | | | | +-----------------+ | ... | +-----------------+ | | | | | | | | | | | | | Network Service | | Network Service | | | System | | System | | +----------^--------------+ +----------^--------------+ | | | Network +-----------------+-----------------+ Level | NETCONF/RESTCONF | +--------------v-----------------+ | | +--------------+| | | +------------+ | || | | | Topology | |Policy/ || | | +------------+ |Configuration || | | +--------------+| | Network management & +-----------------+ | | control systems | | Mapping | +------------------- | +-----------------+ | | | +---------------------------+ | | | | Device-level Configuration| | | | +---------------------------+ | | +-------------------^------------+ Device | Level +-------------------+-----------------+ | CLI/I2RS/ | CLI/I2RS/ | | NETCONF/RESTCONF| NETCONF/RESTCONF | | | | | +-------------v---------------+ +------------v---------+ | | | | | | | | ... | | | | Network Element | | Network Element | | +-----------------------------+ +----------------------+---- Figure 1: SUPA configuration and policy mapping overview Pentikousis, et al. Expires March 27, 2015 [Page 4] Internet-Draft SUPA Configuration and Policy Mapping September 2014 A network service system (NSS) manages and programs the underlying network elements indirectly based on the abstract view of the network infrastructure. In practice, this means that the network service systems 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 the NSS to manage and program the network in a simpler, more maintainable and efficient way. On the other end of the spectrum, the network elements can continue 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 from the network service systems and network elements, the network management and control system has to provide a mapping mechanism which translates the configuration settings from network level to the device level. This document considers three modules in the network management and control system to support such a mapping mechanism, as follows. First, a topology module maintains the topology of the network infrastructure and provides topology information in the specific network layer as the network service expects. It also provides the necessary information of each network element when mapping configuration from the network-level to device-level. Second, the application/policy configuration module receives the network-level configuration and acts as the primary input of the mapping mechanism. Third, the device 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 NSS policies/configurations. Note, however, that said algorithms/strategies are out of the scope of this document. 3.2. Mapping Procedure Firstly, the network service system acquires the topology information from the topology module in the network management & control system if it needs some knowledge of the underlying network to specify policies/configurations. Then, the network service system posts the policies/configurations to the network management & control system. Secondly, in the network management & control system, algorithms/strategies for specific network services generate a series Pentikousis, et al. Expires March 27, 2015 [Page 5] Internet-Draft SUPA Configuration and Policy Mapping September 2014 of detailed configurations from the network level policy/configuration, and decide which network element the configurations need to be deployed based on the topology module. From the topology module, the interfaces supported by a specific network element, e.g. [RFC6020], [RESTCONF], [I-D.ietf-i2rs-architecture] or CLI (Command Line Interface), can be confirmed. Then, the device configuration module distributes the detailed configuration to the corresponding network elements, according to the mechanisms that the network elements interfaces support. Finally, the network elements receive and use the device-level configurations. 3.3. SUPA Mapping Example Figure 2 illustrates a simple example in which interoperability between SUPA and IP traffic engineering (IPTE) 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, ..., 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(1.1.1.1)->B(2.2.2.2). However, under certain conditions, such as, for instance, when the bandwidth between A and B is not suitable, the NSS can decide that is better to steer traffic from path (A, B) to path (A, C, B). Figure 2 depicts the layer 3 topology of the underlying network. The network service system attempts to steer traffic from path (A, B) to path (A, ..., C, ..., B). At first, NSS needs some information about A, B and C to determine the new path in the configuration. This information can be obtained from the topology information model. Topology for a network-level configuration loses some device-level details for the sake of conciseness; it also can be represented as a different network layer as the application expects. Secondly, the network service system sends the information to the network management and control system using a protocol such as NETCONF or RESTCONF. +-----------------------+ | +-----------------+ | | | IPTE Service | | | +-----------------+ | | | IPTE | | | | Configuration | | Pentikousis, et al. Expires March 27, 2015 [Page 6] Internet-Draft SUPA Configuration and Policy Mapping September 2014 | +-----------------+ | | NSS | +----------^------------+ | | NETCONF/RESTCONF | +--------------v---------------+ | | | | | Network management | | control systems | | | | | | | +--------------^---- ----------+ | CLI/I2RS | +----------------v--------------------+ | | 1.1.1.1 2.2.2.2 +------+ +------+ | A +------------------------------+ B +-----+ +-+--+-+ +---.--+ | | | | | ++ | | | | +---+ | +---+--+ | | | | G | +---+--+ | | +---+--+ | F | | | | +------+ | +------+ +---+--+ | | +----+ C +-------+ E +-----+ | | +------+ +------+ | | 3.3.3.3 5.5.5.5 +--+---+ | | D +----+ +------+ 4.4.4.4 Figure 2: Bandwidth usage optimization for DC Interconnection Figure 3 presents the requirements for traffic steering: the traffic needs to be steered to DC B whose IP address is 2.2.2.2/24, the new path must start at DC A, terminate at DC B and go through DC C, and the available bandwidth of the new path must more than 10 Mb/s. This configuration is derived from the IP TE YANG model described in [draft-xxx-supa-configuration-model-00]. Pentikousis, et al. Expires March 27, 2015 [Page 7] Internet-Draft SUPA Configuration and Policy Mapping September 2014 ddc_flow 10000 2.2.2.2 32 path_1 auto 1.1.1.1 ingress 1 3.3.3.3 transit 2 2.2.2.2 egress 3 Figure 3: Example traffic steering requirements Based on this configuration, the network management and control system has to configure each device on the new path-path2, not only the devices specified by the configuration such as, B, C, but also the devices in the underlying network which must be reconfigured, such as in D and E. The topology information is also necessary to decide which device ought to be configured. In this example, the network-level configuration cannot be deployed in the devices directly, it needs to be mapped or translated to device-level configuration. For example, in this scenario, the networking device (ingress/egress router) of node A, B, C, D, and E Pentikousis, et al. Expires March 27, 2015 [Page 8] Internet-Draft SUPA Configuration and Policy Mapping September 2014 support configuration with ACL using CLI. In this instance the configuration of each node is: node A: next hop of packet from 1.1.1.1 to 2.2.2.2/24 is node D: { system view acl number 2002 rule permit ip source 1.1.1.1 0.0.0.0 destination 2.2.2.0 0.0.0.255 quite route policy ddc-example permit node 10 if-match acl 2002 apply ip-address next-hop 4.4.4.4 quit } Node D: next hop of packet from 1.1.1.1 to 2.2.2.2/24 is node C: { system view acl number 2002 rule permit ip source 1.1.1.1 0.0.0.0 destination 2.2.2.0 0.0.0.255 quite route policy ddc-example permit node 10 if-match acl 2002 apply ip-address next-hop 3.3.3.3 quit } Node C: next hop of packet from 1.1.1.1 to 2.2.2.2/24 is node E: { system view acl number 2002 rule permit ip source 1.1.1.1 0.0.0.0 destination 2.2.2.0 0.0.0.255 quite route policy ddc-example permit node 10 if-match acl 2002 apply ip-address next-hop 5.5.5.5 quit } Node E: next hop of packet from 1.1.1.1 to 2.2.2.2/24 is node B: Pentikousis, et al. Expires March 27, 2015 [Page 9] Internet-Draft SUPA Configuration and Policy Mapping September 2014 { system view acl number 2002 rule permit ip source 1.1.1.1 0.0.0.0 destination 2.2.2.0 0.0.0.255 quite route policy ddc-example permit node 10 if-match acl 2002 apply ip-address next-hop 2.2.2.2 quit } If the nodes support an I2RS interface, then an I2RS client [I- D.ietf-i2rs-architecture] is introduced in the "Device Configuration" module. This module will communicate with a number of routers using an asynchronous protocol, sets or collects state to/from those routers. When configuring node A, B, C, D and E, the network management & control system only needs to send the configurations to the I2RS client. The configuration of node A and node C set rules to steer traffic, whose source IP is 1.1.1.1 and destination IP is 2.2.2.2/24, to node D and node E respectively. The detailed contents and format can be found in [I-D.hares-i2rs-info-model-policy]. Once nodes A, B, C, D and E have received their respective configurations (from the I2RS client or via CLI), the device-level configuration is deployed and the traffic is steered as the network service system expects. 4. Security Considerations Security considerations will be discussed in an upcoming revision of this document. 5. IANA Considerations TBD 6. References 6.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Pentikousis, et al. Expires March 27, 2015 [Page 10] Internet-Draft SUPA Configuration and Policy Mapping September 2014 6.2. Informative References [draft-zaalouk-supa-configuration-model-00] Adel Zaalouk, K.Pentikousis, W. Liu, "YANG Data Model for Configuration of Shared Unified Policy Automation (SUPA)" (work in progress), September 2014. [draft-zhou-supa-architecture-00] C. Zhou, T.Tsou, D.Lopez, G.Karagiannis and Q.Sun "The Architecture for Shared Unified Policy Automation (SUPA)", draft-zhou-supa-architecture-00, (work in progress), September 2014. [I-D.ietf-i2rs-architecture] Atlas, A., Halpern, J., Hares, S., Ward, D., and T. Nadeau, "An Architecture for the Interface to the RoutingSystem", draft-ietf-i2rs-architecture-05 (work in progress), July 2014. [I-D.hares-i2rs-info-model-policy] Hares, S. and W. Wu, "An Information Model for Networkpolicy", draft-hares-i2rs-info-model- policy-03 (work in progress), July 2014. [RESTCONF] Bierman, A., Bjorklund, M., Watsen, K., and R. Fernando, "RESTCONF Protocol", draft-ietf-netconf-restconf-01 (work in progress), July 2014. [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, October 2010. 7. Acknowledgements This document has benefited comments, suggestions, and proposed text provided by Cathy Zhou and Will Liu (listed in alphabetical order). Pentikousis, et al. Expires March 27, 2015 [Page 11] Internet-Draft SUPA Configuration and Policy Mapping September 2014 Authors' Addresses Kostas Pentikousis (editor) EICT GmbH Torgauer Strasse 12-15 Berlin 10829 Germany Email: k.pentikousis@eict.de Junru Lin Huawei Technologies Bantian, Longgang District Shenzhen 518129 P.R. China Email: linjunru@huawei.com Yiyong Zha Huawei Technologies Bantian, Longgang District Shenzhen 518129 P.R. China Email: zhayiyong@huawei.com Pentikousis, et al. Expires March 27, 2015 [Page 12]