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 Abstract 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. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. King, et al. Expires September 10, 2015 [Page 1] Internet-Draft Network Policy Framework March 2015 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 Notice 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definitions and Acronyms . . . . . . . . . . . . . . . . . . 4 2.1. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 5 3. A Network Policy Reference Model . . . . . . . . . . . . . . 6 4. Architecture of The Core Policy YANG Models . . . . . . . . . 8 5. Design of Network Policy Modules . . . . . . . . . . . . . . 9 5.1. Common Core Network Policy . . . . . . . . . . . . . . . 9 5.2. The Policy-Set . . . . . . . . . . . . . . . . . . . . . 10 5.2.1. Policy-role . . . . . . . . . . . . . . . . . . . . . 11 5.3. Policy-rule . . . . . . . . . . . . . . . . . . . . . . . 12 5.4. The Policy-group . . . . . . . . . . . . . . . . . . . . 13 5.5. PolicyCondition . . . . . . . . . . . . . . . . . . . . . 13 5.6. PolicyAction . . . . . . . . . . . . . . . . . . . . . . 14 5.7. PolicyVariable . . . . . . . . . . . . . . . . . . . . . 14 5.8. PolicyValue . . . . . . . . . . . . . . . . . . . . . . . 14 5.9. Collection . . . . . . . . . . . . . . . . . . . . . . . 15 5.10. ManagedSystemElement . . . . . . . . . . . . . . . . . . 15 6. IETF Abstract Network Policy Data Hierarchy . . . . . . . . . 16 7. Design of Reusable atomic grouping . . . . . . . . . . . . . 17 King, et al. Expires September 10, 2015 [Page 2] Internet-Draft Network Policy Framework March 2015 7.1. PolicyTimePeriodCondition . . . . . . . . . . . . . . . . 17 7.2. Reusable Variable atomic grouping . . . . . . . . . . . . 18 7.3. Reusable ip-headers filter atomic grouping . . . . . . . 18 7.4. Reusable 8021Filter atomic grouping . . . . . . . . . . . 19 7.5. Usage Examples . . . . . . . . . . . . . . . . . . . . . 20 7.5.1. Routing Policy . . . . . . . . . . . . . . . . . . . 20 7.5.2. QoS Policy . . . . . . . . . . . . . . . . . . . . . 20 8. IETF Network Policy YANG Module . . . . . . . . . . . . . . . 21 8.1. IETF policy-yang-types Yang Module . . . . . . . . . . . 21 8.1.1. IETF basic-policy Yang Module . . . . . . . . . . . . 26 9. Usage Example Module . . . . . . . . . . . . . . . . . . . . 39 9.1. Routing-Policy-Example . . . . . . . . . . . . . . . . . 40 9.2. Qos-Policy-Example . . . . . . . . . . . . . . . . . . . 41 10. Security Considerations . . . . . . . . . . . . . . . . . . . 43 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 43 12.1. Normative References . . . . . . . . . . . . . . . . . . 43 12.2. Informative References . . . . . . . . . . . . . . . . . 44 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44 1. Introduction 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 King, et al. Expires September 10, 2015 [Page 3] Internet-Draft Network Policy Framework March 2015 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. 2. Definitions and Acronyms ACL: Access Control List BNP: Basic Network Policy QoS: Quality of Service YANG: [RFC6020]A data definition language for NETCONF[RFC6241] The following terms defined in [RFC3198] are also used in this document: o Policy Conflict o Policy Decision King, et al. Expires September 10, 2015 [Page 4] Internet-Draft Network Policy Framework March 2015 o Policy Decision Point (PDP) o Policy Enforcement o Policy Enforcement Point (PEP) o Policy Rule o Service Level Agreement (SLA) o Service Level Objective (SLO) Additionally, we defines the following terms based on the concepts described in [RFC3198]: Policy Consistency Checking: An analysis of multiple policies to determine their consistency or possible inconsistency with rspect to each other. When an inconsistency is discovered, a policy discrepancy is reported. Policy Provider: a function element responsible for acquiring Policy Rules, deploying Policy Rules, Communicating the Policy Rules, and validating Policy rules. The Policy Provider can correspond to one or more Policy Decision points. Policy Consumer: a functional element responsible for translating Policy Rules and carrying out the actions indicated by the Policy Rules. A Policy Consumer can be a Policy Enforcement Point. 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: King, et al. Expires September 10, 2015 [Page 5] Internet-Draft Network Policy Framework March 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. A Network Policy Reference Model King, et al. Expires September 10, 2015 [Page 6] Internet-Draft Network Policy Framework March 2015 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 King, et al. Expires September 10, 2015 [Page 7] Internet-Draft Network Policy Framework March 2015 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. 4. Architecture of The Core Policy YANG Models 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. King, et al. Expires September 10, 2015 [Page 8] Internet-Draft Network Policy Framework March 2015 --------- | 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 5. Design of Network Policy Modules 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. 5.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. King, et al. Expires September 10, 2015 [Page 9] Internet-Draft Network Policy Framework March 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 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 5.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 5 shows the snippet of a policy-set. King, et al. Expires September 10, 2015 [Page 10] Internet-Draft Network Policy Framework March 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 5: 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 5.3. o The policy-group container contains a name leaf, and this name can be used to reference the policy-group defined in Section 5.4 5.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 King, et al. Expires September 10, 2015 [Page 11] Internet-Draft Network Policy Framework March 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. 5.3. Policy-rule 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 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 5.5. King, et al. Expires September 10, 2015 [Page 12] Internet-Draft Network Policy Framework March 2015 o The policy-action container contains a name leaf, and this name can be used to reference the policy-action defined in Section 5.3. 5.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 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 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 5.3 and identify each policy rule. 5.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 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 King, et al. Expires September 10, 2015 [Page 13] Internet-Draft Network Policy Framework March 2015 5.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 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 5.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 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 5.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 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 King, et al. Expires September 10, 2015 [Page 14] Internet-Draft Network Policy Framework March 2015 5.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 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 5.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 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 King, et al. Expires September 10, 2015 [Page 15] Internet-Draft Network Policy Framework March 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. 6. IETF Abstract Network Policy Data Hierarchy 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 | King, et al. Expires September 10, 2015 [Page 16] Internet-Draft Network Policy Framework March 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 14: The Structure of the IETF Abstract Network Policy YANG Model 7. 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. 7.1. PolicyTimePeriodCondition 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 o The TimePeriod leaf describes the range of calendar dates on which a policy rule is valid. King, et al. Expires September 10, 2015 [Page 17] Internet-Draft Network Policy Framework March 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. 7.2. Reusable Variable atomic grouping 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 7.3. Reusable ip-headers filter atomic grouping This section describes Reusable ip-headers filter atomic grouping. Figure 17 provides the structure of the IpHeadersFilter block. King, et al. Expires September 10, 2015 [Page 18] Internet-Draft Network Policy Framework March 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 17: Snippet of the Data Hierarchy Related to IpHeadersFilter 7.4. Reusable 8021Filter atomic grouping This section describes a reusable 8021 filter atomic grouping. Figure 18 provides the structure of the 8021Filter block. King, et al. Expires September 10, 2015 [Page 19] Internet-Draft Network Policy Framework March 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 18: Snippet of the Data Hierarchy Related to 8021Filter 7.5. Usage Examples 7.5.1. Routing Policy 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 7.5.2. QoS Policy The following figure provide an example of use in QoS policy: King, et al. Expires September 10, 2015 [Page 20] Internet-Draft Network Policy Framework March 2015 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! 8. IETF Network Policy YANG Module 8.1. IETF policy-yang-types Yang Module 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 { King, et al. Expires September 10, 2015 [Page 21] Internet-Draft Network Policy Framework March 2015 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 King, et al. Expires September 10, 2015 [Page 22] Internet-Draft Network Policy Framework March 2015 "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";} } King, et al. Expires September 10, 2015 [Page 23] Internet-Draft Network Policy Framework March 2015 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";} } King, et al. Expires September 10, 2015 [Page 24] Internet-Draft Network Policy Framework March 2015 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 King, et al. Expires September 10, 2015 [Page 25] Internet-Draft Network Policy Framework March 2015 "simple range covers both ipv4 and ipv6."; type uint8{ range 1..128;} } } 8.1.1. IETF basic-policy Yang Module 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 King, et al. Expires September 10, 2015 [Page 26] Internet-Draft Network Policy Framework March 2015 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."; King, et al. Expires September 10, 2015 [Page 27] Internet-Draft Network Policy Framework March 2015 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; King, et al. Expires September 10, 2015 [Page 28] Internet-Draft Network Policy Framework March 2015 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; } King, et al. Expires September 10, 2015 [Page 29] Internet-Draft Network Policy Framework March 2015 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 King, et al. Expires September 10, 2015 [Page 30] Internet-Draft Network Policy Framework March 2015 "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 */ King, et al. Expires September 10, 2015 [Page 31] Internet-Draft Network Policy Framework March 2015 /* 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{ King, et al. Expires September 10, 2015 [Page 32] Internet-Draft Network Policy Framework March 2015 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; } } King, et al. Expires September 10, 2015 [Page 33] Internet-Draft Network Policy Framework March 2015 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 King, et al. Expires September 10, 2015 [Page 34] Internet-Draft Network Policy Framework March 2015 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 */ King, et al. Expires September 10, 2015 [Page 35] Internet-Draft Network Policy Framework March 2015 /* 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; King, et al. Expires September 10, 2015 [Page 36] Internet-Draft Network Policy Framework March 2015 } } 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{ King, et al. Expires September 10, 2015 [Page 37] Internet-Draft Network Policy Framework March 2015 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{ King, et al. Expires September 10, 2015 [Page 38] Internet-Draft Network Policy Framework March 2015 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"; } } } } } } 9. Usage Example Module King, et al. Expires September 10, 2015 [Page 39] Internet-Draft Network Policy Framework March 2015 9.1. Routing-Policy-Example 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 King, et al. Expires September 10, 2015 [Page 40] Internet-Draft Network Policy Framework March 2015 "/bplc:policy-action" { leaf accept { type boolean; description "accepts the route into the routing table"; } leaf reject { type boolean; description "rejects the route"; } } } 9.2. Qos-Policy-Example 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 King, et al. Expires September 10, 2015 [Page 41] Internet-Draft Network Policy Framework March 2015 "/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; King, et al. Expires September 10, 2015 [Page 42] Internet-Draft Network Policy Framework March 2015 } 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; } } 10. Security Considerations TBD. 11. IANA Considerations TBD. 12. References 12.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. King, et al. Expires September 10, 2015 [Page 43] Internet-Draft Network Policy Framework March 2015 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. Bierman, "Network Configuration Protocol (NETCONF)", RFC 6241, June 2011. 12.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. Authors' Addresses Daniel King Old Dog Consulting UK Email: daniel@olddog.co.uk Zitao Wang Huawei Technologies,Co.,Ltd 101 Software Avenue, Yuhua District Nanjing 210012 China Email: wangzitao@huawei.com Linda Dunbar Huawei Technologies,Co.,Ltd 1700 Alma Drive, Suite 500 Plano, TX 75075 USA Email: ldunbar@huawei.com King, et al. Expires September 10, 2015 [Page 44] Internet-Draft Network Policy Framework March 2015 Qin Wu Huawei 101 Software Avenue, Yuhua District Nanjing, Jiangsu 210012 China Email: bill.wu@huawei.com King, et al. Expires September 10, 2015 [Page 45]