Internet DRAFT - draft-chen-supa-eca-data-model
draft-chen-supa-eca-data-model
Network Working Group M. Chen
Internet Draft BBIX, Inc.
Intended status: Standard Track L.Contreras
Expires: April 26, 2016 Telefonica I+D
M. Hayashi
KDDI R&D Labs. Inc.
T. Tsou
Huawei Technologies
October 26, 2015
ECA Policy YANG Data Model
draft-chen-supa-eca-data-model-05
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 26 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 26, 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 ................................20
5.1. Redefine the supa-policy-target .........................21
5.2. Define the supa-ECA-component ...........................21
5.3. Define Event, Condition and Action clause ...............22
6. Specific ECA Policy Data Model for service flow policy .......24
Chen, et al. Expires April 26, 2016 [Page 2]
Internet-Draft SUPA ECA Policy Data Model October 2015
6.1. SUPA specific ECA Policy Data Model in YANG Module ......24
7. Security Considerations .....................................27
8. IANA Considerations ..........................................27
9. Contributor List ............................................27
10. Acknowledgments .............................................27
11. References ..................................................27
11.1. Normative References ...................................27
11.2. Informative References .................................27
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 26, 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:
<status> <flags> <name> <opts> <type>
<status> is one of:
+ for current
x for deprecated
o for obsolete
<flags> is one of:
rw for Read/Write
ro for ReadOnly
-x for rpcs (remote procedure calls)
-n for notifications
<name> is the name of the node
-If the node is augmented into the tree from another module, its
name is printed as <prefix>:<name>.
Chen, et al. Expires April 26, 2016 [Page 4]
Internet-Draft SUPA ECA Policy Data Model October 2015
<opts> is one of:
? for an optional leaf or choice
! for a presence container
* for a leaf-list or list
[<keys>] 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 26, 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 26, 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 26, 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 26, 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 8, each event can only be
and must one type of the two clauses. Each event clause is defined
Chen, et al. Expires April 26, 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 10, 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 26, 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 11 shows the structure of abstract SUPA Generic ECA policy
data model.
Chen, et al. Expires April 26, 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 26, 2016 [Page 12]
Internet-Draft SUPA ECA Policy Data Model October 2015
4.2. SUPA Generic ECA Policy Data Model in YANG Module
<CODE BEGINS> file "ietf-eca-policy@2015-10-10.yang"
module ietf-eca-policy {
namespace "urn:ietf:params:xml:ns:yang:ietf-eca-policy";
// 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 {
reference "";
}
container supa-policy{
description
"This defines a Generic ECA policy data model ";
leaf supa-policy-name {
type string;
description
"The name of the policy";
}
leaf supa-policy-priority {
type uint8;
description
"The priority of the defined policy";
}
container supa-policy-validity-period {
description
"The valid time of the policy. E.g., the policy will
be valid 9am-9am daily";
Chen, et al. Expires April 26, 2016 [Page 13]
Internet-Draft SUPA ECA Policy Data Model October 2015
leaf start {
type yang:date-and-time;
description "date and time to start the policy";
}
leaf end {
type yang:date-and-time;
description "date and time to end the policy";
}
leaf duration {
type uint32;
description "duration of the policy";
}
leaf periodicity {
type enumeration {
enum daily {
value 0;
description "The policy is repeated daily";
}
enum monthly {
value 1;
description "The policy is repeated monthly";
}
}
description "How the policy is repeated";
}
}
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 {
type string;
description
"Which profile the policy will be worked on";
}
leaf asDomainName {
type string;
description
"Which domain the policy will be worked on";
}
leaf adminSubnetwork {
type string;
description
"Which subnet the policy will be worked on";
}
leaf businessTypeName {
Chen, et al. Expires April 26, 2016 [Page 14]
Internet-Draft SUPA ECA Policy Data Model October 2015
type string;
description
"Which business the policy will be worked on";
}
container instance {
description
"Which instance the policy will be worked on? E.g.,
a VPN, a flow or a link";
}
}
container supa-policy-atomic {
description
"Define a atomic ECA policy rule";
container supa-ECA-policy-rule {
description
"SUPA policy atomic defines a standalone 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";
}
}
description
"The deploy status of the policy.";
}
leaf policy-rule-exec-status {
type enumeration {
enum 0{
description "undefined";
}
Chen, et al. Expires April 26, 2016 [Page 15]
Internet-Draft SUPA ECA Policy Data Model October 2015
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)";
}
}
description
"The executing status of the policy.";
}
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 {
type boolean;
description
"Whether the policy has an event?";
}
}
container supa-policy-conditions {
Chen, et al. Expires April 26, 2016 [Page 16]
Internet-Draft SUPA ECA Policy Data Model October 2015
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 {
type boolean;
description
"Whether the policy has an condition?";
}
leaf conjunctive-type {
type enumeration {
enum 0 {
description "AND: all the conditions
must be matched";
}
enum 1 {
description "OR: one or more of the
conditions are matched";
}
}
description
"Define how the condition clauses will be
conjuncted, AND or OR";
}
}
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 {
type enumeration{
enum 0 {
description "Single: execute one action";
}
enum 1 {
description "Sequenced: execute actions
one by one
in sequence";
}
}
description
"How the actions will be executed";
Chen, et al. Expires April 26, 2016 [Page 17]
Internet-Draft SUPA ECA Policy Data Model October 2015
}
}
}
}
}
container supa-policy-statement {
description
"The individual policy statement clauses.";
/*typedef scriptTemplate {
type string;
description
"The script defined in the YANG model can be sent
to the policy engine to execute. Here is the
content of the script template";
}*/
typedef scriptType {
type enumeration{
enum 0{
description
"Python";
}
enum 1{
description
"Perl";
}
enum 2{
description
"Javascript";
}
}
description
"Here is the type of the script to be executed.
E.g., Python, Perl";
}
grouping supa-entity{
leaf entity{
type empty;
description
"The path of the reference node needs to be
specified when using this type to define event
or condition";
}
description
"Use predefined object to specify the event and
condition";
}
grouping supa-script{
Chen, et al. Expires April 26, 2016 [Page 18]
Internet-Draft SUPA ECA Policy Data Model October 2015
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 {
type scriptType;
description
"Use which type of script, such as Python, Perl
and so on.";
}
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 {
description
"The event clause of the policy.";
choice eventType{
description
"User define to use which type event.";
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
Chen, et al. Expires April 26, 2016 [Page 19]
Internet-Draft SUPA ECA Policy Data Model October 2015
"Defines actions clause here. Each action has
unique attributes so a choice statement here to
allow self-defined action without changing.";
}
}
}
}
<CODE ENDS>
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.
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.
Chen, et al. Expires April 26, 2016 [Page 20]
Internet-Draft SUPA ECA Policy Data Model October 2015
5.1. Redefine the supa-policy-target
The first step is to redefine the target of the policy. As shown
in figure 12, 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.
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 13, 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.
Chen, et al. Expires April 26, 2016 [Page 21]
Internet-Draft SUPA ECA Policy Data Model October 2015
+--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 14, 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
does not include in YANG data model but will be accomplished in
NETCONF via <edit-config> 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.
Chen, et al. Expires April 26, 2016 [Page 22]
Internet-Draft SUPA ECA Policy Data Model October 2015
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 26, 2016 [Page 23]
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
<CODE BEGINS> file "ietf-supa-service-flow-policy@2015-10-10.yang"
module ietf-supa-service-flow-policy {
namespace "urn:ietf:params:xml:ns:yang:ietf-supa-service-flow-"
+"policy";
// replace with IANA namespace when assigned
prefix flow;
/*import ietf-yang-types {
prefix yang;
}*/
import ietf-inet-types {
prefix inet;
}
import ietf-eca-policy {
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-25 {
reference "";
}
//flow filter parameters for a flow
augment "/supa:supa-policy/supa:supa-policy-
target/supa:instance" {
description
"Use the base ECA policy model to define service flow
policy.";
container flowFilter{
description
Chen, et al. Expires April 26, 2016 [Page 24]
Internet-Draft SUPA ECA Policy Data Model October 2015
"Self defined flow filter to specify the policy
target.";
leaf dscp {
type uint32;
description
"dscp value of the indicated flow";
}
leaf src-ip-addr{
type inet:ipv4-address;
description
"source ip addresses of the flow";
}
leaf dst-ip-addr{
type inet:ipv4-address;
description
"destination ip addresses of the flow";
}
leaf src-port{
type uint32;
description
"source port number of the flow";
}
leaf dst-port{
type uint32;
description
"destination port number of the flow";
}
}
}
//Add condition clauses into the condition list
augment "/supa:supa-policy/supa:supa-policy-statement/supa:"
+"condition-list" {
description
"Define the condition clause with parameters.";
container condition-bandwidth{
description
"Define the bandwidth with threshold value.";
leaf bandwidth{
type uint32;
description
"The flow bandwidth, unit is Mbps";
}
leaf threshold{
type uint32;
description
"The threshold to trigger the action.";
}
Chen, et al. Expires April 26, 2016 [Page 25]
Internet-Draft SUPA ECA Policy Data Model October 2015
}
}
//action node is depending on the condition
augment "/supa:supa-policy/supa:supa-policy-
statement/supa:action-"
+"list" {
container action-redirect{
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"{
description
"If the condition has been evaluated as TRUE, then
the action is added to the policy.";
}
leaf cir {
type uint32;
description
"Committed information rate";
}
leaf pir {
type uint32;
description
"Peak information rate";
}
leaf Cbs {
type uint32;
description
"Committed burst size";
}
leaf Pbs {
type uint32;
description
"Peak burst size";
}
description
"Define the action clause in the policy statement.";
}
description
"The augment of the action node is only valid when the
condition is evaluated as TRUE";
}
}
<CODE ENDS>
Chen, et al. Expires April 26, 2016 [Page 26]
Internet-Draft SUPA ECA Policy Data Model October 2015
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
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, 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.
11.2. Informative References
[I-D. strassner-supa-generic-policy-info-model] John Strassner,
"Generic Policy Information Model for Simplified Use of Policy
Chen, et al. Expires April 26, 2016 [Page 27]
Internet-Draft SUPA ECA Policy Data Model October 2015
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.
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/
Michiaki Hayashi
KDDI R&D Labs. Inc.
2-1-15 Ohara, Fujimino, Saitama, Japan. 356-8502
Email: mc-hayashi@kddilabs.jp
Tina Tsou
Huawei Technologies
Email: Tina.Tsou.Zouting@huawei.com
Chen, et al. Expires April 26, 2016 [Page 28]
