Network Working Group Y. Snir
`Request for Comments: 3644 Y. Ramberg
`Category: Standards Track Cisco Systems
` J. Strassner
` Intelliden
` R. Cohen
` Ntear LLC
` B. Moore
` IBM
` November 2003
`
` Policy Quality of Service (QoS) Information Model
`
`Status of this Memo
`
` This document specifies an Internet standards track protocol for the
` Internet community, and requests discussion and suggestions for
` improvements. Please refer to the current edition of the "Internet
` Official Protocol Standards" (STD 1) for the standardization state
` and status of this protocol. Distribution of this memo is unlimited.
`
`Copyright Notice
`
` Copyright (C) The Internet Society (2003). All Rights Reserved.
`
`Abstract
`
` This document presents an object-oriented information model for
` representing Quality of Service (QoS) network management policies.
` This document is based on the IETF Policy Core Information Model and
` its extensions. It defines an information model for QoS enforcement
` for differentiated and integrated services using policy. It is
` important to note that this document defines an information model,
` which by definition is independent of any particular data storage
` mechanism and access protocol.
`
`Snir, et al. Standards Track [Page 1]
`
`Arista Networks, Inc.
`Ex. 1027, p. 1
`
`

`

`RFC 3644 Policy QoS Information Model November 2003
`
`Table of Contents
`
` 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 5
` 1.1. The Process of QoS Policy Definition. . . . . . . . . . 5
` 1.2. Design Goals and Their Ramifications. . . . . . . . . . 8
` 1.2.1. Policy-Definition Oriented. . . . . . . . . . . 8
` 1.2.1.1. Rule-based Modeling . . . . . . . . . 9
` 1.2.1.2. Organize Information Hierarchically . 9
` 1.2.1.3. Goal-Oriented Policy Definition . . . 10
` 1.2.2. Policy Domain Model. . . . . . . . . . . . . . . 11
` 1.2.2.1. Model QoS Policy in a Device- and
` Vendor-Independent Manner . . . . . . 11
` 1.2.2.2. Use Roles for Mapping Policy to
` Network Devices . . . . . . . . . . . 11
` 1.2.2.3. Reusability . . . . . . . . . . . . . 12
` 1.2.3. Enforceable Policy. . . . . . . . . . . . . . . 12
` 1.2.4. QPIM Covers Both Signaled And Provisioned QoS . 14
` 1.2.5. Interoperability for PDPs and Management
` Applications. . . . . . . . . . . . . . . . . . 14
` 1.3. Modeling Abstract QoS Policies. . . . . . . . . . . . . 15
` 1.4. Rule Hierarchy. . . . . . . . . . . . . . . . . . . . . 17
` 1.4.1. Use of Hierarchy Within Bandwidth Allocation
` Policies. . . . . . . . . . . . . . . . . . . . 17
` 1.4.2. Use of Rule Hierarchy to Describe Drop
` Threshold Policies. . . . . . . . . . . . . . . 21
` 1.4.3. Restrictions of the Use of Hierarchy Within
` QPIM. . . . . . . . . . . . . . . . . . . . . . 22
` 1.5. Intended Audiences. . . . . . . . . . . . . . . . . . . 23
` 2. Class Hierarchies . . . . . . . . . . . . . . . . . . . . . . 23
` 2.1. Inheritance Hierarchy . . . . . . . . . . . . . . . . . 23
` 2.2. Relationship Hierarchy. . . . . . . . . . . . . . . . . 26
` 3. QoS Actions . . . . . . . . . . . . . . . . . . . . . . . . . 26
` 3.1. Overview. . . . . . . . . . . . . . . . . . . . . . . . 26
` 3.2. RSVP Policy Actions . . . . . . . . . . . . . . . . . . 27
` 3.2.1. Example: Controlling COPS Stateless Decision. . 28
` 3.2.2. Example: Controlling the COPS Replace Decision. 29
` 3.3. Provisioning Policy Actions . . . . . . . . . . . . . . 29
` 3.3.1. Admission Actions: Controlling Policers and
` Shapers . . . . . . . . . . . . . . . . . . . . 29
` 3.3.2. Controlling Markers . . . . . . . . . . . . . . 32
` 3.3.3. Controlling Edge Policies - Examples. . . . . . 33
` 3.4. Per-Hop Behavior Actions. . . . . . . . . . . . . . . . 34
` 3.4.1. Controlling Bandwidth and Delay . . . . . . . . 35
` 3.4.2. Congestion Control Actions. . . . . . . . . . . 35
` 3.4.3. Using Hierarchical Policies: Examples for PHB
` Actions . . . . . . . . . . . . . . . . . . . . 36
` 4. Traffic Profiles. . . . . . . . . . . . . . . . . . . . . . . 38
` 4.1. Provisioning Traffic Profiles . . . . . . . . . . . . . 38
`
`Snir, et al. Standards Track [Page 2]
`
`Arista Networks, Inc.
`Ex. 1027, p. 2
`
`

`

