| Network Working Group | D. King |
| Internet-Draft | Old Dog Consulting |
| Intended status: Standards Track | Z. Wang |
| Expires: September 10, 2015 | L. Dunbar |
| Q. Wu | |
| Huawei | |
| March 9, 2015 |
A Network Policy Framework using YANG Data Models
draft-wang-netmod-yang-policy-dm-01
The purpose of a Network Policy System is to manage and control a network as a whole. To achieve this purpose, network operators need to control the behavior of the individual entities that comprise the network, and this control needs to be harmonized across multiple entities. For example, to control the access to a network, the operator must control the behavior at all of network elements at the edge of the network, and must apply consistent policies at those elements.
Network Services are provided by network operators to their customers using the resources of the network. To effectively control a network, the operator must have knowledge of network services supported by the network, as well as knowledge of the network resource utilization and the capabilities of each network entity. Control of the network to deliver the network services will involve applying policy at individual network entities and across the whole network, as well as controlling and allocating the resources within the network.
This document describes a common framework and common core YANG data model for network policies. The framework can be applied to deliver various different network services by controlling the policies that enable features such as Constraint-based Routing, Network QoS, Traffic engineering, network management, etc. In future, the core data model could be augmented by additional YANG data modules modeling and configuring policy-related protocols and functions. The policy data model described in this document provides common building blocks for such extensions.
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). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on September 10, 2015.
Copyright (c) 2015 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.
The purpose of a Network Policy System is to manage and control a network as a whole. To achieve this purpose, network operators need to control the behavior of the individual entities that comprise the network, and this control needs to be harmonized across multiple entities. For example, to control the access to a network, the operator must control the behavior at all of network elements at the edge of the network, and must apply consistent policies at those elements.
Network Services are provided by network operators to their customers using the resources of the network. To effectively control a network, the operator must have knowledge of network services supported by the network, as well as knowledge of the network resource utilization and the capabilities of each network entity. Control of the network to deliver the network services will involve applying policy at individual network entities and across the whole network, as well as controlling and allocating the resources within the network. Policies will often be managed for the operator by a network policy system or policy management system.
Network service configuration can be applied based on the needs of network applications. For example, more precise allocation of network resources to a network service can be achieved with better visibility of the network. To achieve this, the policy management system is often forced to limit itself to manage only those features common to the management interfaces common to the majority of the entities in the network since other approaches require the policy management system to be aware of the fine-grain differences between the management interfaces of each release of each different network entity: implementation of policy across networks is still piecemeal and proprietary.
The Policy Core Information Model [RFC3060] models the network as a state machine and uses corresponding policy to aggregate a set of policy rules to control relevant devices at any given time.
Policies can either be used in a stand-alone policy rule or aggregated into policy group functions [RFC3060]. In order to perform more elaborate functions, [RFC3460] defines a policy set to aggregate policy rules and policy groups. A set of conditions is associated with a policy rule to specify when the policy rule is applicable. If the conditions evaluate to true, then a corresponding set of actions will be executed.
This document describes a common framework and common core YANG data model for network policies. The framework can be applied to deliver various different network services by controlling the policies that enable features such as Constraint-based Routing, Network QoS, Traffic engineering, network management, etc. In future, the core data model could be augmented by additional YANG data modules modeling and configuring policy-related protocols and functions. The policy data model described in this document provides common building blocks for such extensions.
The following terms defined in [RFC3198] are also used in this document:
Additionally, we defines the following terms based on the concepts described in [RFC3198]:
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
Network Service Definition
|
-----------|-----------------------------------------------
| V |
| +--------------------+ +--------------------+ |
| | Policy | | Policy Repository | |
| | Management System |-------->| (Directory Server, | |
| +--------------------+ | Database, etc.) | |
| * * +--------------------+ |
| * * | |
| * * | |
| * | |
| * +-------------------------------+ |
| * | |
| * | * |
| * | * |
| * | * * * * * * * * * * * * * * * * |
| * | * |
| * | * |
----*-------|--------------------------------------*-------
* | *
---------+---------- Protocol for --------------------
| Policy Provider | Policy Mechanism | Policy Consumer |
| |<------------------>| |
-------------------- --------------------
Figure 2: Reference Model Overview
A network service definition is derived from the contractual service-level agreements (SLA) established between the network operator and the customer. Conversely, the SLA is defined with the definition of the network service in mind.
The network service definition is injected into the policy management system as policy prescription. The policy management system provides mapping to and from the lower-level policy rule representation. A policy repository is used for persistent storage and retrieval of policy rules.
The policy rules are network device-independent and provide a deterministic set of policies for managing network resources in the policy domain. They are composed by the policy provider and consumed by policy consumer. Before composing a policy rule, the policy management system needs to verify whether the network resource can meet service requirements in the network service definition by looking up resource distribution map. If network resources can meet the service requirements, the policy management system will produce the policy rules, store them in the policy repository using a defined schema, and communicate with the corresponding policy provider. The policy provider is responsible for communicating the policy rules to the policy consumer. The policy mechanisms used by both the policy provider and the policy consumer allow for configuring the necessary logic in the network components. When changes are made to the policies stored in the policy repository, the policy provider need to be informed.
In this document we define a set of common core policy models. The YANG models defined here are generic such that they can be extended for technology- specific needs.
The Generic Policy YANG model acts as the root for other policy YANG models. This allows users to access policies for different technologies through a uniform API. It also provides a nested policy workflow.
Figure 3 depicts the relationship between the different policy YANG models, and shows how they are all related to the Generic Policy YANG model. Some technologies may have different sub-technologies. As an example, consider Network QoS: this could employ either Diffserv or Inteserv as a QoS methodology. The Generic Policy YANG model provides a framework where technology-specific YANG models can inherit constructs from the base YANG model or from a parent model without needing to redefine them for each sub-technology.
---------
| Generic |
| Policy |
----+----
|
|
+-----------+-------+------------+-----. . .-----+
| | | |
-----+----- ----+---- ----+---- ---------
| QoS | | ACL | | Routing |. . .| foo |
| Policy | | Policy | | Policy | | Policy |
-+--------- ----+---- ----+---- ----+----
| | | | |
-------+- -+------- | ----+---- ----+----
| IntServ | | DiffServ| | | BGP |. . .| foo |
| Policy | | Policy | | |sub-tech | |sub-tech |
---+----- -----+--- | ----+---- ----+----
| | | | |
| | | | |
---+---------------+-----------+------------+-------------+---
| Uniform API |
--------------------------------------------------------------
Figure 3: Relationship of Policy YANG Models to the Generic Policy YANG Model
In this document we define a common core policy model including several abstract nodes such as PolicyConditon, PolicyAction, PolicyValue, PolicyVariable, etc. A new model can inherit abstract nodes from the common core model to derive new instance class nodes or abstract nodes. The purpose of this document is to reuse existing class/block definitions, such as PolicyCondition, as much as possible.
Policies can be used either in a stand-alone fashion when they are called policy rules, or can be aggregated into policy groups to perform more elaborate functions [RFC3060]. And in accordance with [RFC3460], a policy set is inserted into the inheritance hierarchy above both policy group and policy rule. In this document, we define an abstract common core network policy block, and specific policies can inherit and augment from it.
This section describes the common core network policy YANG model structure and also describes the separate elements:
Figure 4 shows the high-level structure of the ietf-policy YANG model.
module: ietf-policy
|
|- rw policy-set!
| | ....
| +--rw policy-group* [group-name]
| | ....
| +--rw policy-rule* [rule-name]
| | ....
|-rw policy-group!
|-rw policy-rule!
Figure 4: High-Level Structure of the ietf-policy YANG Model
A policy-set contain a policy-role leaf, a policy-decision-strategy leaf, a list of policy-groups, and a list of policy-rules. A policy-set refers to a set of policies that can be applied to multiple device that fulfil the same role within the network.
Figure 5 shows the snippet of a policy-set.
module: ietf-policy
+--rw policy-set!
+--rw PolicyRole role-type
+--rw PolicyDecisionStrategy py:policy-decision-strategy
+--rw policy-rule
| +--rw name leafref
+--rw policy-group
+--rw name leafref
......
Figure 5: Snippet of the Data Hierarchy Related to policy-set
In [RFC4011] the policy-role is described as "A role is an administratively specified characteristic of a managed element. As a selector for policies, it determines the applicability of the policy to a particular managed element."
Some examples of the policy-role type have already been defined in [RFC4011], such as political, financial, legal, geographical, and architectural characteristics.
In this document, the policy-role is defined as an abstract property. Specific policies can specify corresponding roles. For example, in MPLS management one Label Switched Path (LSP) can be assigned various roles including "primary", "secondary", "backup", and "tunnel". The secondary LSP can be used to carry primary LSP traffic so that network resource utilization can be banlanced. When the primary LSP fails, the backup LSP can be activiated so that network high availability can be achieved. Tunneled LSPs can be used by other LSPs to provide a routing service or to support traffic engineering.
Policies can be used in either as stand-alone policy rules or can be aggregated into policy groups functions [RFC3060].
Figure 6 shows the snippet of a policy-rule.
module: ietf-policy
+--rw policy-rules!
+--rw name string
+--rw policy-rule* [name]
+--rw name string
+--rw Enabled boolean
+--rw Mandatory boolean
+--rw ConditionListType py:policy-conditionlist-type
+--rw SequencedActions py:policy-sequenced-actions
+--rw ExecutionStrategy py:policy-execution-strategy
+--rw policy-condition
| +--rw name leafref
+--rw policy-action
+--rw name leafref
.......
Figure 6: Snippet of the Data Hierarchy Related to policy-rule
Policy-group is a generalized container in the form of a list. This can contain a set of policy-rules that belong to the same group (e.g., having the same role for various policy-rules). A policy-group list can also contains other policy-group instances, but a policy group may not contain instances of both policy-group and policy-rule [RFC3060].
Figure 7 shows the snippet of a policy-group list.
module: ietf-policy
+--rw policy-group!
+--rw name string
+--rw policy-groups*[name]
| +--rw name leafref
| +--rw policy-rules*[name]
+--rw name eafref
....
Figure 7: Snippet of the Data Hierarchy Related to policy-group
A policy-rule usually follows the "If Condition then Action" semantics. In this section we define an abstract PolicyCondition block that can be re-used flexibly. For an extended policy YANG model, the policy-rule can extend and re-use the PolicyConditon block.
Figure 8 shows the snippet of a PolicyCondition block.
module: ietf-policy
+--rw policy-condition!
+--rw name string
Figure 8: Snippet of the Data Hierarchy Related to PolicyCondition
A policy-rule usually follows the "If Condition then Action" semantics. In this section we define an abstract PolicyAction block which can be re-used flexibly. For an extended policy YANG model, the policy-rule can extend and re-use the PolicyAction block.
Figure 9 shows the snippet of a PolicyAction block.
module: ietf-policy
+--rw policy-action!
+--rw name string
.....
Figure 9: Snippet of the Data Hierarchy Related to PolicyAction
A simple condition models an elementary Boolean expression of the form "variable matches value". In this section we define an abstract PolicyVariable block which can be re-use flexibly. For an extended policy YANG model, the condition can extend and re-use the PolicyVariable block.
Figure 10 shows the snippet of a PolicyVariable block.
module: ietf-policy
+--rw policy-variable!
+--rw name string
Figure 10: Snippet of the Data Hierarchy Related to PolicyVariable
A simple condition models an elementary Boolean expression of the form "variable matches value". In this section, we define an abstract policy-value building block which can provide re-use flexiblely. And for an extended policy yang model, the condition can extend and reuse the policy-value block.
Figure 11 shows the snippet of a PolicyValue block.
module: ietf-policy
+--rw policy-value!
+--rw name string
Figure 11: Snippet of the Data Hierarchy Related to PolicyValue
This section describes a collection of managed elements that share a common role. The PolicyRoleCollection always exists in the context of a system. The value of the PolicyRole property in this class specifies the role and can be re-used in other instances of PolicyRule or PolicyGroup.
Figure 12 shows the snippet of the data hierarchy related to the PolicyRoleCollection.
+--rw Policy!
| +--rw PolicySet!
| ......
| +--rw Collection!
| +--rw PolicyRoleCollection!
| +--rw PolicyRole string
Figure 12: Snippet of the Data Hierarchy Related to PolicyRoleCollection
The ManagedSystemElement is an abstract container that can describe and aggregate a set of abstract managed system elements such as LogicalElement, etc.
Figure 13 shows the snippet of the data hierarchy related to the ManagedSystemElement.
+--rw Policy!
| +--rw PolicySet!
......
+--rw ManagedSystemElement!
+--rw LogicalElement!
+--rw System!
| +--rw AdminDomain!
| +--rw ReusablePolicyContainer!
+--rw FilterEntryBase!
+--rw FilterList* [filter-name]
+--rw filter-name string
Figure 13: Snippet of the Data Hierarchy Related to ManagedSystemElement
Figure 14 shows the structure of the IETF Abstract Network Policy YANG model.
module: ietf-policy
+--rw policy-set!
| +--rw PolicyRole role-type
| +--rw PolicyDecisionStrategy py:policy-decision-strategy
| +--rw policy-rule!
| | +--rw name leafref
| +--rw policy-group!
| +--rw name leafref
|
+--rw policy-rule!
| +--rw name string
| +--rw policy-rules*[name]
| +--rw name string
| +--rw Enabled boolean
| +--rw Mandatory boolean
| +--rw ConditionListType py:policy-conditionlist-type
| +--rw SequencedActions py:policy-sequenced-actions
| +--rw ExecutionStrategy py:policy-execution-strategy
| +--rw policy-condition
| | +--rw name leafref
| +--rw policy-action
| +--rw name leafref
|
+--rw policy-group!
| +--rw name string
| +--rw policy-groups* [name]
| | +--rw name leafref
| +--rw policy-rule* [name]
| +--rw name leafref
|
+--rw policy-condition!
| +--rw name string
|
+--rw policy-action!
| +--rw name string
|
+--rw policy-variable!
| +--rw name string
|
+--rw filter-entry-base!
| +--rw name string
|
+--rw ManagedSystemElement!
+--rw LogicalElement!
+--rw System!
| +--rw AdminDomain!
| +--rw ReusablePolicyContainer!
+--rw FilterEntryBase!
+--rw FilterList* [filter-name]
+--rw filter-name string
Figure 14: The Structure of the IETF Abstract Network Policy YANG Model
The abstract containers provide a set of atomic blocks which can be used to aggregate or describe some policy elements. And these abstract containers can be augmented and reused. This section describes these reusable atomic grouping.
This subsection describes time-period-condition grouping.Figure 15provides the structure of time-period-conditon grouping block
+--rw PolicyTimePeriodCondition!
+--rw TimePeriod string
+--rw MonthOfYearMask yang:data-and-time
+--rw DayOfMonthMask yang:data-and-time
+--rw DayOfWeekMask string
+--rw TimeOfDayMask yang:data-and-time
+--rw LocalOrUtcTime enumeration
Figure 15: The Structure of time-period-conditon grouping block
This subsection describes Reusable atomic policy variable grouping.
Figure 16 provides the structure of the PolicyVariable block.
+--rw Policy!
......
| +--rw PolicyVariable!
+--rw PolicyImplicitVariable!
+--rw PolicySourceIPv4Variable
+--rw PolicySourceIPv6Variable
+--rw PolicyDestinationIPv4Variable
+--rw PolicyDestinationIPv6Variable
+--rw PolicySourcePortVariable
+--rw PolicyDestinationPortVariable
+--rw PolicyIPProtocolVariable
+--rw PolicyIPToSVariable
+--rw PolicyDSCPVariable
+--rw PolicyFlowIdVariable
+--rw PolicySourceMACVariable
+--rw PolicyDestinationMACVariable
+--rw PolicyVLANVariable
+--rw PolicyCoSVariable
+--rw PolicyEthertypeVariable
+--rw PolicySourceSAPVariable
+--rw PolicyDestinationSAPVariable
+--rw PolicySNAPOUIVariable
+--rw PolicySNAPTypeVariable
+--rw PolicyFlowDirectionVariable
Figure 16: Extending the PolicyVariable Container
This section describes Reusable ip-headers filter atomic grouping.
Figure 17 provides the structure of the IpHeadersFilter block.
+--rw Policy!
......
+--rw ManagedSystemElement!
+--rw LogicalElement!
+--rw System!
| ......
+--rw FilterEntryBase!
| +--rw IpHeadersFilter!
| +--rw HdrIpVersion
| +--rw HdrSrcAddress
| +--rw HdrSrcAddressEndOfRange
| +--rw HdrSrcMask
| +--rw HdrDestAddress
| +--rw HdrDestAddressEndOfRange
| +--rw HdrDestMask
| +--rw HdrProtocolID
| +--rw HdrSrcPortStart
| +--rw HdrSrcPortEnd
| +--rw HdrDestPortStart
| +--rw HdrDestPortEnd
| +--rw HdrDSCP
| +--rw HdrFlowLabel
Figure 17: Snippet of the Data Hierarchy Related to IpHeadersFilter
This section describes a reusable 8021 filter atomic grouping.
Figure 18 provides the structure of the 8021Filter block.
+--rw Policy!
......
+--rw ManagedSystemElement!
+--rw LogicalElement!
+--rw System!
| ......
+--rw FilterEntryBase!
| +--rw IpHeadersFilter!
| +--rw 8021Filter!
| +--rw 8021HdrSrcMACAddr
| +--rw 8021HdrSrcMACMask
| +--rw 8021HdrDestMACAddr
| +--rw 8021HdrDestMACMask
| +--rw 8021HdrProtocolID
| +--rw 8021HdrPriorityValue
| +--rw 8021HDRVLANID
Figure 18: Snippet of the Data Hierarchy Related to 8021Filter
The following figure provide an example of use in routing policy:
augment /bplc:policy-condition
+--rw policy-variable!
+--rw name leafref
augment /bplc:policy-variable
+--rw HdrSrcAddress py:policy-ip-address
+--rw HdrSrcAddressEndOfRange py:policy-addr-range
+--rw mask-length py:policy-addr-length
+--rw mask-length-range py:policy-addr-range
+--rw neighbor* [name]
+--rw name string
+--rw HdrSrcAddress py:policy-ip-address
augment /bplc:policy-action
+--rw accept boolean
+--rw reject boolean
The following figure provide an example of use in QoS policy:
augment /bplc:policy-condition
+--rw policy-variable!
+--rw name leafref
Augment /bplc:policy-variable
+--rw qos-rsvp-variable!
+--rw source-IPv4 py:policy-IPv4-addr
+--rw source-IPv6 py:policy-IPv6-addr
+--rw destination-IPv4 py:policy-IPv4-addr
+--rw destination-IPv6 py:policy-IPv6-addr
+--rw QoS-Message-Type enumeration
+--rw QoS-RSVPPreemption-Priority uint32
+--rw QoS-RSVPPreemption-DefPriority uint32
+--rw QoS-RSVP-User string
+--rw QoS-RSVP-Application string
+--rw QoS-RSVP-AuthMethod enumeration
augment /bplc:policy-action
+--rw QoSPolicyRSVPSimpleAction!
+--rw QoSPolicyDiscardAction!
+--rw QoSPolicyAdmissionAction!
+--rw QoSPolicyPHBAction!
<CODE BEGINS>
file "policy-yang-types.yang"
module policy-yang-types {
yang-version "1";
namespace "urn:TBD:params:xml:ns:yang:policy-yang-types";
prefix "py";
import ietf-inet-types { prefix inet; }
import ietf-yang-types { prefix yang; }
organization "IETF Netmod Working Group";
contact "wangzitao@huawei.com";
description
"This module defines general data definitions for policy.";
typedef policy-decision-strategy {
description
"The policy-decision-strategy is used to specify the matching
strategy for the policies of the policy rule. There are two
matching strategies: First-Matching and All-Matching.";
type enumeration{
enum FirstMatching {
description
"The FirstMatching strategy is used to cause the evaluation of
the rules in a set such that the only actions enforced on a
given examination of the Policy Set are those for the first rule
that has its conditions evaluate to TRUE.";}
enum AllMatching {
description
"The AllMatching strategy is used to cause the evaluation of
all rules in a set; for all of the rules whose conditions
evaluate to TRUE, the actions are enforced.";}
}
default FirstMatching;
}
typedef policy-sequenced-actions {
type enumeration{
enum mandatory{
description
"Do the actions in the indicated order, or don't do them at
all.";}
enum recommended{
description
"Do the actions in the indicated order if you can, but if you
can't do them in this order, do them in another order if you
can.";}
enum dontCare{
description
"I don't care about the order.";}
}
default dontCare;
}
typedef policy-execution-strategy {
type enumeration{
enum DoUntilSuccess {
description
"Execute actions according to predefined order, until
successful execution of a single action.";}
enum DoAll{
description
"Execute ALL actions which are part of the modeled set,
according to their predefined order. Continue doing this, even
if one or more of the actions fails.";}
enum DoUntilFailure{
description
"Execute actions according to predefined order, until the first
failure in execution of a single sub-action.";}
}
default DoAll;
}
typedef policy-conditionlist-type {
type enumeration{
enum DNF;
enum CNF;
}
default DNF;
}
//policy values
typedef policy-IPv4-addr{
description
"The IPv4 address. of the outermost IP packet header.";
type inet:ipv4-address;
}
typedef policy-IPv6-addr{
description
"The IPv6 address. of the outermost IP packet header.";
type inet:ipv6-address;
}
typedef policy-port{
description
"For TCP and UDP flows, the PolicySourcePortVariable is logically
bound to the source port field of the outermost UDP or TCP packet
header.";
type inet:port-number;
}
typedef policy-protocol{
description
"The IP protocol number.";
type uint16{
range "0..65535";}
}
typedef policy-ip-version{
description
"The IP version number.";
type inet:ip-version;
}
typedef policy-dscp{
description
"The 6 bit Differentiated Service Code Point.";
type inet:dscp;
}
typedef policy-flow-label{
description
"The flow identifier of the outermost IPv6 packet header.";
type uint32{
range "0..1048575";}
}
typedef policy-mac-addr{
description
"The source MAC address.";
type yang:mac-address;
}
typedef policy-vlan{
description
"The virtual Bridged Local Area Network Identifier, a 12-bit
field as defined in the IEEE 802.1q standard.";
type uint16{
range "0..4095";}
}
typedef policy-cos{
description
"A 3-bit field, used in the layer 2 header to select the
forwarding treatment. Bound to the IEEE 802.1q user-priority
field.";
type uint8{
range "0..7";}
}
typedef policy-ether-type{
description
"The Ethertype protocol number of Ethernet frames.";
type uint16{
range "0..65535";}
}
typedef policy-sap{
description
"The Source Service Access Point (SAP) number of thev IEEE 802.2
LLC header.";
type uint8{
range "0..255";}
}
typedef policy-snap-oui{
description
"The value of the first three octets of the Sub-Network Access
Protocol (SNAP) Protocol Identifier field for 802.2 SNAP
encapsulation, containing an Organizationally Unique Identifier
(OUI). The value 00-00-00 indicates the encapsulation of
Ethernet frames (RFC 1042). OUI value 00-00-F8 indicates the
special encapsulation of Ethernet frames by certain types of
bridges (IEEE 802.1H). Other values are supported, but are not
further defined here. These OUI values are to be interpreted
according to the endian-notation conventions of IEEE 802. For
either of the two Ethernet encapsulations, the remainder of the
Protocol Identifier field is represented by the
PolicySNAPTypeVariable.";
type uint32{
range "0..16777215";}
}
typedef policy-flow-direction {
type enumeration{
enum IN;
enum OUT;
enum BOTH;
}
default BOTH;
}
typedef policy-ip-address{
type inet:ip-address;
}
typedef policy-addr-range {
type union{
type inet:ipv4-prefix;
type inet:ipv6-prefix;
}
}
typedef policy-addr-length{
description
"simple range covers both ipv4 and ipv6.";
type uint8{
range 1..128;}
}
}
<CODE ENDS>
<CODE BEGINS>
file "ietf-policy.yang"
module ietf-policy{
yang-version 1;
namespace "urn:TBD:params:xml:ns:yang:basic-policy";
prefix bplc;
import ietf-yang-types { prefix yang;}
import policy-yang-types {prefix py;}
organization "IETF Netmod Working Group";
contact
"wangzitao@huawei.com";
description
"This module defines basic-network-policy yang data model";
typedef role-type {
type string;
description "basic network policy role type";
}
/* Reusable atomic grouping */
grouping basic-roles{
leaf PolicyRoles
{
description
"A set of strings representing the roles and role combinations
associated with a policy rule. Each value represents one role
combination.";
type string;
}
}
grouping basic-role{
leaf PolicyRole{
description
"A role is an administratively specified characteristic of a
managed element. As a selector for policies, it determines
the applicability of the policy to a particular managed
element.";
type role-type;
}
}
grouping core-policy-set{
description
"This grouping collect a set of core parameters of PolicySet.";
uses basic-roles;
leaf PolicyDecisionStrategy {
description
"The match-strategy leaf is used to specify the matching
strategy for the policies of the policy rule. There are two
matching strategy: First-Matching and All-Matching.";
type py:policy-decision-strategy;
}
}
grouping action-method{
description
"This grouping collect SequencedActions and ExecutionStrategy
methods. And this grouping may be used in PolicyRule, etc.";
leaf SequencedActions{
description
"This leaf gives a policy administrator a way of specifying
the ordering of the policy actions.";
type py:policy-sequenced-actions;
}
leaf ExecutionStrategy{
description
"This leaf defines the execution strategy to be used upon the
sequenced actions is this policy-rule.";
type py:policy-execution-strategy;
}
}
grouping condition-method{
description
"This grouping collect ConditionListType methods. And this
grouping may be used in PolicyRule or CompoundPolicyCondition,
etc.";
leaf ConditionListType{
description
"Indicates whether the list of policy conditions associated
with this policy rule is in disjunctive normal form (DNF) or
conjunctive normal form (CNF).";
type py:policy-conditionlist-type;
}
}
grouping core-policy-rule{
description
"This grouping collect a set of core parameters of PolicyRule.";
leaf Enabled{
description
"An enumeration indicating whether a policy rule is
administratively enabled, administratively disabled, or
enabled for debug mode.";
type enumeration{
enum enabled;
enum disabled;
enum enabledForDebug;
}
default enabled;
}
leaf Mandatory{
description
"A flag indicating that the evaluation of the PolicyConditions
and execution of PolicyActions (if the condition list
evaluates to TRUE) is required.";
type boolean;
default true;
}
uses condition-method;
uses action-method;
}
/* Reusable atomic policy condition grouping */
grouping time-period-condition{
container PolicyTimePeriodCondition{
description
"A condition that provides the capability of
enabling/disabling a policy rule according to a pre-determined
schedule.";
uses condition-method;
leaf TimePeriod{
description
"The range of calendar dates on which a policy rule is
valid. And the format is: yyyymmddThhmmss/yyyymmddThhmmss,
where the first date/time may be replaced with the string
THISANDPRIOR or the second date/time may be replaced with
the string THISANDFUTURE.";
type string;
}
leaf MonthOfYearMask{
description
"A mask identifying the months of the year in which a policy
rule is valid.";
type yang:date-and-time;
}
leaf DayOfMonthMask{
description
"A mask identifying the days of the month on which a policy
rule is valid.";
type yang:date-and-time;
}
leaf DayOfWeekMask{
description
"A mask identifying the days of the week on which a policy
rule is valid.";
type string;
}
leaf TimeOfDayMask{
description
"The range of times at which a policy rule is valid. If the
second time is earlier than the first, then the interval
spans midnight.";
type yang:date-and-time;
}
leaf LocalOrUtcTime{
description
"An indication of whether the other times in this instance
represent local times or UTC times.";
type enumeration{
enum localTime;
enum utcTime;
}
default utcTime;
}
}
}
grouping vendor-condition{
container VendorPolicyCondition{
description
"A container defines a registered means to describe a policy
condition.";
uses condition-method;
leaf Constraint{
description
"Representing constraints that have not been modeled as
specific properties. The format of the values is identified
by the OID stored in the property ConstraintEncoding.";
type string;
}
leaf ConstraintEncoding{
description
"An OID encoded as a string, identifying the format and
semantics for this instance's Constraint property. The
value is a dotted sequence of decimal digits (for example,
1.2.100.200) representing the arcs of the OID. The
characters in the string are the UCS-2 characters
corresponding to the US ASCII encodings of the numeric
characters and the period.";
type string;
}
}
}
grouping compound-condition{
description
"Introduces the ConditionListType property, used for assigning
DNF/CNF semantics to subordinate policy conditions.";
uses condition-method;
container CompoundFilterCondition{
description
"Introduces the IsMirrored property.
The IsMirrored property indicates whether packets that mirror
a compound filter condition should be treated as matching the
filter.";
uses condition-method;
leaf IsMirrored{
description
"Indicates whether packets that mirror the specified filter
are to be treated as matching the filter.";
type boolean;
default false;
}
}
}
/* END OF Reusable atomic policy condition grouping */
/* Reusable atomic policy action grouping */
grouping vendor-action{
description
"Defines a registered means to describe a policy action.";
uses action-method;
leaf ActionData{
description
"Actions that have not been modeled as specific properties.
The format of the values is identified by the OID stored in
the property ActionEncoding.";
type string;
}
leaf ActionEncoding{
description
"An OID encoded as a string, identifying the format and
semantics for this instance's ActionData property. The value
is a dotted sequence of decimal digits (for example,
1.2.100.200) representing the arcs of the OID. The characters
in the string are the UCS-2 characters corresponding to the US
ASCII encodings of the numeric characters and the period.";
type string;
}
}
grouping compound-action{
description
"Representing sequenced action terms. Each action term is
defined to be a subclass of the PolicyAction class.";
uses action-method;
}
/* END OF Reusable atomic policy action grouping */
/* Reusable atomic policy variable grouping */
grouping source-IPv4{
leaf PolicySourceIPv4Variable{
description
"The source IPv4 address. of the outermost IP packet header.";
type py:policy-IPv4-addr;
}
}
grouping source-IPv6{
leaf PolicySourceIPv6Variable{
description
"The source IPv6 address. of the outermost IP packet header.";
type py:policy-IPv6-addr;
}
}
grouping destination-IPv4{
leaf PolicyDestinationIPv4Variable{
description
"The destination IPv4 address. of the outermost IP packet
header.";
type py:policy-IPv4-addr;
}
}
grouping destination-IPv6{
leaf PolicyDestinationIPv6Variable{
description
"The destination IPv6 address. of the outermost IP packet
header.";
type py:policy-IPv6-addr;
}
}
grouping source-port{
leaf PolicySourcePortVariable{
description
"For TCP and UDP flows, the PolicySourcePortVariable is
logically bound to the source port field of the outermost UDP
or TCP packet header.";
type py:policy-port;
}
}
grouping destination-port{
leaf PolicyDestinationPortVariable{
description
"For TCP and UDP flows, the PolicyDestinationPortVariable is
logically bound to the destination port field of the outermost
UDP or TCP packet header.";
type py:policy-port;
}
}
grouping protocol{
leaf PolicyIPProtocolVariable{
description
"The IP protocol number.";
type py:policy-protocol;
}
}
grouping IP-version{
leaf PolicyIPVersionVariable{
description
"The IP version number.";
type py:policy-ip-version;
}
}
grouping dscp{
leaf PolicyDSCPVariable{
description
"The 6 bit Differentiated Service Code Point.";
type py:policy-dscp;
}
}
grouping flow-id{
leaf PolicyFlowIdVariable{
description
"The flow identifier of the outermost IPv6 packet header.";
type py:policy-flow-label;
}
}
grouping source-mac{
leaf PolicySourceMACVariable{
description
"The source MAC address.";
type py:policy-mac-addr;
}
}
grouping destination-mac{
leaf PolicyDestinationMACVariable{
description
"The destination MAC address.";
type py:policy-mac-addr;
}
}
grouping vlan-variable{
leaf PolicyVLANVariable{
description
"The virtual Bridged Local Area Network Identifier, a 12-bit
field as defined in the IEEE 802.1q standard.";
type py:policy-vlan;
}
}
grouping cos-variable{
leaf PolicyCoSVariable{
description
"A 3-bit field, used in the layer 2 header to select the
forwarding treatment. Bound to the IEEE 802.1q user-priority
field.";
type py:policy-cos;
}
}
grouping ether-type{
leaf PolicyEthertypeVariable{
description
"The Ethertype protocol number of Ethernet frames.";
type py:policy-ether-type;
}
}
grouping source-sap{
leaf PolicySourceSAPVariable{
description
"The Source Service Access Point (SAP) number of thev IEEE
802.2 LLC header.";
type py:policy-sap;
}
}
grouping destination-sap{
leaf PolicyDestinationSAPVariable{
description
"The Destination Service Access Point (SAP) number of the
IEEE 802.2 LLC header.";
type py:policy-sap;
}
}
grouping snap-oui{
leaf PolicySNAPOUIVariable{
description
"The value of the first three octets of the Sub-Network Access
Protocol (SNAP) Protocol Identifier field for 802.2 SNAP
encapsulation, containing an Organizationally Unique
Identifier (OUI). The value 00-00-00 indicates the
encapsulation of Ethernet frames (RFC 1042). OUI value
00-00-F8 indicates the special encapsulation of Ethernet
frames by certain types of bridges (IEEE 802.1H). Other
values are supported, but are not further defined here. These
OUI values are to be interpreted according to the endian-
notation conventions of IEEE 802. For either of the two
Ethernet encapsulations, the remainder of the Protocol
Identifier field is represented by the
PolicySNAPTypeVariable.";
type py:policy-snap-oui;
}
}
grouping flow-direction{
leaf PolicyFlowDirectionVariable{
description
"The direction of a flow relative to a network element.
Direction may be IN and/or OUT.";
type py:policy-flow-direction;
}
}
/* END OF Reusable atomic policy variable grouping */
/* atomic policy collection grouping */
grouping role-collection{
description
"Be used to collect managed elements that share a role.";
uses basic-role;
}
/* END OF atomic policy role-collection grouping */
/* Reusable ManagedSystemElement atomic grouping */
/* Reusable LogicalElement atomic grouping */
/* grouping reusable-policy-container{
leaf-list policy-name{
type leafref{
path "/policy/policy-id";
}
}
} */
/* Reusable ip-headers filter atomic grouping */
grouping hdr-ip-version{
leaf HdrIpVersion{
type py:policy-ip-version;
}
}
grouping hdr-src-addr{
leaf HdrSrcAddress{
type py:policy-ip-address;
}
}
grouping hdr-src-range{
leaf HdrSrcAddressEndOfRange{
type py:policy-addr-range;
}
}
grouping policy-addr-mask{
leaf mask-length {
description
"masklength for the prefix specification";
type py:policy-addr-length;
mandatory true;
}
leaf mask-length-range {
type py:policy-addr-range;
}
}
grouping hdr-dest-addr{
leaf HdrDestAddress{
type py:policy-ip-address;
}
}
grouping hdr-dest-range{
leaf HdrDestAddressEndOfRange{
type py:policy-addr-range;
}
}
grouping hdr-protocol{
leaf HdrProtocolID{
type py:policy-protocol;
}
}
grouping hdr-srcport-start{
leaf HdrSrcPortStart{
type py:policy-port;
}
}
grouping hdr-srcport-end{
leaf HdrSrcPortEnd{
type py:policy-port;
}
}
grouping hdr-destport-start{
leaf HdrDestPortStart{
type py:policy-port;
}
}
grouping hdr-destport-end{
leaf HdrDestPortEnd{
type py:policy-port;
}
}
grouping hdr-dscp{
leaf HdrDSCP{
type py:policy-dscp;
}
}
grouping hdr-flow-label{
leaf HdrFlowLabel{
type py:policy-flow-label;
}
}
/* END OF Reusable ip-headers filter atomic grouping */
/* END OF Reusable LogicalElement atomic grouping */
grouping ietf-oper-info{
leaf-list targets{
description
"This leaf list can be used to present a set of targets which
the policy is applied.";
type string;
}
}
/*END OF Reusable ManagedSystemElement atomic grouping */
/* END OF Reusable atomic grouping */
/* Application Template*/
container policy-group{
leaf name{
type string;
}
container policy-group{
leaf name{
type leafref{
path "/policy-group/name";
}
}
}
container policy-rule{
leaf name{
type leafref{
path "/policy-rule/name";
}
}
}
}
container policy-rule{
leaf name{
type string;
}
uses bplc:core-policy-rule;
list policy-rules{
key "name";
leaf name{
type string;
}
container policy-condition{
leaf name{
type leafref{
path "/policy-condition/name";
}
}
container policy-variable{
leaf name{
type leafref{
path "/policy-variable/name";
}
}
}
}
container policy-action{
leaf name{
type leafref{
path "/policy-variable/name";
}
}
}
}
}
}
<CODE ENDS>
module routing-policy-example{
yang-version 1;
namespace "urn:TBD:params:xml:ns:yang:routing-policy-example";
prefix rpe;
import basic-policy {prefix bplc;}
organization "IETF Netmod Working Group";
contact
"xxxxxxxx";
description
"This module defines basic-network-policy yang data model";
identity routing-policy {
base bplc:policy-type;
description
"routing policy.";
}
augment
"/bplc:policy-condition" {
container policy-variable{
leaf name{
type leafref{
path "/bplc:policy-variable/bplc:name";
}
}
}
}
augment
"/bplc:policy-variable" {
uses bplc:hdr-src-addr;
uses bplc:hdr-dest-addr;
uses bplc:policy-addr-mask;
list neighbor{
key "name";
leaf name{
type string;
}
uses bplc:hdr-src-addr; //update!
}
}
augment
"/bplc:policy-action" {
leaf accept {
type boolean;
description "accepts the route into the routing table";
}
leaf reject {
type boolean;
description "rejects the route";
}
}
}
module qos-policy-example{
yang-version 1;
namespace "urn:TBD:params:xml:ns:yang:qos-policy-example";
prefix qpe;
import basic-policy {prefix bplc;}
organization "IETF Netmod Working Group";
contact
"xxxxxxxx";
description
"This module defines QoS Policy yang data model.";
identity qos-policy {
base bplc:policy-type;
description
"QOS policy.";
}
augment
"/bplc:policy-condition" {
container policy-variable{
leaf name{
type leafref{
path "/bplc:policy-variable/bplc:name";
}
}
}
}
augment
"/bplc:policy-variable" {
container qos-rsvp-variable{
/* uses the atomic reusable groups*/
uses bplc:source-IPv4;
uses bplc:source-IPv6;
uses bplc:destination-IPv4;
uses bplc:destination-IPv6;
/* ........*/
leaf QoS-Message-Type{
description
"The RSVP message type.";
type enumeration{
enum PATH;
enum PATHTEAR;
enum RESV;
enum RESVTEAR;
enum REVERR;
enum CONF;
enum PATHERR;
}
}
leaf QoS-RSVPPreemption-Priority{
description
"The RSVP reservation priority.";
type uint32;
}
leaf QoS-RSVPPreemption-DefPriority{
description
"The RSVP reservation defending
priority.";
type uint32;
}
leaf QoS-RSVP-User{
description
"The ID of the user that initiated the flow
as defined in the User Locator string.";
type string;
}
leaf QoS-RSVP-Application{
description
"The ID of the application that generated the flow
as defined in the application locator string.";
type string;
}
leaf QoS-RSVP-AuthMethod{
description
"The type of authentication.";
type enumeration{
enum NONE;
enum PLAIN-TEXT;
enum DIGITAL-SIG;
enum KERBEROS_TKT;
enum X509_V3_CERT;
enum PGP_CERT;
}
}
}
}
augment
"/bplc:policy-action" {
container QoSPolicyRSVPSimpleAction;
container QoSPolicyDiscardAction;
container QoSPolicyAdmissionAction ;
container QoSPolicyPHBAction;
}
}
TBD.
TBD.
| [RFC3198] | Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J. and S. Waldbusser, "Terminology for Policy-Based Management", RFC 3198, November 2001. |
| [RFC6020] | Bjorklund, M., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, October 2010. |
| [RFC6241] | Enns, R., Bjorklund, M., Schoenwaelder, J. and A. Bierman, "Network Configuration Protocol (NETCONF)", RFC 6241, June 2011. |
| [RFC3060] | Moore, B., Ellesson, E., Strassner, J. and A. Westerinen, "Policy Core Information Model -- Version 1 Specification", RFC 3060, February 2001. |
| [RFC3460] | Moore, B., "Policy Core Information Model (PCIM) Extensions", RFC 3460, January 2003. |
| [RFC4011] | Waldbusser, S., Saperia, J. and T. Hongal, "Policy Based Management MIB", RFC 4011, March 2005. |