Network Working Group M. Chen Internet Draft BBIX, Inc. Intended status: Standard Track L.Contreras Expires: April 16, 2016 Telefonica I+D M. Fukushima KDDI R&D Labs. Inc. October 16, 2015 ECA Policy YANG Data Model draft-chen-supa-eca-data-model-04 Abstract This document describes a YANG data model for SUPA (Simplified Use of Policy Abstractions) ECA (Event-Condition-Action) policies using policy abstractions defined in [I-D. strassner-supa-generic- policy-info-model]. The EPDM (ECA policy data model) is refined from SGPIM (SUPA Generic Policy Information Model)and EPRIM (ECA Policy Rule Information Model) to be applied to deliver various management policies for controlling managed entities throughout the service development and deployment lifecycle. The generic ECA policy data model could be augmented by additional YANG data modules modeling and configuring policy-related protocols and functions. Reusability as the major advantage of this approach can be realized. The policy data model described in this document provides common building blocks for such extensions. 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." Chen, et al. Expires April 16 2016 [Page 1] Internet-Draft SUPA ECA Policy Data Model October 2015 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 April 16, 2016. 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 .................................................3 2. Conventions used in this document ............................4 2.1. Tree Diagrams ...........................................4 3. SUPA Policy Modules Top Level Design .........................5 3.1. supa-policy-target Design for ECA policy data model .....6 3.2. ECA Policy Data Model Design ............................6 3.2.1. supa-ECA-component sub class .......................7 3.3. supa-policy-statement Design for ECA policy data model ..8 3.3.1. supa-entity sub class ..............................8 3.3.2. supa-script sub class ..............................9 3.4. event-list sub class ....................................9 3.5. condition-list sub class ...............................10 3.6. action-list sub class ..................................10 4. Generic ECA Policy Data Model ...............................11 4.1. Abstract Generic ECA Policy Data Model Hierarchy .......11 4.2. SUPA Generic ECA Policy Data Model in YANG Module ......13 5. ECA Policy Data Model Example ...............................19 5.1. Redefine the supa-policy-target ........................20 5.2. Define the supa-ECA-component ..........................21 5.3. Define Event, Condition and Action clause ..............21 6. Specific ECA Policy Data Model for service flow policy ......23 Chen, et al. Expires April 16, 2016 [Page 2] Internet-Draft SUPA ECA Policy Data Model October 2015 6.1. SUPA specific ECA Policy Data Model in YANG Module .....23 7. Security Considerations .....................................25 8. IANA Considerations .........................................25 9. Contributor List ............................................25 10. Acknowledgments ............................................26 11. References .................................................26 11.1. Normative References ..................................26 11.2. Informative References ................................26 1. Introduction As defined in [I-D. strassner-supa-generic-policy-info-model], policies either be used in a stand-alone policy rule or aggregated into policy composite to perform more elaborate functions. The SUPA policy is tree-structured and can be embedded into hierarchal model. In SUPA framework, the EPRIM is a set of subclasses that specialize the concepts defined in the SGPIM for representing the components of a Policy that uses ECA semantics. Note that, the information model is independent of data repository, data definition language, query language, implementation language, and protocol. While the ECA policy has to be defined with data repository, data definition language, query language, implementation language, and protocol. In this way, an ECA policy data model 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. 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 Chen, et al. Expires April 16, 2016 [Page 3] Internet-Draft SUPA ECA Policy Data Model October 2015 operational and management applications employed, and possibly implemented, by an operator. 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. The protocol specific aspects are deferred to respective implementations. Also certain foundational concepts of the model are intentionally left open to enable future extension. 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. 2.1. Tree Diagrams A simplified graphical representation of the data model is used in this document. The meaning of the symbols in these diagrams is as follows: -Each node is printed as: is one of: + for current x for deprecated o for obsolete is one of: rw for Read/Write ro for ReadOnly -x for rpcs (remote procedure calls) -n for notifications is the name of the node -If the node is augmented into the tree from another module, its name is printed as :. Chen, et al. Expires April 16, 2016 [Page 4] Internet-Draft SUPA ECA Policy Data Model October 2015 is one of: ? for an optional leaf or choice ! for a presence container * for a leaf-list or list [] for the keys of a particular list Figure 1: Symbols Used in Diagrams in this Document 3. SUPA Policy Modules Top Level Design In this section, a generic ECA policy data model is defined with SGPIM to specify the top level sub-class. The SUPA policy is constructed hierarchically with possible extension at each leaf node. According to SGPIM framework, a supa-policy MUST have at least one supa-policy-statement that is used to define the content of the policy. As shown in figure 2, the top level design policy data model is: -supa-policy: The root of the SUPA generic ECA policy data model -supa-policy-target: The managed object that a supa-policy monitors and/or controls the state of. The target will the where the policy will be worked on, including domain, subnet and so on. Also the managed object will be specified such as a VPN, flow, link and so on. This class is specified by the user as the scope and the object needs to be told. -supa-policy-atomic: A Policy that can be used in a stand-alone manner, and hierarchic policy and composite policy has not been taken into account in this document. Here the atomic means there is only one ECA policy rule in the policy data model. The major advantage of this design fashion is the separation of policy data and how to manage these policy data into policy rules. That means, only change the supa-policy-atomic here can generate new policy without redefine all the policy data. -supa-policy-statement: It is used to define the content of a supa-policy, all the event, condition and action clauses are defined here. This part will not be affected by the changing of policy structures or designs. Chen, et al. Expires April 16, 2016 [Page 5] Internet-Draft SUPA ECA Policy Data Model October 2015 +--rw supa-policy | .... +--rw supa-policy-target | | .... +--rw supa-policy-atomic | | .... +--rw supa-policy-statement | | .... Figure 2: Top level design of SUPA generic policy data model 3.1. supa-policy-target Design for ECA policy data model The supa-policy-target target defines the working object of the policy. More specifically, the scope of the policy will be worked on and the instance that the policy will be worked on. This part should be the input from policy user and is not part of ECA policy itself. E.g., if the bandwidth of a flow of voice stream reaches threshold, more bandwidth will be assigned to guarantee the voice service. Here, which flow is for voice service and will be adjusted is specified by the user as the input of the ECA policy. So some kind of template is needed here to allow users to provide information of the working object of the policy. As shown in figure 3, four attributes of supa-policy-target are defined by the user to specify the working scope of the policy. Then the instance defines the specific work object of the policy, such as a VPN, a flow, a link and so on. Obviously, VPN, flow or link needs different elements to be indicated, so it is can be defined with a "augment" statement to indicate the working object. E.g., if user wants to work on a flow, corresponding elements will be defined within "flow" case. +--rw supa-policy-target +--rw profileType? string +--rw asDomainName? string +--rw adminSubnetwork? string +--rw businessTypeName? string +--rw instanceName +--rw instanceElement? empty Figure 3: The snippet of supa-policy-target 3.2. ECA Policy Data Model Design A supa-ECA-policy-rule, is a subclasses of the supa-policy-atomic class. Therefore, it can be used as part of a hierarchy of Chen, et al. Expires April 16, 2016 [Page 6] Internet-Draft SUPA ECA Policy Data Model October 2015 Policies or in a stand-alone manner. The EPRIM specializes the supa-policy-atomic class to create a supa-ECA-policy-rule; it also specializes the supa-policy class to create a supa-ECA-component, and the supa-policy-statement to create corresponding clauses. The supa-ECA-policy-rule uses the rest of the SGPIM infrastructure to define a complete Policy model according to ECA semantics. +--rw supa-policy-atomic +--rw supa-ECA-policy-rule | .... +--rw supa-ECA-component | .... Figure 4: The snippet of supa-policy-atomic with ECA policy rule -A supa-ECA-policy-rule is defined as a subclass of the SGPIM supa-policy-atomic class. All the related information of the ECA policy are defined here with some basic attributes of the policy and the supa-ECA-component sub class. -A supa-ECA-component is one of core parts of the policy data model; it defines how the event, condition and action clauses are integrated into one working policy. Note that supa-ECA-component does not define the content of the policy itself but the structure as well the association of each policy statement clauses. 3.2.1. supa-ECA-component sub class The principal subclasses of supa-policy-component that are defined in this version of this document are supa-policy-events, supa- policy-conditions, and supa-policy-actions. Each of the sub classes take care the event, condition and action part of the ECA policy respectively. The snippet of supa-ECA-component sub class is shown in figure 5. +--rw supa-ECA-component +--rw supa-policy-events | +--rw has-policy-events? boolean +--rw supa-policy-conditions | +--rw has-policy-conditions? boolean | +--rw conjunctive-type? enumeration +--rw supa-policy-actions +--rw action-execution? enumeration Figure 5: The snippet of supa-ECA-component objects Chen, et al. Expires April 16, 2016 [Page 7] Internet-Draft SUPA ECA Policy Data Model October 2015 The supa-policy-events sub class has one leaf to specify whether the policy has an event statement. If TRUE, the policy will take the event clause defined in the supa-policy-statement class. The supa-policy-conditions sub class defines two things: one, does the policy has conditions, similar to the events part; two, if more than one conditions, how all the conditions are integrated into one single statement. Note that the ECA policy only makes the evaluation of condition statement once. So all the condition clauses needs to be integrated into one statement connected via AND or OR operator. Conjunctive-type defines use AND or OR operator to connect condition clauses. The supa-policy-actions sub class defines how the action clause defined in supa-policy-statement will be executed. 3.3. supa-policy-statement Design for ECA policy data model This is a mandatory abstract class that separates the representation of a supa-policy from its implementation. This abstraction is missing in [RFC3060], [RFC3460]. Basically, all the policy statements are defined here as clauses. SUPA use three types of mechanisms to define policies, entity, script template and Boolean clause. The statement has three part, event-list, condition-list and action-list, each has one or more clauses. -supa-entity, which is a mechanism to directly use existing defined object as the input of event; this is described in more detail in Section 3.3.1. -supa-script, which is a mechanism to directly encode the content of the supa-policy-statement into a script template and needs further execution which is out of SUPA; this is described in more detail in Section 3.3.2. 3.3.1. supa-entity sub class This is a mandatory class that specializes a supa-policy-statement. It is defined that then event object can use the predefined object in existing module. -entity can refer to an existing leaf node defined by other module. An example will be given in the following section. Chen, et al. Expires April 16, 2016 [Page 8] Internet-Draft SUPA ECA Policy Data Model October 2015 +--rw supa-entity +--rw entity? empty Figure 6: The snippet of supa-entity The supa-entity has been defined as a "grouping" to improve reusability. 3.3.2. supa-script sub class This is a mandatory concrete class that specializes (i.e., is a subclass of) a supa-policy-statement. It defines a generalized extension scripting mechanism for representing supa-policy- statement that has not been modeled with other supa policy objects. Rather, the Policy Clause is directly encoded into script template and then been executed in the network management function/controller. -supa-script-content defines the content of this script template. It works with another attribute of the supa-script class, called supa-script-type, which defines how to interpret this script. These two attributes form a tuple, and together enable a machine to understand the script and know how to execute the script. Note that, the scripting approach is to improve the logic expression without defining new logic terminologies. Anything supported by script being used can be accommodated by SUPA. -supa-script-type defines the type of this script being used. It works with another attribute of the supa-script class, called supa-script-content, which defines the content (i.e., the value) of the script template. +--rw supa-script +--rw supa-script-type? scriptType +--rw supa-script-content Figure 7: The snippet of supa-script The supa-script has been defined as a "grouping" to improve reusability as the event and condition statement can both use the script template. 3.4. event-list sub class All the event clauses are defined here with either encoded clause or Boolean clause. As shown in figure 9, each event can only be and must one type of the two clauses. Each event clause is defined Chen, et al. Expires April 16, 2016 [Page 9] Internet-Draft SUPA ECA Policy Data Model October 2015 by calling the predefined two types of clauses in a "choice" statement. +--rw event-list +--rw event-name +--rw (eventType)? +--:(entity) | +--rw entity? empty +--:(script) | +--rw supa-script-type? scriptType | +--rw supa-script-content Figure 8: The snippet of event-list sub class 3.5. condition-list sub class All the condition clauses are defined using a "augment" statement. If there is more than one condition clause, just simply add more "container" to define more condition clause. +--rw condition-list +--rw condition-name empty Figure 9: The snippet of condition-list sub class 3.6. action-list sub class The action-list sub class defines all the action clauses those will be executed while the condition statement is being evaluating as TRUE. Since the action can only be defined by users as each action may have different attributes and elements to configure, the predefined structures and statements will not help. Not only the value of the leaf but also the number of leafs will depend on the type of actions. As shown in figure 11, here a "augment" statement is designed to keep the structure of the action statement stable while allows extensibility. The user can define new action by adding more case statement with self-defined element and statement structure without affecting existing one. +--rw action-list +--rw actionName +--rw actionElement? empty Figure 10: The snippet of action-list sub class Chen, et al. Expires April 16, 2016 [Page 10] Internet-Draft SUPA ECA Policy Data Model October 2015 4. Generic ECA Policy Data Model 4.1. Abstract Generic ECA Policy Data Model Hierarchy Figure 12 shows the structure of abstract SUPA Generic ECA policy data model. Chen, et al. Expires April 16, 2016 [Page 11] Internet-Draft SUPA ECA Policy Data Model October 2015 module: ietf-supa-policy +--rw supa-policy +--rw supa-policy-name? string +--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-target | +--rw profileType? string | +--rw asDomainName? string | +--rw adminSubnetwork? string | +--rw businessTypeName? string | +--rw instance +--rw supa-policy-atomic | +--rw supa-ECA-policy-rule | +--rw policy-rule-deploy-status? enumeration | +--rw policy-rule-exec-status? enumeration | +--rw supa-ECA-component | +--rw supa-policy-events | | +--rw has-policy-events? boolean | +--rw supa-policy-conditions | | +--rw has-policy-conditions? boolean | | +--rw conjunctive-type? enumeration | +--rw supa-policy-actions | +--rw action-execution? enumeration +--rw supa-policy-statement +--rw event-list | +--rw event-name | +--rw (eventType)? | +--:(entity) | | +--rw entity? empty | +--:(script) | +--rw supa-script-type? scriptType | +--rw supa-script-content +--rw condition-list +--rw action-list Figure 11: The structure of abstract SUPA Generic ECA policy data model Chen, et al. Expires April 16, 2016 [Page 12] Internet-Draft SUPA ECA Policy Data Model October 2015 4.2. SUPA Generic ECA Policy Data Model in YANG Module module ietf-supa-policy { namespace "urn:ietf:params:xml:ns:yang:ietf-supa-policy0910"; // replace with IANA namespace when assigned prefix policy; import ietf-yang-types { prefix yang; } organization "IETF"; contact "Editor: Maoke Chen"; description "This YANG module defines a component that describing the generic ECA policy data model refining from SGPIM and EPRIM. Terms and Acronyms "; revision 2015-08-25 ; identity network-object{ } container supa-policy{ description "This defines a Generic ECA policy data model "; leaf supa-policy-name { description "The name of the policy"; type string; } leaf supa-policy-priority { description "The priority of the defined policy"; type uint8; } container supa-policy-validity-period { description "The valid time of the policy. E.g., the policy will be valid 9am-9am daily"; leaf start { Chen, et al. Expires April 16, 2016 [Page 13] Internet-Draft SUPA ECA Policy Data Model October 2015 type yang:date-and-time; } leaf end { type yang:date-and-time; } leaf duration { type uint32; } leaf periodicity { type enumeration { enum daily { } enum monthly { } } } } container supa-policy-target { description "SUPAPolicyTarget is an abstract class that defines a set of managed objects that may be affected by the actions of a SUPAPolicyStatement."; leaf profileType { description "Which profile the policy will be worked on"; type string; } leaf asDomainName { description "Which domain the policy will be worked on"; type string; } leaf adminSubnetwork { description "Which subnet the policy will be worked on"; type string; } leaf businessTypeName { description "Which business the policy will be worked on"; type string; } container instance { description "Which instance the policy will be worked on? E.g., a VPN, a flow or a link"; Chen, et al. Expires April 16, 2016 [Page 14] Internet-Draft SUPA ECA Policy Data Model October 2015 } } container supa-policy-atomic { description "Define a atomic ECA policy rule"; container supa-ECA-policy-rule { description "supa-ECA-policy-rule is an abstracted class to define how the event, condition and action clause will be organized into a policy rule."; leaf policy-rule-deploy-status { 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"; } } } leaf policy-rule-exec-status { type enumeration { enum 0{ description "undefined"; } enum 1{ description "executed and SUCEEDED (operational mode)"; } enum 2{ description "executed and FAILED (operational mode)"; } enum 3{ Chen, et al. Expires April 16, 2016 [Page 15] Internet-Draft SUPA ECA Policy Data Model October 2015 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 supa-ECA-component{ description "The component defines how the event, condition and action clauses are constructed into policy"; container supa-policy-events { description "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."; leaf has-policy-events { description "Whether the policy has an event?"; type boolean; } } container supa-policy-conditions { description "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."; leaf has-policy-conditions { description "Whether the policy has an condition?"; type boolean; } Chen, et al. Expires April 16, 2016 [Page 16] Internet-Draft SUPA ECA Policy Data Model October 2015 leaf conjunctive-type { description "Define how the condition clauses will be conjuncted, AND or OR"; type enumeration { enum 0 { description "AND: all the conditions must be matched"; } enum 1 { description "OR: one or more of the conditions are matched"; } } } } container supa-policy-actions { description "A set of actions that should be triggered as part of the policy execution: This enables the service management to provision the service."; leaf action-execution { description "How the actions will be executed"; type enumeration{ enum 0 { description "Single: execute one action"; } enum 1 { description "Sequenced: execute actions one by one in sequence"; } } } } } } } container supa-policy-statement { typedef scriptTemplate { description Chen, et al. Expires April 16, 2016 [Page 17] Internet-Draft SUPA ECA Policy Data Model October 2015 "The script defined in the YANG model can be sent to the policy engine to execute. Here is the content of the script template"; type string; } typedef scriptType { description "Here is the type of the script to be executed. E.g., Python, Perl"; type enumeration{ enum 0{ description "Python"; } enum 1{ description "Perl"; } enum 2{ description "Javascript"; } } } grouping supa-entity{ description "Use predefined object to specify the event and condition"; leaf entity{ description "The path of the reference node needs to be specified when using this type to define event or condition"; type empty; } } grouping supa-script{ description "The script can be used to specify the event and condition clauses. The script can be executed in the policy engine."; leaf supa-script-type { description "Use which type of script, such as Python, Perl and so on."; type scriptType; } Chen, et al. Expires April 16, 2016 [Page 18] Internet-Draft SUPA ECA Policy Data Model October 2015 anyxml supa-script-content { description "The script template that will be sent to the policy engine to specify the event or condition clause"; } } container event-list{ description "The event clauses. Each one can be a predefined network entity, a script or boolean clause,"; container event-name { choice eventType{ case entity{ uses supa-entity; } case script { uses supa-script; } } } } container condition-list{ description "The condition clauses. Each one can be a predefined network entity, a script or boolean clause, and conjuncted by AND or OR"; } container action-list{ description "Defines actions clause here. Each action has unique attributes so a choice statement here to allow self-defined action without changing structure."; } } } } 5. ECA Policy Data Model Example This section will provide one example to show how to use this generic ECA policy data model to generate specific policy data model a service flow policy that can be mapped into configurations. Chen, et al. Expires April 16, 2016 [Page 19] Internet-Draft SUPA ECA Policy Data Model October 2015 The generic ECA policy data model contains no configuration information and lack of action elements, it cannot be mapped into configuration such as XML instance by just filling the value of the leaves. In order to make a working ECA policy, the user needs to define some part of the generic policy data model and fill in some of the leaves but do not need change the structure. Basically, instantiate a generic ECA policy data model into a specific ECA policy data model only needs adding some leaves and specify some values. More specifically, for a service flow policy "If the bandwidth of a voice stream flow exceeds 8Mbps, change the CIR to 20Mbps to guarantee the voice service", how to use generic ECA data model to generate a working data model to deploy this policy? Instructions with data model will be given in next few sections. The major steps are: 1. Fill in the basic attributes of the policy, such as name, priority, valid period and so on. 2. Redefine the supa-policy-target 3. Specify the leaf value in supa-ECA-component to define how the policy clauses in supa-policy-statement will be integrated into a policy rule. 4. Define the event clause, condition clause and action clause using augment statement. 5.1. Redefine the supa-policy-target The first step is to redefine the target of the policy. As shown in figure 13, the user fills in all the attributes to define the working scope of the policy such as the profile, domain and subnet. Then, in order to tell the system which flow to be worked on, the user will define a flow filter with possible elements to get the right flow. Here, dscp value, source IP, destination IP, source port and destination port are attributes needed to indicate a flow. For this working policy, user also fills in the value of each leaf, dscp = 5, src-ip-addr = 10.111.10.1, dst-ip-addr = 10.112.10.1, src-port = 8080 and dst-port = 8090. After all this, the desired voice stream flow (dscp=5) will be selected as policy target. Chen, et al. Expires April 16, 2016 [Page 20] Internet-Draft SUPA ECA Policy Data Model October 2015 augment /supa:supa-policy/supa:supa-policy-target/supa:instance: +--rw flowFilter +--rw dscp? uint32 +--rw src-ip-addr? string +--rw dst-ip-addr? string +--rw src-port? uint32 +--rw dst-port? uint32 Figure 12: The snippet of specific policy target Note that, the supa-policy-target is reusable and extensible as the user can add more instance into case statement without affecting existing one. E.g., user could also add VPN with elements such as VPNName, source IP and destination IP. 5.2. Define the supa-ECA-component In order to define how the policy clauses are organized and associated into one policy, the user needs to fill in all the leaf value in supa-ECA-component. As shown in figure 14, the corresponding value will be filled in. The policy has event and condition, but only one condition. And the policy will execute a single action if the condition being evaluated as TRUE. +--rw supa-ECA-component +--rw supa-policy-events | +--rw has-policy-events? boolean //TRUE +--rw supa-policy-conditions | +--rw has-policy-conditions? boolean //TRUE | +--rw conjunctive-type? enumeration//0: AND conjunctive +--rw supa-policy-actions +--rw action-execution? enumeration //0: single Figure 13: The snippet of specific ECA component 5.3. Define Event, Condition and Action clause The core part of ECA policy is the policy statement as individual clauses. For the example policy, event is the flow entry, condition is that its bandwidth >= 8M, and action is to do CAR with CIR = 20M. As shown in figure 15, the user first needs to choose the type of event and condition clause. In this case, event clause should be entity and use predefined flow object. Condition clause should be script template to send the bandwidth >= 8M script to the controller. Then design the event and condition clause by filling in the leaf. Note that the choice of clause type Chen, et al. Expires April 16, 2016 [Page 21] Internet-Draft SUPA ECA Policy Data Model October 2015 does not include in YANG data model but will be accomplished in NETCONF via operation. More specifically, the path of leafref of entity is "/supa:flows/supa:flow/supa:flowId", which pointed to anther module. We suppose that module has already defined the object "flow". For the condition part, the condition elements are defined using augment statement. "bandwidth" and "threshold" leaf are added into "condition-bandwidth" class. augment /supa:supa-policy/supa:supa-policy-statement/supa:condition- list: +--rw condition-bandwidth +--rw bandwidth? uint32 +--rw threshold? uint32 augment /supa:supa-policy/supa:supa-policy-statement/supa:action-list: +--rw action-redirect +--rw cir? uint32 +--rw pir? uint32 +--rw Cbs? uint32 +--rw Pbs? uint32 Figure 14: The snippet of specific policy statement The design of action clause is more complicated as different action has different number and type of attributes to be specified. And the action is only valid when the condition is evaluated as TRUE. So here a "when" statement is used to do the augment. The "when" expression is the Xpath expression to evaluate if the predefined "bandwidth" exceeds the "threshold". Finally, with the refined ECA policy data model as shown in section 6, with working policy "If the bandwidth of a voice stream flow exceeds 8Mbps, change the CIR to 20Mbps to guarantee the voice service" can be mapped into XML instance. Chen, et al. Expires April 16, 2016 [Page 22] Internet-Draft SUPA ECA Policy Data Model October 2015 6. Specific ECA Policy Data Model for service flow policy 6.1. SUPA specific ECA Policy Data Model in YANG Module module ietf-supa-service-flow { namespace "urn:ietf:params:xml:ns:yang:ietf-supa-policy"; // replace with IANA namespace when assigned prefix flow; import ietf-yang-types { prefix yang; } import eca-policy-0910 { prefix supa; } organization "IETF"; contact "Editor: Maoke Chen"; description "This YANG module defines a component that describing the specific ECA policy data model for service flow refining from SGPIM and EPRIM. Terms and Acronyms "; revision 2015-08-05 ; //flow filter parameters for a flow augment "/supa:supa-policy/supa:supa-poliy- target/supa:instance"{ container flowFilter{ leaf dscp { description "dscp value of the indicated flow"; type uint32; config "true"; default "0"; } leaf src-ip-addr{ description "source ip addresses of the flow"; type string; Chen, et al. Expires April 16, 2016 [Page 23] Internet-Draft SUPA ECA Policy Data Model October 2015 config "true"; default "0.0.0.0/0"; } leaf dst-ip-addr{ description "destination ip addresses of the flow"; type string; config "true"; default "0.0.0.0/0"; } leaf src-port{ description "source port number of the flow"; type uint32; config "true"; } leaf dst-port{ description "destination port number of the flow"; type uint32; config "true"; } } } //Add condition clauses into the condition list augment "/supa:supa-policy/supa:supa-policy- statement/supa:condition-list" { container condition-bandwidth{ leaf bandwidth{ description "The flow bandwidth, unit is Mbps"; type uint32; } leaf threshold{ description "The threshold to trigger the action."; type uint32; } } } //action node is depending on the condition augment "/supa:supa-policy/supa:supa-policy- statement/supa:action-list" { description "The augment of the action node is only valid when the condition is evaluated as TRUE"; Chen, et al. Expires April 16, 2016 [Page 24] Internet-Draft SUPA ECA Policy Data Model October 2015 when "/ietf-supa-policy/supa-policy/supa-policy- statement/condition-list/condition- bandwidth/bandwidth>/ietf-supa-policy/supa-policy/supa- policy-statement/condition-list/condition- bandwidth/threshold"; container action-redirect{ leaf cir { description "Committed information rate"; type uint32; } leaf pir { description "Peak information rate"; type uint32; } leaf Cbs { description "Committed burst size"; type uint32; } leaf Pbs { description "Peak burst size"; type uint32; } } } } 7. Security Considerations TBD 8. IANA Considerations This document has no actions for IANA. 9. Contributor List Andy Bierman YumaWorks, Inc. Email: andy@yumaworks.com Chen, et al. Expires April 16, 2016 [Page 25] Internet-Draft SUPA ECA Policy Data Model October 2015 Yiyong Zha Huawei Technologies, Email: zhayiyong@huawei.com 10. Acknowledgments This document has benefited from reviews, suggestions, comments and proposed text provided by the following members, listed in alphabetical order: Liya Zhang, John Strassner, Juergen Schoenwaelder. 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, April 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. 11.2. Informative References [I-D. strassner-supa-generic-policy-info-model] John Strassner, "Generic Policy Information Model for Simplified Use of Policy Abstractions (SUPA)", draft-strassner-supa-generic-policy-info- model-01 (work in progress), May 2015. [RESTCONF] Bierman, A., Bjorklund, M., Watsen, K., and R. Fernando, "RESTCONF Protocol", draft-ietf-netconf-restconf (work in progress), July 2014. [POLICY MODEL] Z. Wang, L. Dunbar, Q. Wu, "Network Policy YANG Data Model" draft-wang-netmod-yang-policy-dm, January 2015. Chen, et al. Expires April 16, 2016 [Page 26] Internet-Draft SUPA ECA Policy Data Model October 2015 Authors' Addresses Maoke Chen BBIX, Inc. Tokyo Shiodome Building, Higashi-Shimbashi 1-9-1 Minato-ku, Tokyo, 105-7310, Japan Email: maoke@bbix.net 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/ Masaki Fukushima KDDI R&D Labs. Inc. 2-1-15 Ohara, Fujimino, Saitama, Japan. 356-8502 Email: fukusima@kddilabs.jp Laurent Ciavaglia Email: Laurent.Ciavaglia@alcatel-lucent.com Chen, et al. Expires April 16, 2016 [Page 27]