`RFC 3644 Policy QoS Information Model November 2003
`
` 4.2. RSVP Traffic Profiles . . . . . . . . . . . . . . . . . 39
` 5. Pre-Defined QoS-Related Variables . . . . . . . . . . . . . . 40
` 6. QoS Related Values. . . . . . . . . . . . . . . . . . . . . . 42
` 7. Class Definitions: Association Hierarchy. . . . . . . . . . . 44
` 7.1. The Association "QoSPolicyTrfcProfInAdmissionAction". . 44
` 7.1.1. The Reference "Antecedent". . . . . . . . . . . 44
` 7.1.2. The Reference "Dependent" . . . . . . . . . . . 44
` 7.2. The Association "PolicyConformAction" . . . . . . . . . 44
` 7.2.1. The Reference "Antecedent". . . . . . . . . . . 45
` 7.2.2. The Reference "Dependent" . . . . . . . . . . . 45
` 7.3. The Association "QoSPolicyExceedAction" . . . . . . . . 45
` 7.3.1. The Reference "Antecedent". . . . . . . . . . . 46
` 7.3.2. The Reference "Dependent" . . . . . . . . . . . 46
` 7.4. The Association "PolicyViolateAction" . . . . . . . . . 46
` 7.4.1. The Reference "Antecedent". . . . . . . . . . . 46
` 7.4.2. The Reference "Dependent" . . . . . . . . . . . 47
` 7.5 The Aggregation
` "QoSPolicyRSVPVariableInRSVPSimplePolicyAction" . . . . 47
` 7.5.1. The Reference "GroupComponent". . . . . . . . . 47
` 7.5.2. The Reference "PartComponent" . . . . . . . . . 47
` 8. Class Definitions: Inheritance Hierarchy. . . . . . . . . . . 48
` 8.1. The Class QoSPolicyDiscardAction. . . . . . . . . . . . 48
` 8.2. The Class QoSPolicyAdmissionAction. . . . . . . . . . . 48
` 8.2.1. The Property qpAdmissionScope . . . . . . . . . 48
` 8.3. The Class QoSPolicyPoliceAction . . . . . . . . . . . . 49
` 8.4. The Class QoSPolicyShapeAction. . . . . . . . . . . . . 49
` 8.5. The Class QoSPolicyRSVPAdmissionAction. . . . . . . . . 50
` 8.5.1. The Property qpRSVPWarnOnly . . . . . . . . . . 50
` 8.5.2. The Property qpRSVPMaxSessions. . . . . . . . . 51
` 8.6. The Class QoSPolicyPHBAction. . . . . . . . . . . . . . 51
` 8.6.1. The Property qpMaxPacketSize. . . . . . . . . . 51
` 8.7. The Class QoSPolicyBandwidthAction. . . . . . . . . . . 52
` 8.7.1. The Property qpForwardingPriority . . . . . . . 52
` 8.7.2. The Property qpBandwidthUnits . . . . . . . . . 52
` 8.7.3. The Property qpMinBandwidth . . . . . . . . . . 53
` 8.7.4. The Property qpMaxBandwidth . . . . . . . . . . 53
` 8.7.5. The Property qpMaxDelay . . . . . . . . . . . . 53
` 8.7.6. The Property qpMaxJitter. . . . . . . . . . . . 53
` 8.7.7. The Property qpFairness . . . . . . . . . . . . 54
` 8.8. The Class QoSPolicyCongestionControlAction. . . . . . . 54
` 8.8.1. The Property qpQueueSizeUnits . . . . . . . . . 54
` 8.8.2. The Property qpQueueSize. . . . . . . . . . . . 55
` 8.8.3. The Property qpDropMethod . . . . . . . . . . . 55
` 8.8.4. The Property qpDropThresholdUnits . . . . . . . 55
` 8.8.5. The Property qpDropMinThresholdValue. . . . . . 55
` 8.8.6. The Property qpDropMaxThresholdValue. . . . . . 56
` 8.9. The Class QoSPolicyTrfcProf . . . . . . . . . . . . . . 56
` 8.10. The Class QoSPolicyTokenBucketTrfcProf. . . . . . . . . 57
`
`Snir, et al. Standards Track [Page 3]
`
`Arista Networks, Inc.
`Ex. 1027, p. 3
`
`

`

