Network Working Group Z. Wang Internet-Draft Huawei Intended status: Experimental May 4, 2015 Expires: November 5, 2015 A Network Policy YANG Data Models using abstraction language draft-wang-netmod-yang-policy-dm-02 Abstract This document describes a YANG data model for network policies using Language Abstractions defined in RFC6095. The model intends to be applied to deliver various different network services by controlling the policies that enable features such as QoS, Security, 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. Earlier revisions of this document were written to trigger discussion with operator community at IETF-92 in Dallas. This document has been updated to reflect the limited conclusions of those discussions and record them for archival purposes. There is no intent to advance this document any further toward publication. 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). 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 November 5, 2015. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. Wang Expires November 5, 2015 [Page 1] Internet-DrafNetwork Policy Model using Abstraction Language May 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Definitions and Acronyms . . . . . . . . . . . . . . . . . . 3 2.1. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 3 3. Design of Network Policy Modules . . . . . . . . . . . . . . 4 3.1. Common Core Network Policy . . . . . . . . . . . . . . . 4 3.2. The Policy-Set . . . . . . . . . . . . . . . . . . . . . 5 3.2.1. Policy-role . . . . . . . . . . . . . . . . . . . . . 6 3.3. Policy-rule . . . . . . . . . . . . . . . . . . . . . . . 7 3.4. The Policy-group . . . . . . . . . . . . . . . . . . . . 8 3.5. PolicyCondition . . . . . . . . . . . . . . . . . . . . . 8 3.6. PolicyAction . . . . . . . . . . . . . . . . . . . . . . 9 3.7. PolicyVariable . . . . . . . . . . . . . . . . . . . . . 9 3.8. PolicyValue . . . . . . . . . . . . . . . . . . . . . . . 9 3.9. Collection . . . . . . . . . . . . . . . . . . . . . . . 10 3.10. ManagedSystemElement . . . . . . . . . . . . . . . . . . 10 4. IETF Abstract Network Policy Data Hierarchy . . . . . . . . . 11 5. Design of Reusable atomic grouping . . . . . . . . . . . . . 12 5.1. PolicyTimePeriodCondition . . . . . . . . . . . . . . . . 12 5.2. Reusable Variable atomic grouping . . . . . . . . . . . . 13 5.3. Reusable ip-headers filter atomic grouping . . . . . . . 13 5.4. Reusable 8021Filter atomic grouping . . . . . . . . . . . 14 6. IETF Network Policy YANG Module . . . . . . . . . . . . . . . 15 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 20 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 9.1. Normative References . . . . . . . . . . . . . . . . . . 21 9.2. Informative References . . . . . . . . . . . . . . . . . 21 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 22 1. Introduction 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. Wang Expires November 5, 2015 [Page 2] Internet-DrafNetwork Policy Model using Abstraction Language May 2015 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 YANG data model for network policies using Language Abstractions defined in [RFC6095]. The model intends to be applied to deliver various different network services by controlling the policies that enable features such as QoS, Security, 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. Earlier revisions of this document were written to trigger discussion with operator community at IETF-92 in Dallas. This document has been updated to reflect the limited conclusions of those discussions and record them for archival purposes. There is no intent to advance this document any further toward publication. 2. Definitions and Acronyms BNP: Basic Network Policy QoS: Quality of Service YANG: [RFC6020]A data definition language for NETCONF[RFC6241] 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: Wang Expires November 5, 2015 [Page 3] Internet-DrafNetwork Policy Model using Abstraction Language May 2015 Each node is printed as: is one of: + for current x for deprecated o for obsolete is one of: rw for Read/Write ro for ReadOnly -x for rpcs (remote procedure calls) -n for notifications is the name of the node If the node is augmented into the tree from another module, its name is printed as :. is one of: ? for an optional leaf or choice ! for a presence container * for a leaf-list or list [] for the keys of a particular list Figure 1: Symbols Used in Diagrams in this Document 3. Design of Network Policy Modules In this document we define a common core policy model using language abstraction 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. 3.1. Common Core Network Policy 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. Wang Expires November 5, 2015 [Page 4] Internet-DrafNetwork Policy Model using Abstraction Language May 2015 This section describes the common core network policy YANG model structure and also describes the separate elements: Policy-Set is a set of Policies which is inserted into the inheritance hierarchy above both policy-group and policy-rule. Policy-Group is used to provide a hierarchical policy definition that gives the model context or scope for each policy-rule. The policy-group is identified by a policy group-name, and contains a set of policy-rules. One policy-group can be nested within another policy-group. Policy-Rule is represented by the semantics "If Condition then Action". A policy-rule may have a priority and a precedence assigned to it. One policy-rule can be nested within another policy-rule. Figure 2 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 2: High-Level Structure of the ietf-policy YANG Model 3.2. The Policy-Set 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 3 shows the snippet of a policy-set. Wang Expires November 5, 2015 [Page 5] Internet-DrafNetwork Policy Model using Abstraction Language May 2015 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 3: Snippet of the Data Hierarchy Related to policy-set o The policy-decision-strategy leaf is used to specify the decision strategy for a policies. There are two matching strategies: "First-Matching" and "All-Matching." The First-Matching 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. The All-Matching 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. [RFC3460]. o The policy-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. o The policy-rule container contains a name leaf, this name can be used to reference the policy-rule defined in Section 3.3. o The policy-group container contains a name leaf, and this name can be used to reference the policy-group defined in Section 3.4 3.2.1. Policy-role 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 Wang Expires November 5, 2015 [Page 6] Internet-DrafNetwork Policy Model using Abstraction Language May 2015 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. 3.3. Policy-rule Policies can be used in either as stand-alone policy rules or can be aggregated into policy groups functions [RFC3060]. Figure 4 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 4: Snippet of the Data Hierarchy Related to policy-rule o name is the identification of a policy-rule. Different occurrences of policy-rule are distinguished via the rule-name leaf. o The ConditionListType is an enumeration type and indicates whether the list of policy conditions associated with this policy rule is in disjunctive normal form (DNF) or conjunctive normal form (CNF). o The Sequenced-Actions leaf is an enumeration type and indicate the action ordering. o The ExecutionStrategy leaf defines the execution strategy to be used upon the sequenced actions is this policy-rule. o The policy-condition container contains a name leaf, this name can be used to reference the policy-condition defined in Section 3.5. Wang Expires November 5, 2015 [Page 7] Internet-DrafNetwork Policy Model using Abstraction Language May 2015 o The policy-action container contains a name leaf, and this name can be used to reference the policy-action defined in Section 3.3. 3.4. The Policy-group 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 5 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 5: Snippet of the Data Hierarchy Related to policy-group o Name under policy-group container is the identification of the policy-group. Different policy-group list instances are distinguished via the leaf group name. o The name in policy-rules can be used to reference the rules defined in Section 3.3 and identify each policy rule. 3.5. PolicyCondition 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 6 shows the snippet of a PolicyCondition block. module: ietf-policy +--rw policy-condition! +--rw name string Figure 6: Snippet of the Data Hierarchy Related to PolicyCondition Wang Expires November 5, 2015 [Page 8] Internet-DrafNetwork Policy Model using Abstraction Language May 2015 3.6. PolicyAction 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 7 shows the snippet of a PolicyAction block. module: ietf-policy +--rw policy-action! +--rw name string ..... Figure 7: Snippet of the Data Hierarchy Related to PolicyAction 3.7. PolicyVariable 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 8 shows the snippet of a PolicyVariable block. module: ietf-policy +--rw policy-variable! +--rw name string Figure 8: Snippet of the Data Hierarchy Related to PolicyVariable 3.8. PolicyValue 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 9 shows the snippet of a PolicyValue block. module: ietf-policy +--rw policy-value! +--rw name string Figure 9: Snippet of the Data Hierarchy Related to PolicyValue Wang Expires November 5, 2015 [Page 9] Internet-DrafNetwork Policy Model using Abstraction Language May 2015 3.9. Collection 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 10 shows the snippet of the data hierarchy related to the PolicyRoleCollection. +--rw Policy! | +--rw PolicySet! | ...... | +--rw Collection! | +--rw PolicyRoleCollection! | +--rw PolicyRole string Figure 10: Snippet of the Data Hierarchy Related to PolicyRoleCollection 3.10. ManagedSystemElement The ManagedSystemElement is an abstract container that can describe and aggregate a set of abstract managed system elements such as LogicalElement, etc. Figure 11 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 11: Snippet of the Data Hierarchy Related to ManagedSystemElement Wang Expires November 5, 2015 [Page 10] Internet-DrafNetwork Policy Model using Abstraction Language May 2015 o ReusablePolicyContainer describes an administratively defined container for reusable policy-related information [RFC3460]. Notice that this container does not introduce any additional properties beyond the AdminDomain. It does, however, participate in a number of unique associations. o FilterEntryBase is an abstract contaienr representing a single filter that is aggregated into a FilterList via the aggregation. 4. IETF Abstract Network Policy Data Hierarchy Figure 12 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 | Wang Expires November 5, 2015 [Page 11] Internet-DrafNetwork Policy Model using Abstraction Language May 2015 +--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 12: The Structure of the IETF Abstract Network Policy YANG Model 5. Design of Reusable atomic grouping 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. 5.1. PolicyTimePeriodCondition This subsection describes time-period-condition grouping.Figure 13provides 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 13: The Structure of time-period-conditon grouping block o The TimePeriod leaf describes the range of calendar dates on which a policy rule is valid. Wang Expires November 5, 2015 [Page 12] Internet-DrafNetwork Policy Model using Abstraction Language May 2015 o The TimeMask leaf describes a mask identifying time in which a policy rule is valid. o The LocalOrUtcTime leaf describes an indication of whether the other times in this instance represent local times or UTC times. 5.2. Reusable Variable atomic grouping This subsection describes Reusable atomic policy variable grouping. Figure 14 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 14: Extending the PolicyVariable Container 5.3. Reusable ip-headers filter atomic grouping This section describes Reusable ip-headers filter atomic grouping. Figure 15 provides the structure of the IpHeadersFilter block. Wang Expires November 5, 2015 [Page 13] Internet-DrafNetwork Policy Model using Abstraction Language May 2015 +--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 15: Snippet of the Data Hierarchy Related to IpHeadersFilter 5.4. Reusable 8021Filter atomic grouping This section describes a reusable 8021 filter atomic grouping. Figure 16 provides the structure of the 8021Filter block. Wang Expires November 5, 2015 [Page 14] Internet-DrafNetwork Policy Model using Abstraction Language May 2015 +--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 16: Snippet of the Data Hierarchy Related to 8021Filter 6. IETF Network Policy YANG Module module abstract-policy{ yang-version 1; namespace "urn:TBD:params:xml:ns:yang:abstract-policy"; prefix aplc; import ietf-complex-types {prefix "ct"; } organization "IETF I2RS Working Group"; contact "wangzitao@huawei.com"; description "This module defines common core-network-policy yang data model"; typedef bnp-group-type { type string; description "basic network group type"; } typedef bnp-rule-type { type string; description "basic network policy rule type"; } typedef role-type { type string; description "basic network policy role type"; } Wang Expires November 5, 2015 [Page 15] Internet-DrafNetwork Policy Model using Abstraction Language May 2015 grouping bnp-role{ leaf role{ 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 ietf-policy-rule{ ct:complex-type PolicyRule{ list policy-rule{ description "defines a list of policy rules."; key "rule-name"; leaf rule-name{ type string; description "The entry-index is the identification of the policy-rule-entry list"; } leaf rule-type{ description "The rule-type is used to indicate the type of the policy rule."; type bnp-rule-type; } leaf priority{ description "The priority leaf indicate the priority of the policy rule. And it will be used when a single client is sending operations to accomplish multiple tasks."; type uint32; } leaf sequenced-actions{ description "This leaf gives a policy administrator a way of specifying the ordering of the policy 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.";} Wang Expires November 5, 2015 [Page 16] Internet-DrafNetwork Policy Model using Abstraction Language May 2015 } } leaf execution-strategy{ description "This leaf defines the execution strategy to be used upon the sequenced actions is this policy-rule."; 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.";} } } } } } grouping ietf-role-collection{ container PolicyRoleCollection{ uses bnp-role; } } grouping ietf-filter{ list FilterList{ key "list-name"; leaf list-name{ type string; } } } grouping ietf-policy-group{ ct:complex-type PolicyGroup{ list policy-group{ key "group-name"; leaf group-name{ description Wang Expires November 5, 2015 [Page 17] Internet-DrafNetwork Policy Model using Abstraction Language May 2015 "The group-name is the identification of the policy-group."; type string; } leaf group-type{ description "The group-type is used to indicate the type of the policy group."; type bnp-group-type; } } } } ct:complex-type Policy{ct:abstract true;} ct:complex-type PolicySet{ ct:abstract true; uses bnp-role; leaf policy-decision-strategy { 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 enumeration{ enum First-Matching { description "The First-Matching 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 All-Matching { description " The All-Matching 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.";} } } } ct:complex-type PolicyCondition{ ct:abstract true; } ct:complex-type PolicyAction{ ct:abstract true; } ct:complex-type PolicyVariable{ ct:abstract true; } ct:complex-type PolicyValue{ ct:abstract true; } ct:complex-type Collection{ Wang Expires November 5, 2015 [Page 18] Internet-DrafNetwork Policy Model using Abstraction Language May 2015 ct:abstract true; } ct:complex-type ManagedSystemElement{ ct:abstract true; ct:complex-type LogicalElement{ ct:abstract true; ct:complex-type System{ ct:abstract true; ct:complex-type AdminDomain{ ct:abstract true; } } ct:complex-type FilterEntryBase{ ct:abstract true; } ct:complex-type PolicyTimePeriodCondition{ ct:extends PolicyCondition; leaf TimePeriod{type string;} leaf TimeMask{type yang:date-and-time;} leaf LocalOrUtcTime{ type enumeration{ enum localTime; enum utcTime; } } } ct:complex-type PolicyImplicitVariable{ ct:extends PolicyVariable; container PolicySourceIPv4Variable; container PolicySourceIPv6Variable; container PolicyDestinationIPv4Variable; container PolicyDestinationIPv6Variable; container PolicySourcePortVariable; container PolicyDestinationPortVariable; container PolicyIPProtocolVariable; container PolicyIPToSVariable; container PolicyDSCPVariable; container PolicyFlowIdVariable; container PolicySourceMACVariable; container PolicyDestinationMACVariable; container PolicyVLANVariable; container PolicyCoSVariable; container PolicyEthertypeVariable; container PolicySourceSAPVariable; container PolicyDestinationSAPVariable; Wang Expires November 5, 2015 [Page 19] Internet-DrafNetwork Policy Model using Abstraction Language May 2015 container PolicySNAPOUIVariable; container PolicySNAPTypeVariable; container PolicyFlowDirectionVariable; } ct:complex-type IpHeadersFilter{ ct:extends FilterEntryBase; container HdrIpVersion; container HdrSrcAddress; container HdrSrcAddressEndOfRange; container HdrSrcMask; container HdrDestAddress; container HdrDestAddressEndOfRange; container HdrDestMask; container HdrProtocolID; container HdrSrcPortStart; container HdrSrcPortEnd; container HdrDestPortStart; container HdrDestPortEnd; container HdrDSCP; container HdrFlowLabel; } ct:complex-type 8021Filter{ ct:extends FilterEntryBase; container 8021HdrSrcMACAddr; container 8021HdrSrcMACMask; container 8021HdrDestMACAddr; container 8021HdrDestMACMask; container 8021HdrProtocolID; container 8021HdrPriorityValue; container 8021HDRVLANID; } } } } 7. Conclusion This document uses Policy core information model defined in [RFC3060][RFC3460] as basis and makes a exploration on how Policy core information model can be represented using YANG. To better describe class inheritance and recursiveness, RFC6095 introduces language abstractions to improve the model extensibility and reuse. In case the model of a system that should be managed with NETCONF Wang Expires November 5, 2015 [Page 20] Internet-DrafNetwork Policy Model using Abstraction Language May 2015 makes use of inheritance, complex types enable an almost one-to- one mapping between the classes in the original model and the YANG module. Unfortuately Language Abstractions defined in RFC6095 has its limitation due to introduce multi-level hiearchy and is not widely used in practice. 8. Acknowledgements The authors would like to thank Daniel King, Linda Dunbar and Qin Wu for the very fruitful discussions and useful suggestions in the initial version. 9. References 9.1. Normative References [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. 9.2. Informative References [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. [RFC6095] Linowski, B., Ersue, M., and S. Kuryla, "Extending YANG with Language Abstractions", RFC 6095, March 2011. Wang Expires November 5, 2015 [Page 21] Internet-DrafNetwork Policy Model using Abstraction Language May 2015 Author's Address Zitao Wang Huawei Technologies,Co.,Ltd 101 Software Avenue, Yuhua District Nanjing 210012 China Email: wangzitao@huawei.com Wang Expires November 5, 2015 [Page 22]