ECA Policy YANG Data Model
draft-chen-supa-eca-data-model-02
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Maoke Chen , Luis M. Contreras , Masaki Fukushima | ||
| Last updated | 2015-08-07 | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-chen-supa-eca-data-model-02
Network Working Group M. Chen
Internet Draft BBIX, Inc.
Intended status: Standard Track L.Contreras
Expires: February 6, 2016 Telefonica I+D
M. Fukushima
KDDI R&D Labs. Inc.
August 6, 2015
ECA Policy YANG Data Model
draft-chen-supa-eca-data-model-02
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 and EPRIM 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."
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
Chen, et al. Expires February 6, 2016 [Page 1]
Internet-Draft SUPA ECA Policy Data Model August 2015
This Internet-Draft will expire on January 22,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 ............................ 4
3.1. supa-policy-target Design for ECA policy data model.......... 5
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....... 7
3.3.1. supa-encoded-clause sub class .......................... 8
3.3.2. supa-boolean-clause sub class .......................... 8
3.3.3. event-list sub class ................................... 9
3.3.4. condition-list sub class .............................. 10
3.3.5. 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 .......... 14
5. ECA Policy Data Model Example ................................... 21
5.1. Redefine the supa-policy-target ............................ 22
5.2. Define the supa-ECA-component .............................. 22
5.3. Define Event, Condition and Action clause .................. 23
6. Specific ECA Policy Data Model for service flow policy .......... 24
6.1. Abstract Specific ECA Policy Data Model Hierarchy .......... 24
6.2. SUPA specific ECA Policy Data Model in YANG Module ......... 27
7. Security Considerations ......................................... 36
8. IANA Considerations ............................................. 36
9. Contributor List ................................................ 36
10. Acknowledgments ................................................ 36
11. References ..................................................... 36
11.1. Normative References ...................................... 36
Chen, et al. Expires February 6, 2016 [Page 2]
Internet-Draft SUPA ECA Policy Data Model August 2015
11.2. Informative References .................................... 37
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.
- 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 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.
Chen, et al. Expires February 6, 2016 [Page 3]
Internet-Draft SUPA ECA Policy Data Model August 2015
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>.
<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
Chen, et al. Expires February 6, 2016 [Page 4]
Internet-Draft SUPA ECA Policy Data Model August 2015
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.
+--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
Chen, et al. Expires February 6, 2016 [Page 5]
Internet-Draft SUPA ECA Policy Data Model August 2015
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
defined with a ''choice-case'' 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)?
+--:(instanceType)
+--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 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
Chen, et al. Expires February 6, 2016 [Page 6]
Internet-Draft SUPA ECA Policy Data Model August 2015
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
The supa-policy-events sub class has one leaf to specify whether the policy has
a 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 two types of clauses to define policies, encoded clause and Boolean
clause. The statement has three part, event-list, condition-list and action-
list, each has one or more clauses.
Chen, et al. Expires February 6, 2016 [Page 7]
Internet-Draft SUPA ECA Policy Data Model August 2015
-supa-encoded-clause, which is a mechanism to directly encode the content of
the supa-policy-statement into a set of attributes; this is described in more
detail in Section 3.3.1.
-supa-boolean-clause, which defines a supa-policy-statement as a set of one or
more clauses; multiple clauses may be combined with Boolean AND and OR
operators. This defines a supa-policy as a completely reusable set of supa-
policy objects that are structured in an ECA form, and is described in more
detail in Section 3.3.2.
3.3.1. supa-encoded-clause 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 mechanism for
representing supa-policy-statement that have not been modeled with other supa-
policy objects. Rather, the Policy Clause is directly encoded into the
attributes of the supa-encoded-clause.
-supa-clause-content defines the content of this encoded clause of this clause.
It works with another attribute of the supa-encoded-clause class, called supa-
clause-format, which defines how to interpret this attribute. These two
attributes form a tuple, and together enable a machine to understand the syntax
and value of the encoded clause for the object instance of this class.
-supa-clause-format defines the format of this encoded clause. It works with
another attribute of the supa-encoded-clause class, called supa-clause-content,
which defines the content (i.e., the value) of the encoded clause.
+--rw supa-encoded-clause
+--rw supa-clause-content? string
+--rw supa-clause-format? String
Figure 6: The snippet of supa-encoded-clause
The supa-encoded-clause has been defined as a ''grouping'' to improve
reusability as the event and condition statement can both use the encoded
clause.
3.3.2. supa-boolean-clause sub class
This is a mandatory abstract class that defines a clause as the following
three-tuple:
{PolicyVariable, PolicyOperator, PolicyValue}
The composite pattern is used in order to construct complex Boolean clauses
from a set of supa-boolean-clause objects. This is why supa-boolean-clause is
Chen, et al. Expires February 6, 2016 [Page 8]
Internet-Draft SUPA ECA Policy Data Model August 2015
defined to be abstract - only instances of the supa-boolean-clause-atomic
and/or supa-boolean-clause-composite classes can be used to construct a supa-
boolean-clause. As shown in figure 7, it aggregates supa-policy-variable, supa-
policy-operator, and supa-policy-value objects to form a complete supa-boolean-
clause.
+--rw supa-boolean-clause
+--rw supa-policy-variable? string
+--rw supa-policy-operator? enumeration
+--rw supa-policy-value? uint32
Figure 7: The snippet of supa-boolean-clause
-The value of a supa-policy-variable is typically compared to the value of a
supa-policy-value using the type of operator defined in a supa-policy-operator.
-supa-policy-operator defines class for modeling different types of operators
that are used in a supa-policy-statement.
Values include:
0: Unknown
1: Match
2: Greater than
3: Greater than or equal to
4: Less than
5: Less than or equal to
6: Equal to
7: Not equal to
8: IN
9: NOT IN
10: SET
11: CLEAR
-The supa-policy-value class is a mandatory abstract class for modeling
different types of values and constants that occur in a supa-policy-statement.
The supa-encoded-clause has been defined as a ''grouping'' to improve
reusability as the event and condition statement can both use the encoded
clause.
3.3.3. 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
Chen, et al. Expires February 6, 2016 [Page 9]
Internet-Draft SUPA ECA Policy Data Model August 2015
two clauses. Each event clause is defined by calling the predefined two types
of clauses in a ''choice'' statement.
+--rw event-list
+--rw event-name
+--rw (clauseType)?
+--:(encoded)
| +--rw supa-clause-content? string
| +--rw supa-clause-format? string
+--:(boolean)
+--rw supa-policy-variable? string
+--rw supa-policy-operator? enumeration
+--rw supa-policy-value? uint32
Figure 8: The snippet of event-list sub class
3.3.4. condition-list sub class
All the condition 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 condition clause is defined by calling the predefined
two types of clauses in a ''choice'' 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
+--rw (clauseType)?
+--:(encoded)
| +--rw supa-clause-content? string
| +--rw supa-clause-format? string
+--:(boolean)
+--rw supa-policy-variable? string
+--rw supa-policy-operator? enumeration
+--rw supa-policy-value? uint32
Figure 9: The snippet of condition-list sub class
3.3.5. 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 ''choice-case'' statement is
designed to keep the structure of the action statement stable while allows
Chen, et al. Expires February 6, 2016 [Page 10]
Internet-Draft SUPA ECA Policy Data Model August 2015
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)?
+--:(actionType)
+--rw actionElement? Empty
Figure 10: The snippet of action-list sub class
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 February 6, 2016 [Page 11]
Internet-Draft SUPA ECA Policy Data Model August 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 (instanceName)?
| +--:(instanceType)
| +--rw instanceElement? empty
+--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 (clauseType)?
| +--:(encoded)
| | +--rw supa-clause-content? string
| | +--rw supa-clause-format? string
| +--:(boolean)
| +--rw supa-policy-variable? string
| +--rw supa-policy-operator? enumeration
| +--rw supa-policy-value? uint32
+--rw condition-list
| +--rw condition-name
| +--rw (clauseType)?
| +--:(encoded)
| | +--rw supa-clause-content? string
| | +--rw supa-clause-format? string
| +--:(boolean)
Chen, et al. Expires February 6, 2016 [Page 12]
Internet-Draft SUPA ECA Policy Data Model August 2015
| +--rw supa-policy-variable? string
| +--rw supa-policy-operator? enumeration
| +--rw supa-policy-value? uint32
+--rw action-list
+--rw (actionName)?
+--:(actionType)
+--rw actionElement? empty
Figure 11: The structure of abstract SUPA Generic ECA policy data model
Chen, et al. Expires February 6, 2016 [Page 13]
Internet-Draft SUPA ECA Policy Data Model August 2015
4.2. SUPA Generic ECA Policy Data Model in YANG Module
<CODE BEGINS>
module ietf-supa-policy {
namespace "urn:ietf:params:xml:ns:yang:ietf-supa-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-05 ;
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 {
type yang:date-and-time;
}
leaf end {
type yang:date-and-time;
}
leaf duration {
type uint32;
Chen, et al. Expires February 6, 2016 [Page 14]
Internet-Draft SUPA ECA Policy Data Model August 2015
}
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;
}
choice instanceName {
description
"Which instance the policy will be worked on? E.g., a VPN, a flow
or a link";
case instanceType {
leaf instanceElement{
type empty;
}
}
}
}
container supa-policy-atomic {
Chen, et al. Expires February 6, 2016 [Page 15]
Internet-Draft SUPA ECA Policy Data Model August 2015
description
"Define a atomic ECA policy rule";
container supa-ECA-policy-rule {
description
"A supa-policy-atomic class represents a SUPA ECA Policy Rule
that can operate as a single, stand-alone, manageable object. Put
another way, a supa-policy-atomic object can NOT be modeled as a
set of hierarchical supa-policy-rule objects; if this is required,
then a supa-policy-composite object should be used instead.'';
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{
description "currently executing (operational mode)";
}
enum 4{
description "executed and SUCEEDED (test mode)";
Chen, et al. Expires February 6, 2016 [Page 16]
Internet-Draft SUPA ECA Policy Data Model August 2015
}
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;
}
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 {
Chen, et al. Expires February 6, 2016 [Page 17]
Internet-Draft SUPA ECA Policy Data Model August 2015
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 {
grouping supa-encoded-clause{
description "SUPAEncodedClause, which is a mechanism to directly
encode the content of the SUPAPolicyStatement into a set of
attributes";
leaf supa-clause-content {
description "This is a mandatory string attribute, and
defines the content of this encoded clause of this clause. It
works with another attribute of the SUPAEncodedClause class,
called supaClauseFormat, which defines how to interpret this
attribute. These two attributes form a tuple, and together
enable a machine to understand the syntax and value of the
encoded clause for the object instance of this class.";
type string;
}
leaf supa-clause-format {
description
"This is a mandatory string attribute, and defines the
Chen, et al. Expires February 6, 2016 [Page 18]
Internet-Draft SUPA ECA Policy Data Model August 2015
format of this encoded clause. It works with another
attribute of the SUPAEncodedClause class, called
supaClauseContent, which defines the content (i.e., the
value) of the encoded clause.";
type string;
}
}
grouping supa-boolean-clause{
description
"SUPABooleanClause, which defines a SUPAPolicyStatement as a
set of one or more clauses; multiple clauses may be combined
with Boolean AND and OR operators. This defines a SUPAPolicy
as a completely reusable set of SUPAPolicy objects that are
structured in an ECA form";
leaf supa-policy-variable {
description
"The definition of the variable";
type string;
}
leaf supa-policy-operator {
type enumeration {
enum 0 {
description "Unknown";
}
enum 1 {
description "Match";
}
enum 2 {
description "Greater than";
}
enum 3 {
description "Greater than or equal to";
}
enum 4 {
description "Less than";
}
enum 5 {
description "Less than or equal to";
}
enum 6 {
description "Equal to";
}
enum 7 {
description "Not equal to";
}
enum 8 {
description "IN";
Chen, et al. Expires February 6, 2016 [Page 19]
Internet-Draft SUPA ECA Policy Data Model August 2015
}
enum 9 {
description "NOT IN";
}
enum 10 {
description "SET";
}
enum 11 {
description "CLEAR";
}
}
}
leaf supa-policy-value {
description
"The value of the variable";
type uint32;
}
}
container event-list{
description
"The condition clauses. Each one can be an encoded or boolean
clause";
container event-name {
choice clauseType{
case encoded {
uses supa-encoded-clause;
}
case boolean {
uses supa-boolean-clause;
}
}
}
}
container condition-list{
description
"The condition clauses. Each one can be an encoded or boolean
clause, and conjuncted by AND or OR";
container condition-name {
choice clauseType{
case encoded {
uses supa-encoded-clause;
}
case boolean {
uses supa-boolean-clause;
}
}
}
Chen, et al. Expires February 6, 2016 [Page 20]
Internet-Draft SUPA ECA Policy Data Model August 2015
}
container action-list{
description
"Defines actions clause here.";
choice actionName {
description
"Each action has unique attributes so a choice statement
here to allow self-defined action without changing
structure.";
case actionType {
leaf actionElement {
type empty;
}
}
}
}
}
}
}
<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
Chen, et al. Expires February 6, 2016 [Page 21]
Internet-Draft SUPA ECA Policy Data Model August 2015
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.
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.
+--rw supa-policy-target
+--rw profileType? string
+--rw asDomainName? string
+--rw adminSubnetwork? string
+--rw businessTypeName? string
+--rw instance
+--rw (instanceName)?
+--:(flow-filter)
+--rw dscp? uint32 //5
+--rw src-ip-addr? string //10.111.10.1
+--rw dst-ip-addr? string //10.112.10.1
+--rw src-port? uint32 //8080
+--rw dst-port? uint32 //8090
Figure 12: The snippet of specific policy target
Note that, the supa-policy-target is reusable and extensiable 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 February 6, 2016 [Page 22]
Internet-Draft SUPA ECA Policy Data Model August 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 encoded clause and condition clause should be encoded
clause. Then design the event and condition clause by filling in the leaf. Note
that the choice of clause type does include in YANG data model but will be
accomplished in NETCONF via <edit-config> operation.
+--rw supa-policy-statement
+--rw event-list
| +--rw event-flowEntry
| +--:(encoded)
| | +--rw supa-clause-content? string //flow entry
| | +--rw supa-clause-format? string //default
+--rw condition-list
| +--rw condition-linkThreshold
| +--:(encoded)
| +--rw supa-clause-content? string //bandwidth > 8m
| +--rw supa-clause-format? string //default
+--rw action-list
+--rw (actionName)?
+--:(car)
+--rw cir? uint32 //20
+--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. So the user can add
Chen, et al. Expires February 6, 2016 [Page 23]
Internet-Draft SUPA ECA Policy Data Model August 2015
their own definition of action in the case node by specifying all the action
elements.
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.
6. Specific ECA Policy Data Model for service flow policy
6.1. Abstract Specific ECA Policy Data Model Hierarchy
Figure 15 shows the structure of specific ECA policy data model.
Chen, et al. Expires February 6, 2016 [Page 24]
Internet-Draft SUPA ECA Policy Data Model August 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 (instanceName)?
| +--:(flow-filter)
| +--rw dscp? uint32
| +--rw src-ip-addr? string
| +--rw dst-ip-addr? string
| +--rw src-port? uint32
| +--rw dst-port? uint32
+--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-flowEntry
| +--rw (clauseType)?
| +--:(encoded)
| | +--rw supa-clause-content? string
| | +--rw supa-clause-format? string
| +--:(boolean)
| +--rw supa-policy-variable? string
| +--rw supa-policy-operator? enumeration
| +--rw supa-policy-value? uint32
+--rw condition-list
| +--rw condition-linkThreshold
Chen, et al. Expires February 6, 2016 [Page 25]
Internet-Draft SUPA ECA Policy Data Model August 2015
| +--rw (clauseType)?
| +--:(encoded)
| | +--rw supa-clause-content? string
| | +--rw supa-clause-format? string
| +--:(boolean)
| +--rw supa-policy-variable? string
| +--rw supa-policy-operator? enumeration
| +--rw supa-policy-value? uint32
+--rw action-list
+--rw (actionName)?
+--:(remark)
| +--rw remarkVlanPri? uint32
| +--rw remarkDscpValue? uint32
| +--rw applySLALevel? string
+--:(car)
| +--rw cir? uint32
| +--rw pir? uint32
| +--rw Cbs? uint32
| +--rw Pbs? uint32
+--:(redirect)
+--rw egressInterface? string
+--rw egressVpnName? uint32
+--rw encapType? enumeration
+--rw encapValue? uint32
+--rw serviceId? uint32
Figure 15: The structure of specific ECA policy data model
Chen, et al. Expires February 6, 2016 [Page 26]
Internet-Draft SUPA ECA Policy Data Model August 2015
6.2. SUPA specific ECA Policy Data Model in YANG Module
<CODE BEGINS>
module ietf-supa-policy {
namespace "urn:ietf:params:xml:ns:yang:ietf-supa-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 specific ECA policy data model for service flow
refining from SGPIM and EPRIM.
Terms and Acronyms
";
revision 2015-08-05 ;
container supa-policy{
description
"This defines a specific ECA policy data model for service flow.";
leaf supa-policy-name {
description
"The name of the policy is service flow policy";
type string;
}
leaf supa-policy-priority {
description
"The value is 0 here denotes highest priority.";
type uint8;
}
container supa-policy-validity-period {
description
"The policy will be valid 9am-9am daily";
leaf start {
type yang:date-and-time;
}
leaf end {
type yang:date-and-time;
}
leaf duration {
type uint32;
}
Chen, et al. Expires February 6, 2016 [Page 27]
Internet-Draft SUPA ECA Policy Data Model August 2015
leaf periodicity {
type enumeration {
enum daily {
}
enum monthly {
}
}
}
}
container supa-policy-target {
description
"";
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 {
choice instanceName {
description
"The policy will be working on a flow. The following
attributes are filled in by the user to specify which flow to
be picked up";
case flow-filter{
leaf dscp {
description
"dscp value of the indicated flow";
type uint32;
config "true";
default "0";
}
leaf src-ip-addr{
Chen, et al. Expires February 6, 2016 [Page 28]
Internet-Draft SUPA ECA Policy Data Model August 2015
description
"source ip addresses of the flow";
type string;
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";
}
}
}
}
}
container supa-policy-atomic {
description
"Define an atomic ECA policy rule";
container supa-ECA-policy-rule {
description
"ECA policy for service flow.";
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{
Chen, et al. Expires February 6, 2016 [Page 29]
Internet-Draft SUPA ECA Policy Data Model August 2015
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{
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
"";
container supa-policy-events {
description
"";
leaf has-policy-events {
description
"TRUE, it has an event to trigger evaluation of
condition.";
type boolean;
}
Chen, et al. Expires February 6, 2016 [Page 30]
Internet-Draft SUPA ECA Policy Data Model August 2015
}
container supa-policy-conditions {
description
"";
leaf has-policy-conditions {
description
"TRUE, it has conditions.";
type boolean;
}
leaf conjunctive-type {
description
"Only one condition clause, choose '0'.";
type enumeration {
enum 0 {
description "";
}
enum 1 {
description "";
}
}
}
}
container supa-policy-actions {
description
"";
leaf action-execution {
description
"Only one action, choose '0'.";
type enumeration{
enum 0 {
description "";
}
enum 1 {
description "";
}
}
}
}
}
}
}
container supa-policy-statement {
grouping supa-encoded-clause{
description "";
leaf supa-clause-content {
description
"";
Chen, et al. Expires February 6, 2016 [Page 31]
Internet-Draft SUPA ECA Policy Data Model August 2015
type string;
}
leaf supa-clause-format {
description
"";
type string;
}
}
grouping supa-boolean-clause{
description
"";
leaf supa-policy-variable {
description
"";
type string;
}
leaf supa-policy-operator {
type enumeration {
enum 0 {
description "Unknown";
}
enum 1 {
description "Match";
}
enum 2 {
description "Greater than";
}
enum 3 {
description "Greater than or equal to";
}
enum 4 {
description "Less than";
}
enum 5 {
description "Less than or equal to";
}
enum 6 {
description "Equal to";
}
enum 7 {
description "Not equal to";
}
enum 8 {
description "IN";
}
enum 9 {
description "NOT IN";
Chen, et al. Expires February 6, 2016 [Page 32]
Internet-Draft SUPA ECA Policy Data Model August 2015
}
enum 10 {
description "SET";
}
enum 11 {
description "CLEAR";
}
}
}
leaf supa-policy-value {
description
"";
type uint32;
}
}
container event-list{
description
"";
container event-flowEntry {
description
"The flow entry event will choice 'encoded clause' to denote
the event.";
choice clauseType{
case encoded {
description
"The value of supa-clause-content is 'flow entry'. The
value of supa-clause-format is 'asic II'";
uses supa-encoded-clause;
}
case boolean {
uses supa-boolean-clause;
}
}
}
}
container condition-list{
description
"";
container condition-linkThreshold {
description
"The link threshold condition will choice 'boolean clause' to
denote the condition.";
choice clauseType{
case encoded {
uses supa-encoded-clause;
}
case boolean {
Chen, et al. Expires February 6, 2016 [Page 33]
Internet-Draft SUPA ECA Policy Data Model August 2015
description
"The value of supa-policy-variable leaf is link
'bandwidth'.
The value of supa-policy-operator is '3' which
is 'Greater than or equal to'. The value of supa-
policy-value is '8'.";
uses supa-boolean-clause;
}
}
}
}
container action-list{
description
"Defines actions clause here.";
choice actionName {
description
"Each action has unique attributes so a choice statement
here to allow self-defined action without changing
structure.";
case remark {
leaf remarkVlanPri {
description
"The 802.1p priority value";
type uint32;
}
leaf remarkDscpValue {
description
"The DSCP value";
type uint32;
}
leaf applySLALevel {
description
"SLA level";
type string;
}
}
case car {
leaf cir {
description
"Committed information rate";
type uint32;
}
leaf pir {
description
"Peak information rate";
type uint32;
}
Chen, et al. Expires February 6, 2016 [Page 34]
Internet-Draft SUPA ECA Policy Data Model August 2015
leaf Cbs {
description
"Committed burst size";
type uint32;
}
leaf Pbs {
description
"Peak burst size";
type uint32;
}
}
case redirect {
leaf egressInterface {
description
"SFF2SF interface, from internet to server";
type string;
}
leaf egressVpnName {
description
"egress redirect vpn name";
type uint32;
}
leaf encapType {
description
"tunnelType";
type enumeration{
enum vlan;
enum vxlan;
}
}
leaf encapValue {
description
"Remark value";
type uint32;
}
leaf serviceId {
description
"Service ID of the flow";
type uint32;
}
}
}
}
}
}
}
<CODE ENDS>
Chen, et al. Expires February 6, 2016 [Page 35]
Internet-Draft SUPA ECA Policy Data Model August 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
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, 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.
Chen, et al. Expires February 6, 2016 [Page 36]
Internet-Draft SUPA ECA Policy Data Model August 2015
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.
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
Chen, et al. Expires February 6, 2016 [Page 37]