`RFC 3644 Policy QoS Information Model November 2003
`
` 8.10.1. The Property qpTBRate . . . . . . . . . . . . . 57
` 8.10.2. The Property qpTBNormalBurst. . . . . . . . . . 57
` 8.10.3. The Property qpTBExcessBurst. . . . . . . . . . 57
` 8.11. The Class QoSPolicyIntServTrfcProf. . . . . . . . . . . 57
` 8.11.1. The Property qpISTokenRate. . . . . . . . . . . 58
` 8.11.2. The Property qpISPeakRate . . . . . . . . . . . 58
` 8.11.3. The Property qpISBucketSize . . . . . . . . . . 58
` 8.11.4. The Property qpISResvRate . . . . . . . . . . . 58
` 8.11.5. The Property qpISResvSlack. . . . . . . . . . . 59
` 8.11.6. The Property qpISMinPolicedUnit . . . . . . . . 59
` 8.11.7. The Property qpISMaxPktSize . . . . . . . . . . 59
` 8.12. The Class QoSPolicyAttributeValue . . . . . . . . . . . 59
` 8.12.1. The Property qpAttributeName. . . . . . . . . . 60
` 8.12.2. The Property qpAttributeValueList . . . . . . . 60
` 8.13. The Class QoSPolicyRSVPVariable . . . . . . . . . . . . 60
` 8.14. The Class QoSPolicyRSVPSourceIPv4Variable . . . . . . . 61
` 8.15. The Class QoSPolicyRSVPDestinationIPv4Variable. . . . . 61
` 8.16. The Class QoSPolicyRSVPSourceIPv6Variable . . . . . . . 62
` 8.17. The Class QoSPolicyRSVPDestinationIPv6Variable. . . . . 62
` 8.18. The Class QoSPolicyRSVPSourcePortVariable . . . . . . . 62
` 8.19. The Class QoSPolicyRSVPDestinationPortVariable. . . . . 63
` 8.20. The Class QoSPolicyRSVPIPProtocolVariable . . . . . . . 63
` 8.21. The Class QoSPolicyRSVPIPVersionVariable. . . . . . . . 63
` 8.22. The Class QoSPolicyRSVPDCLASSVariable . . . . . . . . . 64
` 8.23. The Class QoSPolicyRSVPStyleVariable. . . . . . . . . . 64
` 8.24. The Class QoSPolicyRSVPIntServVariable. . . . . . . . . 65
` 8.25. The Class QoSPolicyRSVPMessageTypeVariable. . . . . . . 65
` 8.26. The Class QoSPolicyRSVPPreemptionPriorityVariable . . . 65
` 8.27. The Class QoSPolicyRSVPPreemptionDefPriorityVariable. . 66
` 8.28. The Class QoSPolicyRSVPUserVariable . . . . . . . . . . 66
` 8.29. The Class QoSPolicyRSVPApplicationVariable. . . . . . . 66
` 8.30. The Class QoSPolicyRSVPAuthMethodVariable . . . . . . . 67
` 8.31. The Class QosPolicyDNValue. . . . . . . . . . . . . . . 67
` 8.31.1. The Property qpDNList . . . . . . . . . . . . . 68
` 8.32. The Class QoSPolicyRSVPSimpleAction . . . . . . . . . . 68
` 8.32.1. The Property qpRSVPActionType . . . . . . . . . 68
` 9. Intellectual Property Rights Statement. . . . . . . . . . . . 69
` 10. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 69
` 11. Security Considerations . . . . . . . . . . . . . . . . . . . 69
` 12. References. . . . . . . . . . . . . . . . . . . . . . . . . . 70
` 12.1. Normative References . . . . . . . . . . . . . . . . . 70
` 12.2. Informative References . . . . . . . . . . . . . . . . 70
` 13. Authors’ Addresses. . . . . . . . . . . . . . . . . . . . . . 72
` 14. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 73
`
`Snir, et al. Standards Track [Page 4]
`
`Arista Networks, Inc.
`Ex. 1027, p. 4
`
`

`

