ECA Policy YANG Data Model
draft-chen-supa-eca-data-model-01
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-07-23 | ||
| 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-01
Network Working Group M. Chen
Internet Draft BBIX, Inc.
Intended status: Standard Track L.Contreras
Expires: January 22, 2016 Telefonica I+D
M. Fukushima
KDDI R&D Labs. Inc.
July 22, 2015
ECA Policy YANG Data Model
draft-chen-supa-eca-data-model-01
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 core 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 by metadata. 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 January 22,2016 [Page 1]
Internet-Draft SUPA ECA Policy Data Model July 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 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 .........................5
3.1. ECA Policy Data Model Design ............................6
3.1.1. supa-ECA-policy-rule sub class ......................6
3.1.2. supa-ECA-component sub class ........................7
3.2. supa-policy-statement Design for ECA policy data model ..7
3.2.1. supa-encoded-clause sub class .......................8
3.2.2. supa-boolean-clause sub class .......................8
3.3. supa-policy-term class ..................................9
4. Abstract ECA Policy Data Model Hierarchy ....................10
5. SUPA ECA Policy Data Model in YANG Module ...................12
6. Data Model Example ..........................................18
7. Security Considerations .....................................21
8. IANA Considerations .........................................22
9. Contributor List ............................................22
10. Acknowledgments ............................................22
11. References .................................................22
11.1. Normative References ..................................22
11.2. Informative References ................................22
Chen, et al. Expires January 22,2016 [Page 2]
Internet-Draft SUPA ECA Policy Data Model July 2015
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
Chen, et al. Expires January 22,2016 [Page 3]
Internet-Draft SUPA ECA Policy Data Model July 2015
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>.
<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
Chen, et al. Expires January 22,2016 [Page 4]
Internet-Draft SUPA ECA Policy Data Model July 2015
3. SUPA Policy Modules Top Level Design
In this section, a 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 SPGIM model
-supa-policy-atomic: a Policy that can be used in a stand-alone
manner
-supa-policy-composite: used to build hierarchies of Policies
-supa-policy-statement: used to define the content of a supa-
policy
-supa-policy-term: used to define variables, operators, and
values in a supa-policy-statement
-supa-policy-target: the managed object that a supa-policy
monitors and/or controls the state of
-supa-policy-metadata: specifies descriptive and/or prescriptive
information about a supa-policy object
+--rw supa-policy
| ....
+--rw supa-policy-atomic
| | ....
+--rw supa-policy-composite
| | ....
+--rw supa-policy-statement
| | ....
+--rw supa-policy-target? string
+--rw supa-policy-term
| | ....
+--rw supa-policy-metadata?
| ....
Figure 2: Top level design of SUPA policy data model
Chen, et al. Expires January 22,2016 [Page 5]
Internet-Draft SUPA ECA Policy Data Model July 2015
3.1. 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 a supa-boolean-clause. 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 3: 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. A supa-policy-atomic has event,
condition, and action clauses; each of these is created by either
a supa-boolean-clause or a supa-encoded-clause.
-A supa-ECA-component defines supa-event, supa-condition, and
supa-action objects that are used to create the event, condition,
and action clauses of a supa-ECA-policy-rule.
3.1.1. supa-ECA-policy-rule sub class
Similar to supa-policy class, the composite pattern is applied to
the supa-ECA-policy-rule class, enabling it to be used as either a
stand-alone policy rule or as a hierarchy of policy rules.
+--rw supa-ECA-policy-rule
+--rw supa-ECA-policy-rule-atomic
| | ....
+--rw supa-ECA-policy-rule-composite
| ....
Figure 4: The snippet of supa-ECA-policy-rule sub class
-A supa-ECA-policy-rule-atomic class represents a SUPA ECA Policy
Rule that can operate as a single, stand-alone, manageable object.
Put another way, a supa-ECA-policy-rule-atomic object can NOT be
modeled as a set of hierarchical supa-ECA-policy-rule objects; if
Chen, et al. Expires January 22,2016 [Page 6]
Internet-Draft SUPA ECA Policy Data Model July 2015
this is required, then a supa-ECA-policy-rule-composite object
must be used.
-A supa-ECA-policy-rule-composite class represents a SUPA ECA
Policy Rule as a hierarchy of Policy objects, where the hierarchy
contains instances of a supa-ECA-policy-rule-atomic and/or supa-
ECA-policy-rule-composite object.
3.1.2. supa-ECA-component sub class
The principal subclasses of supa-policy-term that are defined in
this version of this document are supa-policy-event, supa-policy-
condition, and supa-policy-action. More details will be in next
version. The snippet of supa-ECA-component sub class is shown in
figure 5.
+--rw supa-ECA-component
+--rw has-policy-events? boolean
+--rw has-policy-conditions? boolean
+--rw has-policy-actions? Boolean
Figure 5: The snippet of supa-ECA-component objects
3.2. 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]. As shown in figure
6, there are two principal subclasses of supa-policy-statement:
-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.2.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.2.2.
Chen, et al. Expires January 22,2016 [Page 7]
Internet-Draft SUPA ECA Policy Data Model July 2015
+--rw supa-policy-statement
+--rw supa-encoded-clause
| | ....
+--rw supa-boolean-clause
+--rw supa-boolean-clause-atomic
| | ....
Figure 6: The snippet of supa-policy-statement
3.2.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 7: The snippet of supa-encoded-clause
3.2.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 defined to be abstract - only instances
of the supa-boolean-clause-atomic and/or supa-boolean-clause-
Chen, et al. Expires January 22,2016 [Page 8]
Internet-Draft SUPA ECA Policy Data Model July 2015
composite classes can be used to construct a supa-boolean-clause.
As shown in figure 8, 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-boolean-clause-atomic
+--rw supa-policy-variable? string
+--rw supa-policy-operator? enumeration
+--rw supa-policy-value? uint32
Figure 8: The snippet of supa-boolean-clause
3.3. supa-policy-term class
The principal subclasses of supa-policy-term that are defined in
this version of this document are supa-policy-event, supa-policy-
condition, and supa-policy-action.
-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.
Chen, et al. Expires January 22,2016 [Page 9]
Internet-Draft SUPA ECA Policy Data Model July 2015
+--rw supa-policy-term
+--rw supa-policy-variable? string
+--rw supa-policy-operator? enumeration
+--rw supa-policy-value? uint32
Figure 9: The snippet of supa-policy-term
4. Abstract ECA Policy Data Model Hierarchy
Figure 10 shows the structure of abstract SUPA ECA policy data
model.
Chen, et al. Expires January 22,2016 [Page 10]
Internet-Draft SUPA ECA Policy Data Model July 2015
module: ietf-supa-policy
+--rw supa-policy
+--rw supa-policy-name? string
+--rw supa-policy-type? enumeration
+--rw applicable-service-type? enumeration
+--rw supa-policy-priority? uint8
+--rw supa-policy-validity-period
| +--rw start? yang:date-and-time
| +--rw end? yang:date-and-time
| +--rw duration? uint32
| +--rw periodicity? enumeration
+--rw supa-policy-atomic
| +--rw supa-ECA-policy-rule
| | +--rw policy-rule-deploy-status? enumeration
| | +--rw policy-rule-exec-status? enumeration
| | +--rw supa-ECA-policy-rule-atomic
| | +--rw supa-ECA-policy-rule-composite
| +--rw supa-ECA-component
| +--rw has-policy-events? boolean
| +--rw has-policy-conditions? boolean
| +--rw has-policy-actions? boolean
+--rw supa-policy-composite
+--rw supa-policy-statement
| +--rw supa-encoded-clause
| | +--rw supa-clause-content? string
| | +--rw supa-clause-format? string
| +--rw supa-boolean-clause
| +--rw supa-boolean-clause-atomic
| +--rw supa-policy-variable? string
| +--rw supa-policy-operator? enumeration
| +--rw supa-policy-value? uint32
+--rw supa-policy-target? string
+--rw supa-policy-term
| +--rw supa-policy-variable? string
| +--rw supa-policy-operator? enumeration
| +--rw supa-policy-value? uint32
+--rw supa-policy-metadata? uint32
Figure 10: The structure of abstract SUPA ECA policy data model
Chen, et al. Expires January 22,2016 [Page 11]
Internet-Draft SUPA ECA Policy Data Model July 2015
5. SUPA 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-inet-types {
prefix inet;
}
organization "IETF";
contact
"Editor: Maoke Chen";
description
"This YANG module defines a component that describing
the ECA policy data model refining from SGPIM and EPRIM.";
Terms and Acronyms
revision 2015-07-22 {
description
"Initial revision.";
reference
" ECA Policy YANG Data Model refining from SGPIM and
EPRIM";
}
container supa-policy{
description
"Top level class of policy model that can be integrated into
another model";
leaf supa-policy-name {
type string;
description
"The name of policy";
}
leaf supa-policy-type {
type enumeration {
enum local {
description "local";
}
enum global {
Chen, et al. Expires January 22,2016 [Page 12]
Internet-Draft SUPA ECA Policy Data Model July 2015
description "globe";
}
}
}
leaf applicable-service-type {
type enumeration {
enum local {
description "local";
}
enum globe {
description "globe";
}
}
}
leaf supa-policy-priority {
type uint8;
}
container supa-policy-validity-period {
description
"The validity time period of the policy will define the
start time and end time of the policy on a daily or monthly
fashion periodicity. ";
leaf start {
type yang:date-and-time;
}
leaf end {
type yang:date-and-time;
}
leaf duration {
type uint32;
}
leaf periodicity {
type enumeration {
enum daily {
description "daily";
}
enum monthly {
description "monthly";
}
}
}
}
container supa-policy-atomic {
description
Chen, et al. Expires January 22,2016 [Page 13]
Internet-Draft SUPA ECA Policy Data Model July 2015
"A sub class of policy which define a Policy that can be
used in a stand-alone manner";
container supa-ECA-policy-rule {
description "The event-condition-action 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{
description "currently executing (operational mode)";
}
enum 4{
description "executed and SUCEEDED (test mode)";
}
enum 5{
description "executed and FAILED (test mode)";
Chen, et al. Expires January 22,2016 [Page 14]
Internet-Draft SUPA ECA Policy Data Model July 2015
}
enum 6{
description "currently executing (test mode)";
}
}
}
container supa-ECA-policy-rule-atomic {
description "A SUPAECAPolicyRuleAtomic class
represents a SUPA ECA Policy Rule that can operate as
a single, stand-alone, manageable object.";
}
container supa-ECA-policy-rule-composite {
description "A SUPAECAPolicyRuleComposite class
represents a SUPA ECA Policy
Rule as a hierarchy of Policy objects, where the
hierarchy contains
instances of a SUPAECAPolicyRuleAtomic and/or
SUPAECAPolicyRuleComposite object.";
}
}
container supa-ECA-component{
leaf has-policy-events {
type boolean;
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-conditions {
type boolean;
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-actions {
type boolean;
description
"A set of actions that should be triggered as part of the
policy execution: This enables the service management to
provision the service.";
}
}
Chen, et al. Expires January 22,2016 [Page 15]
Internet-Draft SUPA ECA Policy Data Model July 2015
}
container supa-policy-composite {
description "SUPA Policy Composite is used to build
hierarchies of Policies";
}
container supa-policy-statement {
description
"A SUPA Policy Statement is an abstract class that contains
an individual or group of related functions; this set of
functions defines a set of actions to take. Examples of
actions include getting information, stating facts about the
system being managed, writing a change to a configuration of
one or more managed objects, and querying information about
one or more managed objects.";
container 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 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;
}
}
container supa-boolean-clause{
description "SUPABooleanClause, which defines a
SUPAPolicyStatement as a set of one or more clauses;
Chen, et al. Expires January 22,2016 [Page 16]
Internet-Draft SUPA ECA Policy Data Model July 2015
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";
container supa-boolean-clause-atomic {
description "This is a mandatory abstract class that
represents a SUPABooleanClause that can operate as a
single, stand-alone, manageable object.";
leaf supa-policy-variable {
type string;
description "The definition of the variable";
}
leaf supa-policy-operator {
type enumeration {
enum 0 {
description "Equal to";
}
enum 1 {
description "Larger than";
}
enum 2 {
description "Less than";
}
}
}
leaf supa-policy-value {
type uint32;
description "Vaule of the variable";
}
}
}
}
leaf 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.";
type string;
}
container supa-policy-term {
description "The principal subclasses of SUPAPolicyTerm that
are defined in this version of this document are
SUPAPolicyVariable, SUPAPolicyOperator, and SUPAPolicyValue.
These terms enable generic statements to be created from a
Chen, et al. Expires January 22,2016 [Page 17]
Internet-Draft SUPA ECA Policy Data Model July 2015
set of reusable terms.";
leaf supa-policy-variable {
type string;
description "The definition of the variable";
}
leaf supa-policy-operator {
type enumeration {
enum 0 {
description "Equal to";
}
enum 1 {
description "Larger than";
}
enum 2 {
description "Less than";
}
}
}
leaf supa-policy-value {
type uint32;
description "The value of the variable";
}
}
leaf supa-policy-metadata {
type uint32;
}
}
}<CODE ENDS>
6. Data Model Example
This section will provide one example to show how this ECA policy
data model can be mapped into real configuration.
For a service flow policy, if a flow matches certain conditions,
then some actions to this flow will be performed. As shown below:
Chen, et al. Expires January 22,2016 [Page 18]
Internet-Draft SUPA ECA Policy Data Model July 2015
+--supa-policy-composite (flow-poliy-entry)
+--supa-ECApolicy-rule-atomic (flow-filter-condition,
flow-classifier-action)
+--for each filter-condition node that is not an
identityref
+--supa-boolean-clause-atomic (flow-filter-
condition)
+--supa-policy-variable (source-ip-address
variable)
+--supa-policy-operator (typically "MATCH"
default)
+--supa-policy-value (condition value e.g.
"10.111.10.1")
+--supa-boolean-clause-atomic (flow-filter-
condition)
+--supa-policy-variable (destnation-ip-address
variable)
+--supa-policy-operator (typically "MATCH"
default)
+--supa-policy-value (condition value e.g.
"10.112.10.1")
+--supa-boolean-clause-atomic (flow-filter-
condition)
+--supa-policy-variable (source-port variable)
+--supa-policy-operator (typically "MATCH"
default)
+--supa-policy-value (condition value e.g.
"8080")
+--supa-boolean-clause-atomic (flow-filter-
condition)
+--supa-policy-variable (destnation-port
variable)
+--supa-policy-operator (typically "MATCH"
default)
+--supa-policy-value (condition value e.g.
"8090")
+--for each action node that is not an identityref
+--supa-boolean-clause-Composite
+--supa-boolean-clause-atomic
+--supa-policy-action-name (action name e.g.
"redirect")
+--supa-policy-action-variable (action value
"interface")
+--supa-policy-action-value (action value
"Gre-Tunnel-IF-10")
+--supa-policy-Composite (child-policy-)
Chen, et al. Expires January 22,2016 [Page 19]
Internet-Draft SUPA ECA Policy Data Model July 2015
Actually, the ECA policy data model only specify the type of each
node, e.g., the type of the supa-policy-variable is string, and
the real value of a "condition" clause can be source-ip-address.
After filling up all the tags in the data model, the configuration
related data model denotes to certain policy configuration which
is dependent on the use case. Then the data model is used to guide
the XML instance as shown below:
Chen, et al. Expires January 22,2016 [Page 20]
Internet-Draft SUPA ECA Policy Data Model July 2015
<flow-poliy>
<flow-poliy-entry>
<flow-poliy-filter>
<flow-poliy-filter-condition>
<SourceIP><operator>Match</operator><Vlaue>10.111.10.1</value><
/SourceIP>
<SourcePort><operator>Match</operator><Vlaue>8080</value></Sour
cePort>
<DestIP><operator>Match</operator><Vlaue>10.112.10.2</value></D
estIP>
<DestPort><operator>Match</operator><Vlaue>8090</value></DestPo
rt>
<flow-poliy-filter-condition>
<flow-poliy-filter>
<actionList>
<action>
<actionName>redirect</actionName>
<actionvariable>node</actionvariable>
<actionvariablevalue>dc1</actionvariablevalue>
<actionvariable>interface</actionvariable>
<actionvariablevalue>Gre-Tunnel-IF-1</actionvariablevalue>
</action>
<action>
<actionName>redirect</actionName>
<actionvariable>node</actionvariable>
<actionvariablevalue>pop1</actionvariablevalue>
<actionvariable>interface</actionvariable>
<actionvariablevalue>Gre-Tunnel-IF-2</actionvariablevalue>
</action>
<action>
<actionName>redirect</actionName>
<actionvariable>node</actionvariable>
<actionvariablevalue>pop2</actionvariablevalue>
<actionvariable>interface</actionvariable>
<actionvariablevalue>Gre-Tunnel-IF-3</actionvariablevalue>
</action>
</actionList>
</flow-poliy-entry>
</flow-poliy>
7. Security Considerations
TBD
Chen, et al. Expires January 22,2016 [Page 21]
Internet-Draft SUPA ECA Policy Data Model July 2015
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: Juergen Schoenwaelder, Yiyong Zha.
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
Abstractions (SUPA)", draft-strassner-supa-generic-policy-info-
model-01 (work in progress), May 2015.
Chen, et al. Expires January 22,2016 [Page 22]
Internet-Draft SUPA ECA Policy Data Model July 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 January 22,2016 [Page 23]