Network Working Group J. Bi Internet Draft Tsinghua University Intended status: Standard Track R. Tadepalli Expires: November 2015 Wipro Limited M. Hayashi KDDI R&D Labs. Inc. May 7, 2015 DDC Service Policy YANG Data Model draft-bi-supa-policy-model-02 Abstract This document describes a YANG data model for traffic steering policies in Distributed Data Center (DDC) scenarios. The policy model is a specific data model for traffic steering using VPN technology. It helps the service management in Simplified Use of Policy Abstractions (SUPA) to model the policy (a set of constraints and rules) that defines how a VPN service is monitored by bandwidth and managed during its lifecycle. Two traffic steering applications have been provided such as traffic optimization with pass or bypass specific nodes or sites. 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), 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 Bi, et al. Expires November 7, 2015 [Page 1] Internet-Draft SUPA Policy Model May 2015 This Internet-Draft will expire on October 25, 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. 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. Conventions used in this document ............................4 3. Network Configuration Model Overview .........................4 4. Network Policy Configuration Modules .........................4 4.1. Network Policy Model ....................................5 4.2. Policy Applications in DDC services .....................7 4.2.1. Model for Traffic Steering Policy ..................9 4.2.2. Policy Based Traffic Steering Operation ...........17 5. Security Considerations .....................................17 6. IANA Considerations .........................................17 7. Contributor List ............................................17 8. Acknowledgments .............................................18 9. References ..................................................18 9.1. Normative References ...................................18 9.2. Informative References .................................18 1. Introduction In order to support the DDC service with VPN connection as well as new services, it brings new requirements for both network providers and service providers. Rapid uptake of new services requires dynamic service provisioning capabilities in the service management. This is achieved using policies that can be created by the operators once and the service management refers to these policies to infer how a given service needs to be provisioned considering the current state of the network. Bi, et al. Expires November 7, 2015 [Page 2] Internet-Draft SUPA Policy Model May 2015 In SUPA framework, network policy is a predefined rule or a set of rules that the service management use to map the service to the lower level network infrastructures. More specifically, based on different level of policy abstractions, there are a generic policy model on top and ECA policy, intent policy to handle service management. Note that, the generic policy is use case independent while the ECA policy has to be defined with objects from service model. In this way, an ECA policy defines: An event or a set of events that trigger the evaluation of policy: This is the trigger for the service management application to evaluate if a policy needs to be applied. For example a user action to provision a new VPN service can be an event. A set of conditions that need to be satisfied for the policy to be applicable: This enables service management to select the right policy by validating the conditions against the current network state. A set of actions that should be triggered as part of the policy execution: This enables the service management to provision the service. Meanwhile, DDC service which is mainly relied on VPN [RFC4110] needs policy based management and controlling capability from the service management systems to facilitate the service deployment both inter data centers and within data center. This document introduces YANG [RFC6020] [RFC6021] data models for SUPA configuration. Such models can facilitate the standardization for the interface of SUPA, as they are compatible to a variety of protocols such as NETCONF [RFC6241] and [RESTCONF]. Please note that in the context of SUPA, the term "application" refers to an operational and management applications employed, and possibly implemented, by an operator. The policy model is based on the first example - DDC services. With respect to the scope, defining an information model for the policy exchange between the policy manager and policy agent and a corresponding data model based on yang to support specific DDC service use case is initial goal of this document. The protocol specific aspects are deferred to respective implementations. Also certain foundational concepts of the model are intentionally left open to enable future extension. Here the traffic steering policy in DDC use case provides a concrete example for a specific network technology and service, as what constitutes a policy could itself vary depending on the context where it is used, e.g. there could Bi, et al. Expires November 7, 2015 [Page 3] Internet-Draft SUPA Policy Model May 2015 be tenant specific policies, site specific, network domain specific etc. 2. Conventions used in this document 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]. In this document, these words will appear with that interpretation only when in ALL CAPS. Lower case uses of these words are not to be interpreted as carrying [RFC2119] significance. 3. Network Configuration Model Overview Figure 1 illustrates the network configuration model which contains several modules for specific services such as VPN management. Basically, service model is to define the creation and configuration of the VPN service, while the policy model is more focused on the adjustment or optimization of the flow path during the lifecycle of the VPN service based on the predefined policy. +------------------------------------------+ | Service Management | | | | +------------+ +------------+ | | | Service | | Policy | | | | Data Model | | Data Model | | | +------------+ +------------+ | +------------------------------------------+ Figure 1: Overview of configuration model structure 4. Network Policy Configuration Modules In this section, a policy model is defined with an application for traffic steering between data centers are provided to illustrate how to use the policy model. The policy model and policy configuration are based on a set of specific network services and the framework of SUPA [SUPA-framework]. On the other hand, the policy model should be working on the orchestration level which is above network element and below OSS level based on the YANG model classification in [draft-bogdanovic-netmod-yang-model classification-02] Bi, et al. Expires November 7, 2015 [Page 4] Internet-Draft SUPA Policy Model May 2015 4.1. Network Policy Model A Policy Rule can be expressed in different ways and its content is separated from its representation. Therefore, this object takes different forms, depending on the level of abstraction desired. For example, an event-condition-action policy is expressed as a tuple of three statements. Within SUPA scope, the service management system takes the E-C-A fashioned policy model to handle the VPN management in the data center use case to improve bandwidth utilization and facilitate service deployment. Event: a significant occurrence in time that triggers the evaluation of the condition of the policy rule Condition: a set of tests that determine if the actions of the policy rule should be executed or not Action: a set of operations that should be performed if the condition is true Note that event, condition, and action can each be made up of Boolean clauses +--------------------------+ | PolicyRuleMetaData | +------------+-------------+ | +--------+------+ | PolicyRule | +-----------+---+ | ------+--------------- | | +------+-------+ +------+---------+ | ECA Policy | | Intent Policy | | Model | | Model | +-+------+--+--+ +----------------+ | | | -------- | -------------- | | | +----+----+ +----+------+ +----+----+ | Event | | Condition | | Action | +---------+ +-----------+ +---------+ Figure 2: Overview of ECA policy model Bi, et al. Expires November 7, 2015 [Page 5] Internet-Draft SUPA Policy Model May 2015 module: ietf-supa-policy +--rw supa-policy +--rw supa-policy-name? string +--rw supa-policy-type? enumeration +--rw applicable-service-type? enumeration +--rw supa-policy-priority? uint8 +--rw supa-policy-validity-period | +--rw start? yang:date-and-time | +--rw end? yang:date-and-time | +--rw duration? uint32 | +--rw periodicity? enumeration +--rw supa-policy-metadata? uint32 +--rw supa-policy-atomic | +--rw supa-ECA-policy-rule | +--rw policy-rule-name? string | +--rw policy-rule-type? enumeration | +--rw policy-rule-deploy-status? enumeration | +--rw policy-rule-exec-status? enumeration | +--rw has-policy-events? boolean | +--rw has-policy-conditions? boolean | +--rw has-policy-actions? boolean +--rw supa-policy-statement +--rw event-clause | +--rw policy-variable? string +--rw condition-clause | +--rw policy-variable? string | +--rw policy-operator? string | +--rw policy-value? string +--rw action-clause +--rw policy-action? string As shown in the YANG tree of the ECA policy model, it is basically following the generic policy model from [draft-strassner-supa- generic-policy-model-00] to define the policy model structure of the ECA policy. The top level class "supa-policy": it has some basic attributes such as name and type. "applicable-service-type" is related the service which define the service being supported by the policy model. "supa-policy-priority" and "supa-policy-validity-period" define when and how often the policy will be executed, which is designed to handle some time based management policy. E.g. "perform LOAD BALANCING at 2am every Thursday" such policy will Bi, et al. Expires November 7, 2015 [Page 6] Internet-Draft SUPA Policy Model May 2015 introduce the timing issue. And finally, "supa-policy-atomic" and "supa-policy-statement" are two major components of the policy model. "supa-policy-atomic" is a type of Policy Container which here contains the ECA model policy model. In addition to the "name" and "type" attributes, "policy-rule-deploy-status" and "policy-rule- exec-status" describe the deploy status and execute status of the ECA policy respectively. The most important components are "has- policy-events", "has-policy-conditions" and "has-policy-actions" which denote whether the policy rule has an "event", "condition" and "action" clause. Note that each definition of the clause is in the "supa-policy-statement" "supa-policy-statement" separates the representation of a SUPA Policy from its implementation. Its subclasses enable the developer to define a SUPA Policy as either a completely reusable set of SUPA Policy objects or as an efficient encoding made up of attributes. "event-clause" defines the policy event the system monitors. If the predefined event is evaluated as TRUE, then the condition will be evaluated. "condition-clause" defines the condition to trigger the corresponding action. It should be a three-tuple clause with {PolicyVariable, PolicyOperator, PolicyValue}. E.g., in "bandwidth utilization > 80% ", "bandwidth utilization" is the variable, ">" is the operator and "80%" is the value. "action-clause" defines the consequence action as the "condition-clause" is evaluated as TRUE. 4.2. Policy Applications in DDC services More specifically, for the networking system an E-C-A based policy model can cover use cases as follows: Network Policy -event: -- bandwidth usage -- port N status -- TTL value -condition : -- bandwidth usage > x -- port N is up -- TTL < y -action: -- adjust flow -- use backup link -- retry Bi, et al. Expires November 7, 2015 [Page 7] Internet-Draft SUPA Policy Model May 2015 For the first one, if the bandwidth usage of a contain link is above threshold, the flow will be adjusted. The event is the link bandwidth usage, the condition is bandwidth usage above the x and the action is to adjust the flow. The second one is, if the port N is up, the system will use backup link. The third one is, if the TTL is below y, retry. The following describes SUPA policy model designed for DDC services use case [SUPA-DDC] to do the traffic steering among DCs. [SUPA-DDC] took a large-scale Internet Data Center (IDC) operator as an example to describe what SUPA needs to do in VPN-based traffic steering. Here the ECA policy model only focus on the policy based traffic steering application. The traffic steering policy is used in dynamical link configuration in DDC services [SUPA-DDC]. The service management can dynamically adjust the traffic flow in the links based on traffic steering policy. The policy model specifies some high level requirements to the links, like routing strategy. For example in this specific traffic steering policy model, if the link bandwidth usage is above certain threshold, the monitored flow will be forced to routed to the third place to bypass the overloaded node or site. Module "ietf-supa-policy" defines E-C-A based policy model to describe the policy management in DDC service. In effect, the module can be expanded with more operation services for DDC services. The ECA model here with the DDC traffic steering application is an instantiation and inheritance of the generic policy model with ECA policy rule. Bi, et al. Expires November 7, 2015 [Page 8] Internet-Draft SUPA Policy Model May 2015 module: ietf-supa-policy +--rw supa-ddc-policy +--rw adjust-flow-path-policy +--rw adjust-flow-path* [vpn-name] +--rw vpn-name string +--rw vpn-type? enumeration +--rw flow-name? string +--rw traffic-steering-policy-rule +--rw policy-rule-deploy-status? enumeration +--rw policy-rule-exec-status? enumeration +--rw policy-event | +--rw bandwidth? string +--rw policy-condition | +--rw bandwidth-utilization? enumeration | +--rw operator? enumeration | +--rw value? uint32 +--rw policy-action-adjust-path +--rw constraint-nodes | +--rw constraint-node* [nodeId] | +--rw nodeId string | +--ro constraint-type? enumeration | +--rw sequence? uint32 +--rw constraint-sites +--rw constraint-site* [siteId] +--rw siteId string +--ro constraint-type? enumeration +--rw sequence? uint32 4.2.1. Model for Traffic Steering Policy module ietf-supa-policy { namespace "urn:ietf:params:xml:ns:yang:ietf-supa-policy"; // replace with IANA namespace when assigned prefix policy; import ietf-inet-types { prefix inet; } organization "IETF"; contact "Editor: Jun Bi junbi@tsinghua.edu.cn"; description "This YANG module defines a component that describing Bi, et al. Expires November 7, 2015 [Page 9] Internet-Draft SUPA Policy Model May 2015 the ddc policy model for monitoring and optimizing tenant's DC (data center) services that are deployed between multiple data centers. Terms and Acronyms DDC: Distributed Data Center L2VPN: Layer 2 Virtual Private Network L3VPN: Layer 3 Virtual Private Network"; revision 2015-05-06 { description "Revised revision."; reference " Network Policy YANG Data Model "; } container supa-ddc-policy{ description "Distributed Data Center Service Operation Data"; container adjust-flow-path-policy { description "To improve the bandwidth utilization (or reduce the cost, or other reason) and mitigate traffic congestion,management system/ application requires controller to adjust certain flows to pass/bypass certain nodes(or links), when, e.g., bandwidth utilization exceed certain threshold. Vpn name, vpn type, adjusted flow and specified nodes (that the flow should pass) should be told to controller. So that the controller can configure the network elements to change the VRF table and routing table. If the link bandwidth usage is above certain threshold, the monitored flow will be forced to routed to the third place to bypass the overloaded node or site."; list adjust-flow-path { key "vpn-name"; description "The list of VPN and flow that need to be adjusted in specific paths. So as to optimize traffic in the links that are between data centers."; leaf vpn-name { type string; mandatory true; description "Indicates the name of VPN that the adjusted flow belongs to. A VPN instance is identified by vpn-name. It should be one of the created VPN instance names"; Bi, et al. Expires November 7, 2015 [Page 10] Internet-Draft SUPA Policy Model May 2015 } leaf vpn-type { type enumeration { enum L2VPN { description "L2VPN"; } enum L3VPN { description "L3VPN"; } } description "Indicates the type of VPN instance that the adjusted flow belongs to. L2VPN or L3VPN"; } leaf flow-name { type string; description "The name of the adjusted flow. So as to tell the Controller which flow should be adjusted"; } container traffic-steering-policy-rule{ leaf policy-rule-deploy-status { description "It defines the current deployment status of this policy rule. Both operational and test mode values are included in its definition."; type enumeration { enum 0{ description "undefined"; } enum 1{ description "deployed and enabled"; } enum 2{ description "deployed and in test"; } enum 3{ description "deployed but not enabled"; } enum 4{ description "ready to be deployed"; } enum 5{ description "not deployed"; } } } Bi, et al. Expires November 7, 2015 [Page 11] Internet-Draft SUPA Policy Model May 2015 leaf policy-rule-exec-status { description "It defines the current execution status of this policy rule. Both operational and test mode values are included in its definition"; type enumeration { enum 0{ description "undefined"; } enum 1{ description "executed and SUCEEDED (operational mode)"; } enum 2{ description "executed and FAILED (operational mode)"; } enum 3{ description "currently executing (operational mode)"; } enum 4{ description "executed and SUCEEDED (test mode)"; } enum 5{ description "executed and FAILED (test mode)"; } enum 6{ description "currently executing (test mode)"; } } } container policy-event{ description "The Policy defines an ECA type policy model for the service management of traffic optimization between DCs. If the predefined event is monitored, then the controller will evaluate if the condition is matched. If the condition is matched, the corresponding action will be performed. Here in this case, bandwidth is the 'event' to monitor in the traffic steering policy case"; leaf bandwidth { type string; } } container policy-condition { Bi, et al. Expires November 7, 2015 [Page 12] Internet-Draft SUPA Policy Model May 2015 description "There are several types of 'condition' match, here it is above/below"; leaf bandwidth-utilization { type enumeration { enum utilization { description "In this case, the bandwidth utilization is the 'event'. The controller will monitor the bandwidth utilization if it is above the threshold which is the link utilization ratio, 0-100%"; } enum BW { description " In this case, the bandwidth usage is the 'event'. The controller will monitor the bandwidth usage if it is above the threshold which is bandwidth value, 2G,10G e.g."; } } } leaf operator{ type enumeration { enum above { description "If the value of the monitored event is above the threshold, do the action. E.g., in this case, if the bandwidth utilization is above 70%, 'above' is the 'match-type' here."; } enum below { description "If the value of the monitored event is below the threshold, do the action. E.g., in this case, if the bandwidth usage is below 2Gb, 'below' is the 'match-type' here."; } } } leaf value { description "The target value of the monitored 'event' or the threshold to trigger the action. E.g., in this case, if the bandwidth utilization is above 70%, '70%' is the 'value' here. If the bandwidth usage is above 2Gb, here '2Gb' is the 'value' here"; type uint32; } } container policy-action-adjust-path { Bi, et al. Expires November 7, 2015 [Page 13] Internet-Draft SUPA Policy Model May 2015 description "This is the corresponding 'action' when the condition has been triggered. E.g., if the link occupied ratio is above 70%, adjust the path of the flow. Here the 'adjust-path' is the action of the ECA policy. If the 'event' is monitored, and the 'condition' is triggered, the corresponding 'action', rerouted the flow path, will be performed."; container constraint-nodes { description "The generated 'action' of the ECA policy. It is a description of the constraints on the nodes those need to be adjusted. Here the 'action' only describe the constraint not the real operation. And then, the controller will compute a new route based on the constraint. More specifically, the constraint-nodes are a set of nodes that specify the constraints by the up-level. Each node in the list will be passed/bypassed when computing the new route."; list constraint-node { max-elements unbounded; min-elements 0; description "There can be a set of nodes to be constrained. Each node in the list will be passed/ bypassed when computing the new route."; key nodeId; description " List of nodes that the adjusted flow needs to pass or bypass so as to adjust the flow path between data centers. E.g. if the event and condition has been triggered that the vpn flow will be adjusted. The constraint-nodes specify how to adjust the flow and which nodes will be adjusted. Each node in the list will be told to controller to pass/bypass when computing the new route."; leaf nodeId { description "The node needs to be constrained that describe which nodes will be adjusted in the path. The node ID is the identifier of the node that the controller will take into account when computing the new route."; config true; type string { length "0..64"; pattern "([^?]*)"; } } leaf constraint-type { description "The node can be bypassed or passed."; config false; Bi, et al. Expires November 7, 2015 [Page 14] Internet-Draft SUPA Policy Model May 2015 type enumeration { enum bypass { value 0; description "The node will be bypassed. E.g., if the corresponding action of the ECA policy is to bypass the busy node 1, 2 and 3, then the node-list will be nodeId: 1, 2 and 3, while the'constraint-type' of each node is 'bypass' which denote all these nodes should be bypassed when computing the new route. Then the controller will compute the new route based on the constraint to compute a new path without node 1, 2 and 3."; } enum pass { value 1; description "The node will be passed. E.g., if the corresponding action of the ECA policy is to pass the light loaded nodes 1, 2 and 3, then the node-list will be nodeId: 1, 2 and 3, while the 'constraint-type' of each node is 'pass' which denote all these nodes should be passed when computing the new route. Then the controller will compute the new route based on the constraint to compute a new path without node 1, 2 and 3."; } } } leaf sequence { description "Constraint node sequence. The corresponding action can also specify the sequence of the node list that should be passed/bypassed. E.g., if the 'action' is to adjust the flow to a new path with node 1, 2 and 3, while the pass the node 1 first, then 3, finally 2. Here the sequence of the node-list will be 1-3-2. Then the controller will compute the new path based on the sequence."; config true; default 1; type uint32 { range "0..128"; } } } } container constraint-sites { list constraint-site { max-elements unbounded; min-elements 0; description "."; key siteId; Bi, et al. Expires November 7, 2015 [Page 15] Internet-Draft SUPA Policy Model May 2015 description " List of sites that the adjusted flow needs to pass or bypass So as to adjust the flow path between data centers. The site can be a group of nodes at different granularities for example data centers."; description " List of sites that the adjusted flow needs to pass or bypass So as to adjust the flow path between data centers."; leaf siteId { description "The site needs to be adjusted in the flow path. The site"; config true; type string { length "0..64"; pattern "([^?]*)"; } } leaf constraint-type { description "The constraint type of the site to specify whether the node site will be passed or bypassed"; config false; type enumeration { enum bypass { value 0; description "The site will be bypassed"; } enum pass { value 1; description "The site will be passed"; } } } leaf sequence { description "constraint site sequence"; config true; default 1; type uint32 { range "0..128"; } } } } } Bi, et al. Expires November 7, 2015 [Page 16] Internet-Draft SUPA Policy Model May 2015 } } } } } 4.2.2. Policy Based Traffic Steering Operation The associated action generated by the ECA model is sent to the controller such as the list of constraint nodes which denotes the constraint of the adjusted flow path. E.g. the node C will be bypassed. Based on the steering information, the Network Manager/Controller generates a path which meets the requirements: e.g., 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. 5. Security Considerations TBD 6. IANA Considerations This document has no actions for IANA. 7. Contributor List Andy Bierman YumaWorks, Inc. Email: andy@yumaworks.com Bi, et al. Expires November 7, 2015 [Page 17] Internet-Draft SUPA Policy Model May 2015 8. Acknowledgments This document has benefited from reviews, suggestions, comments and proposed text provided by the following members, listed in alphabetical order: Jing Huang, Junru Lin, Felix Lu, Juergen Schoenwaelder, Yiyong Zha, and Min Zha. 9. References 9.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. [RFC6021] Schoenwaelder, J., "Common YANG Data Types", RFC 6021, October 2010. [RFC3272] Awduche, D., Chiu, A., Elwalid, A., Widjaja, I., and X. Xiao, "Overview and Principles of Internet Traffic Engineering", RFC 3272, May 2002. 9.2. Informative References [SUPA-framework] C. Zhou, L. M. Contreras, Q. Sun, and P. Yegani, " The Framework of Shared Unified Policy Automation (SUPA) ", IETF Internet draft, draft-zhou-supa-framework, January 2015. [SUPA-problem-statement] G. Karagiannis, Q. Sun, Luis M. Contreras, P. Yegani, and JF Tremblay, "Problem Statement for Shared Unified Policy Automation (SUPA)", IETF Internet draft, draft-karagiannis- supa-problem-statement, January 2015. [SUPA-DDC] Y. Cheng,and JF. Tremblay, "Use Cases for Distributed Data Center Applications in SUPA", IETF Internet draft, draft- cheng-supa-ddc-use-cases, January 2015. [RESTCONF] Bierman, A., Bjorklund, M., Watsen, K., and R. Fernando, "RESTCONF Protocol", draft-ietf-netconf-restconf (work in progress), July 2014. Bi, et al. Expires November 7, 2015 [Page 18] Internet-Draft SUPA Policy Model May 2015 [POLICY MODEL] Z. Wang, L. Dunbar, Q. Wu, "Network Policy YANG Data Model" draft-wang-netmod-yang-policy-dm, January 2015. Authors' Addresses Jun Bi Tsinghua University Network Research Center, Tsinghua University Beijing 100084, China Email: junbi@tsinghua.edu.cn Raghavendra Tadepalli Wipro Limited Email: raghav.rao@wipro.com Michiaki Hayashi KDDI R&D Labs. Inc. 2-1-15 Ohara, Fujimino, Saitama, Japan. 356-8502 Email: mc-hayashi@kddilabs.jp Bi, et al. Expires November 7, 2015 [Page 19]