`RFC 3644 Policy QoS Information Model November 2003
`
`1. Introduction
`
` The QoS Policy Information Model (QPIM) establishes a standard
` framework and constructs for specifying and representing policies
` that administer, manage, and control access to network QoS resources.
` Such policies will be referred to as "QoS policies" in this document.
` The framework consists of a set of classes and relationships that are
` organized in an object-oriented information model. It is agnostic of
` any specific Policy Decision Point (PDP) or Policy Enforcement Point
` (PEP) (see [TERMS] for definitions) implementation, and independent
` of any particular QoS implementation mechanism.
`
` QPIM is designed to represent QoS policy information for large-scale
` policy domains (the term "policy domain" is defined in [TERMS]). A
` primary goal of this information model is to assist human
` administrators in their definition of policies to control QoS
` resources (as opposed to individual network element configuration).
` The process of creating QPIM data instances is fed by business rules,
` network topology and QoS methodology (e.g., Differentiated Services).
`
` This document is based on the IETF Policy Core Information Model and
` its extensions as specified by [PCIM] and [PCIMe]. QPIM builds upon
` these two documents to define an information model for QoS
` enforcement for differentiated and integrated services ([DIFFSERV]
` and [INTSERV], respectively) using policy. It is important to note
` that this document defines an information model, which by definition
` is independent of any particular data storage mechanism and access
` protocol. This enables various data models (e.g., directory
` schemata, relational database schemata, and SNMP MIBs) to be designed
` and implemented according to a single uniform model.
`
` The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
` "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
` document are to be interpreted as described in BCP 14, RFC 2119
` [KEYWORDS].
`
`1.1. The Process of QoS Policy Definition
`
` This section describes the process of using QPIM for the definition
` QoS policy for a policy domain. Figure 1 illustrates information
` flow and not the actual procedure, which has several loops and
` feedback not depicted.
`
`Snir, et al. Standards Track [Page 5]
`
`Arista Networks, Inc.
`Ex. 1027, p. 5
`
`

`

`RFC 3644 Policy QoS Information Model November 2003
`
` ---------- ---------- -----------
` | Business | | Topology | | QoS |
` | Policy | | | |Methodology|
` ---------- ---------- -----------
` | | |
` | | |
` ------------------------------------
` |
` V
` ---------------
` | QPIM/PCIM(e) |
` | modeling |
` ---------------
` |
` | --------------
` |<----------| Device info, |
` | | capabilities |
` | --------------
` V
` (---------------)
` ( device )---)
` ( configuration ) )---)
` (---------------) ) )
` (--------------) )
` (-------------)
`
` Figure 1: The QoS definition information flow
`
` The process of QoS policy definition is dependent on three types of
` information: the topology of the network devices under management,
` the particular type of QoS methodology used (e.g., DiffServ) and the
` business rules and requirements for specifying service(s) [TERMS]
` delivered by the network. Both topology and business rules are
` outside the scope of QPIM. However, important facets of both must be
` known and understood for correctly specifying the QoS policy.
`
` Typically, the process of QoS policy definition relies on a
` methodology based on one or more QoS methodologies. For example, the
` DiffServ methodology may be employed in the QoS policy definition
` process.
`
` The topology of the network consists of an inventory of the network
` elements that make up the network and the set of paths that traffic
` may take through the network. For example, a network administrator
` may decide to use the DiffServ architectural model [DIFFSERV] and
` classify network devices using the roles "boundary" and "core" (see
` [TERMS] for a definition of role, and [PCIM] for an explanation of
`
`Snir, et al. Standards Track [Page 6]
`
`Arista Networks, Inc.
`Ex. 1027, p. 6
`
`

`

`RFC 3644 Policy QoS Information Model November 2003
`
` how they are used in the policy framework). While this is not a
` complete topological view of the network, many times it may suffice
` for the purpose of QoS policy definition.
`
` Business rules are informal sets of requirements for specifying the
` behavior of various types of traffic that may traverse the network.
` For example, the administrator may be instructed to implement policy
` such that VoIP traffic manifests behavior that is similar to legacy
` voice traffic over telephone networks. Note that this business rule
` (indirectly) prescribes specific behavior for this traffic type
` (VoIP), for example in terms of minimal delay, jitter and loss.
` Other traffic types, such as WEB buying transactions, system backup
` traffic, video streaming, etc., will express their traffic
` conditioning requirements in different terms. Again, this
` information is required not by QPIM itself, but by the overall policy
` management system that uses QPIM. QPIM is used to help map the
` business rules into a form that defines the requirements for
` conditioning different types of traffic in the network.
`
` The topology, QoS methodology, and business rules are necessary
` prerequisites for defining traffic conditioning. QPIM enables a set
` of tools for specifying traffic conditioning policy in a standard
` manner. Using a standard QoS policy information model such as QPIM
` is needed also because different devices can have markedly different
` capabilities. Even the same model of equipment can have different
` functionality if the network operating system and software running in
` those devices is different. Therefore, a means is required to
` specify functionality in a standard way that is independent of the
` capabilities of different vendors’ devices. This is the role of
` QPIM.
`
` In a typical scenario, the administrator would first determine the
` role(s) that each interface of each network element plays in the
` overall network topology. These roles define the functions supplied
` by a given network element independent of vendor and device type.
` The [PCIM] and [PCIMe] documents define the concept of a role. Roles
` can be used to identify what parts of the network need which type of
` traffic conditioning. For example, network interface cards that are
` categorized as "core" interfaces can be assigned the role name
` "core-interface". This enables the administrator to design policies
` to configure all interfaces having the role "core-interface"
` independent of the actual physical devices themselves. QPIM uses
` roles to help the administrator map a given set of devices or
` interfaces to a given set of policy constructs.
`
`Snir, et al. Standards Track [Page 7]
`
`Arista Networks, Inc.
`Ex. 1027, p. 7
`
`

`

`RFC 3644 Policy QoS Information Model November 2003
`
` The policy constructs define the functionality required to perform
` the desired traffic conditioning for particular traffic type(s). The
` functions themselves depend on the particular type of networking
` technologies chosen. For example, the DiffServ methodology
` encourages us to aggregate similar types of traffic by assigning to
` each traffic class a particular per-hop forwarding behavior on each
` node. RSVP enables bandwidth to be reserved. These two
` methodologies can be used separately or in conjunction, as defined by
` the appropriate business policy. QPIM provides specific classes to
` enable DiffServ and RSVP conditioning to be modeled.
`
` The QPIM class definitions are used to create instances of various
` policy constructs such as QoS actions and conditions that may be
` hierarchically organized in rules and groups (PolicyGroup and
` PolicyRule as defined in [PCIM] and [PCIMe]). Examples of policy
` actions are rate limiting, jitter control and bandwidth allocation.
` Policy conditions are constructs that can select traffic according to
` a complex Boolean expression.
`
` A hierarchical organization was chosen for two reasons. First, it
` best reflects the way humans tend to think about complex policy.
` Second, it enables policy to be easily mapped onto administrative
` organizations, as the hierarchical organization of policy mirrors
` most administrative organizations. It is important to note that the
` policy definition process described here is done independent of any
` specific device capabilities and configuration options. The policy
` definition is completely independent from the details of the
` implementation and the configuration interface of individual network
` elements, as well as of the mechanisms that a network element can use
` to condition traffic.
`
`1.2. Design Goals and Their Ramifications
`
` This section explains the QPIM design goals and how these goals are
` addressed in this document. This section also describes the
` ramifications of the design goals and the design decisions made in
` developing QPIM.
`
`1.2.1. Policy-Definition Oriented
`
` The primary design goal of QPIM is to model policies controlling QoS
` behavior in a way that as closely as possible reflects the way humans
` tend to think about policy. Therefore, QPIM is designed to address
` the needs of policy definition and management, and not device/network
` configuration.
`
`Snir, et al. Standards Track [Page 8]
`
`Arista Networks, Inc.
`Ex. 1027, p. 8
`
`

`

`RFC 3644 Policy QoS Information Model November 2003
`
` There are several ramifications of this design goal. First, QPIM
` uses rules to define policies, based on [PCIM] and [PCIMe]. Second,
` QPIM uses hierarchical organizations of policies and policy
` information extensively. Third, QPIM does not force the policy
` writer to specify all implementation details; rather, it assumes that
` configuration agents (PDPs) interpret the policies and match them to
` suit the needs of device-specific configurations.
`
`1.2.1.1. Rule-based Modeling
`
` Policy is best described using rule-based modeling as explained and
` described in [PCIM] and [PCIMe]. A QoS policy rule is structured as
` a condition clause and an action clause. The semantics are simple:
` if the condition clause evaluates to TRUE, then a set of QoS actions
` (specified in the action clause) can be executed. For example, the
` rule:
`
` "WEB traffic should receive at least 50% of the available
` bandwidth resources or more, when more is available"
`
` can be formalized as:
`
` "<If protocol == HTTP> then <minimum BW = 50%>"
`
` where the first angle bracketed clause is a traffic condition and the
` second angle bracketed clause is a QoS action.
`
` This approach differs from data path modeling that describes the
` mechanisms that operates on the packet flows to achieve the desired
` effect.
`
` Note that the approach taken in QPIM specifically did NOT subclass
` the PolicyRule class. Rather, it uses the SimplePolicyCondition,
` CompoundPolicyCondition, SimplePolicyAction, and CompoundPolicyAction
` classes defined in [PCIMe], as well as defining subclasses of the
` following classes: Policy, PolicyAction, SimplePolicyAction,
` PolicyImplicitVariable, and PolicyValue. Subclassing the PolicyRule
` class would have made it more difficult to combine actions and
` conditions defined within different functional domains [PCIMe] within
` the same rules.
`
`1.2.1.2. Organize Information Hierarchically
`
` The organization of the information represented by QPIM is designed
` to be hierarchical. To do this, QPIM utilizes the PolicySetComponent
` aggregation [PCIMe] to provide an arbitrarily nested organization of
` policy information. A policy group functions as a container of
`
`Snir, et al. Standards Track [Page 9]
`
`Arista Networks, Inc.
`Ex. 1027, p. 9
`
`

`

`RFC 3644 Policy QoS Information Model November 2003
`
` policy rules and/or policy groups. A policy rule can also contain
` policy rules and/or groups, enabling a rule/sub-rule relationship to
` be realized.
`
` The hierarchical design decision is based on the realization that it
` is natural for humans to organize policy rules in groups. Breaking
` down a complex policy into a set of simple rules is a process that
` follows the way people tend to think and analyze systems. The
` complexity of the abstract, business-oriented policy is simplified
` and made into a hierarchy of simple rules and grouping of simple
` rules.
`
` The hierarchical information organization helps to simplify the
` definition and readability of data instances based on QPIM.
` Hierarchies can also serve to carry additional semantics for QoS
` actions in a given context. An example, detailed in section 2.3,
` demonstrates how hierarchical bandwidth allocation policies can be
` specified in an intuitive form, without the need to specify complex
` scheduler structures.
`
`1.2.1.3. Goal-Oriented Policy Definition
`
` QPIM facilitates goal-oriented QoS policy definition. This means
` that the process of defining QoS policy is focused on the desired
` effect of policies, as opposed to the means of implementing the
` policy on network elements.
`
` QPIM is intended to define a minimal specification of desired network
` behavior. It is the role of device-specific configuration agents to
` interpret policy expressed in a standard way and fill in the
` necessary configuration details that are required for their
` particular application. The benefit of using QPIM is that it
` provides a common lingua franca that each of the device- and/or
` vendor-specific configuration agents can use. This helps ensure a
` common interpretation of the general policy as well as aid the
` administrator in specifying a common policy to be implemented across
` different devices. This is analogous to the fundamental object-
` oriented paradigm of separating specification from implementation.
` Using QPIM, traffic conditioning can be specified in a general manner
` that can help different implementations satisfy a common goal.
`
` For example, a valid policy may include only a single rule that
` specifies that bandwidth should be reserved for a given set of
` traffic flows. The rule does not need to include any of the various
` other details that may be needed for implementing a scheduler that
` supports this bandwidth allocation (e.g., the queue length required).
` It is assumed that a PDP or the PEPs would fill in these details
` using (for example) their default queue length settings. The policy
`
`Snir, et al. Standards Track [Page 10]
`
`Arista Networks, Inc.
`Ex. 1027, p. 10
`
`

`

`RFC 3644 Policy QoS Information Model November 2003
`
` writer need only specify the main goal of the policy, making sure
` that the preferred application receives enough bandwidth to operate
` adequately.
`
`1.2.2. Policy Domain Model
`
` An important design goal of QPIM is to provide a means for defining
` policies that span numerous devices. This goal differentiates QPIM
` from device-level information models, which are designed for modeling
` policy that controls a single device, its mechanisms and
` capabilities.
`
` This design goal has several ramifications. First, roles [PCIM] are
` used to define policies across multiple devices. Second, the use of
` abstract policies frees the policy definition process from having to
` deal with individual device peculiarities, and leaves interpretation
` and configuration to be modeled by PDPs or other configuration
` agents. Third, QPIM allows extensive reuse of all policy building
` blocks in multiple rules used within different devices.
`
`1.2.2.1. Model QoS Policy in a Device- and Vendor-Independent Manner
`
` QPIM models QoS policy in a way designed to be independent of any
` particular device or vendor. This enables networks made up of
` different devices that have different capabilities to be managed and
` controlled using a single standard set of policies. Using such a
` single set of policies is important because otherwise, the policy
` will itself reflect the differences between different device
` implementations.
`
`1.2.2.2. Use Roles for Mapping Policy to Network Devices
`
` The use of roles enables a policy definition to be targeted to the
` network function of a network element, rather than to the element’s
` type and capabilities. The use of roles for mapping policy to
` network elements provides an efficient and simple method for compact
` and abstract policy definition. A given abstract policy may be
` mapped to a group of network elements without the need to specify
` configuration for each of those elements based on the capabilities of
` any one individual element.
`
` The policy definition is designed to allow aggregating multiple
` devices within the same role, if desired. For example, if two core
` network interfaces operate at different rates, one does not have to
` define two separate policy rules to express the very same abstract
` policy (e.g., allocating 30% of the interface bandwidth to a given
`
`Snir, et al. Standards Track [Page 11]
`
`Arista Networks, Inc.
`Ex. 1027, p. 11
`
`

`

`RFC 3644 Policy QoS Information Model November 2003
`
` preferred set of flows). The use of hierarchical context and
` relative QoS actions in QPIM addresses this and other related
` problems.
`
`1.2.2.3. Reusability
`
` Reusable objects, as defined by [PCIM] and [PCIMe], are the means for
` sharing policy building blocks, thus allowing central management of
` global concepts. QPIM provides the ability to reuse all policy
` building blocks: variables and values, conditions and actions,
` traffic profiles, and policy groups and policy rules. This provides
` the required flexibility to manage large sets of policy rules over
` large policy domains.
`
` For example, the following rule makes use of centrally defined
` objects being reused (referenced):
`
` If <DestinationAddress == FinanceSubNet> then <DSCP =
` MissionCritical>
`
` In this rule, the condition refers to an object named FinanceSubNet,
` which is a value (or possibly a set of values) defined and maintained
` in a reusable objects container. The QoS action makes use of a value
` named MissionCritical, which is also a reusable object. The
` advantage of specifying a policy in this way is its inherent
` flexibility. Given the above policy, whenever business needs require
` a change in the subnet definition for the organization, all that’s
` required is to change the reusable value FinanceSubNet centrally.
` All referencing rules are immediately affected, without the need to
` modify them individually. Without this capability, the repository
` that is used to store the rules would have to be searched for all
` rules that refer to the finance subnet, and then each matching rule’s
` condition would have to be individually updated. This is not only
` much less efficient, but also is more prone to error.
`
` For a complet