RFC 3644
Policy Quality of Service (QoS) Information Model
RFC 3644: Policy Quality of Service (QoS) Information Model 🎀
okay bestie, this is the RFC that describes an information model for QoS policies, so it's basically the blueprint for how networks decide who gets priority and how much. 💅 it was published in November 2003 as a Standards Track document, which means it's on the official protocol path, not just a vibe-check. the authors are Y. Snir, Y. Ramberg (from Cisco Systems), J. Strassner (from Intelliden), R. Cohen (from Ntear LLC), and B. Moore (from IBM). 🌈 quick note: the title block doesn't say anything about it obsoleting or updating another RFC, so I'm not making that up for you. 🙈
Status of this Memo 📜
this document is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🦋 if you want the current standardization state and status of this protocol, check the latest edition of the "Internet Official Protocol Standards" (STD 1). and yes, distribution of this memo is unlimited 💜
Copyright Notice ©️
Copyright (C) The Internet Society (2003). All Rights Reserved. 🫶
Abstract ✨
okay so this doc gives you an object-oriented information model for representing Quality of Service (QoS) network management policies 🔥 it's built on top of the IETF Policy Core Information Model and its extensions, and it defines a model for QoS enforcement for differentiated and integrated services using policy. the big thing to remember is that this is an information model, which by definition doesn't care about any particular data storage mechanism or access protocol. it's the idea, not the plumbing 🧚
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
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
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. . . . . . . . . . . . . . . . . . . 731. Introduction ✨
okay so the QoS Policy Information Model (QPIM) is basically the standard playbook for writing down policies that decide who gets to use QoS network resources and how. we'll call those "QoS policies" in this doc 💅. the framework is a bunch of classes and relationships organized as an object-oriented information model. it doesn't care which Policy Decision Point (PDP) or Policy Enforcement Point (PEP) you're using (see [TERMS] for definitions) 🦋, and it doesn't care what QoS mechanism is running underneath either 🧚.
QPIM is built for huge policy domains (the term "policy domain" is defined in [TERMS]) 🌸. its main goal is helping human admins define policies for QoS resources, instead of fiddling with each individual network element's config 🫶. the data instances come from business rules, network topology, and QoS methodology (for example, Differentiated Services) 🎀.
this document builds on the IETF Policy Core Information Model and its extensions, specified in [PCIM] and [PCIMe] 💜. QPIM takes those two and uses them to define an information model for QoS enforcement with policy, covering differentiated and integrated services ([DIFFSERV] and [INTSERV], respectively) ✨. important bit: this is an information model, which means it's independent of any particular data storage mechanism and access protocol 🍓. so the same uniform model can be turned into different data models, like directory schemata, relational database schemata, and SNMP MIBs 🌈. it's giving one blueprint, many outfits 👑.
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 walks through how you actually use QPIM to define QoS policy for a policy domain 💖. heads up: Figure 1 shows the information flow, not the real procedure, which has a bunch of loops and feedback that aren't drawn 🙈.
---------- ---------- -----------
| Business | | Topology | | QoS |
| Policy | | | |Methodology|
---------- ---------- -----------
| | |
| | |
------------------------------------
|
V
---------------
| QPIM/PCIM(e) |
| modeling |
---------------
|
| --------------
|<----------| Device info, |
| | capabilities |
| --------------
V
(---------------)
( device )---)
( configuration ) )---)
(---------------) ) )
(--------------) )
(-------------)
Figure 1: The QoS definition information flowso QoS policy definition runs on three kinds of info 🧠: the topology of the network devices being managed, the QoS methodology in use (like DiffServ) 🦋, and the business rules and requirements for the service(s) [TERMS] the network delivers 💅. topology and business rules are outside QPIM's scope, but you still need to really understand important parts of both to specify QoS policy correctly 🫶.
usually, QoS policy definition leans on a methodology built from one or more QoS methodologies 🎀. for instance, the DiffServ methodology can be part of that process ✨.
the topology is basically an inventory of the network elements plus the set of paths traffic can take through them 🗺️. say a network admin decides to use the DiffServ architectural model [DIFFSERV] and sorts devices into the roles "boundary" and "core" (see [TERMS] for what a role is, and [PCIM] for how roles get used in the policy framework) 🌸. it's not a full topology picture, but honestly it can be enough for QoS policy definition 🙌.
business rules are informal requirements about how different kinds of traffic should behave on the network 💜. for example, an admin might be told to make VoIP traffic act like old-school voice traffic on telephone networks 📞. that rule quietly dictates behavior for that traffic type (VoIP), like minimal delay, jitter, and loss 😭. other traffic, like WEB buying transactions, system backup traffic, video streaming, and so on, will state its traffic conditioning needs in different terms 🍓. again, QPIM doesn't need this info itself, but the overall policy management system that uses QPIM does 🧚. QPIM helps turn those business rules into requirements for conditioning each traffic type in the network 👑.
the topology, QoS methodology, and business rules are the must-have prerequisites for defining traffic conditioning 🔥. QPIM gives you a set of tools to specify traffic conditioning policy in a standard way ✨. a standard QoS policy information model like QPIM matters because different devices can be wildly different in what they can do 🙈. even the same equipment model can behave differently if the network operating system and software on it are different 💀. so you need a way to specify functionality in a standard manner that doesn't depend on each vendor's device capabilities. that's QPIM's whole job 🎀.
in a typical scenario, the admin first works out the role(s) each interface of each network element plays in the overall topology 🗺️. those roles describe what a given network element does, regardless of vendor and device type 💖. the [PCIM] and [PCIMe] documents define what a role is 🦋. roles help you figure out which parts of the network need which type of traffic conditioning 🌸. for example, network interface cards categorized as "core" interfaces can be given the role name "core-interface" 💜. that lets the admin design policies that configure all interfaces with the role "core-interface", no matter which physical devices they're on 😭. QPIM uses roles to help the admin map a set of devices or interfaces to a set of policy constructs 🫶.
the policy constructs spell out the functionality needed to do the desired traffic conditioning for particular traffic type(s) ✨. those functions depend on the networking technology chosen 🧠. the DiffServ methodology, for example, encourages you to group similar traffic together by giving each traffic class a particular per-hop forwarding behavior on each node 🎀. RSVP lets you reserve bandwidth 💅. these two methodologies can be used on their own or together, depending on the appropriate business policy 🌈. QPIM has specific classes so DiffServ and RSVP conditioning can both be modeled 👑.
the QPIM class definitions get used to create instances of different policy constructs, like QoS actions and conditions 🍓. those can be organized hierarchically inside 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 pick out traffic using a complex Boolean expression 🔥.
the hierarchical setup was picked for two reasons 💖. first, it best matches the way humans tend to think about complicated policy 🧠. second, it makes policy easy to map onto administrative organizations, since hierarchical policy mirrors most admin orgs 🏢. note that this policy definition process happens without any reference to specific device capabilities and configuration options 🫶. the definition is completely separate from the implementation details, the configuration interface of individual network elements, and the mechanisms a network element can use to condition traffic 🌸.
1.2. Design Goals and Their Ramifications 🎀
this section covers QPIM's design goals and how this document addresses them 💜. it also covers what those goals lead to, and the design decisions made while building QPIM 🦋.
1.2.1. Policy-Definition Oriented 💅
QPIM's number one design goal is modeling policies that control QoS behavior in a way that matches, as closely as possible, how humans think about policy 🫶. so QPIM is built for policy definition and management, not device/network configuration 🌈.
this goal has a few ramifications 👑. first, QPIM uses rules to define policies, based on [PCIM] and [PCIMe] ✨. second, QPIM leans hard on hierarchical organizations of policies and policy information 🌳. third, QPIM doesn't make the policy writer spell out every implementation detail 🧚. instead, it assumes configuration agents (PDPs) will interpret the policies and match them to what each device's configuration needs 🍓.
1.2.1.1. Rule-based Modeling 🔥
policy works best when it's described with rule-based modeling, as explained in [PCIM] and [PCIMe] 💖. a QoS policy rule is made of a condition clause and an action clause 🧠. the logic is simple: if the condition clause evaluates to TRUE, then the set of QoS actions in the action clause can be executed 🦋. for example, take this rule:
"WEB traffic should receive at least 50% of the available
bandwidth resources or more, when more is available"it 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 is different from data path modeling, which describes the mechanisms that operate on packet flows to get the desired effect 🌸.
also, the QPIM approach did not subclass the PolicyRule class 🙅♀️. instead, it uses the SimplePolicyCondition, CompoundPolicyCondition, SimplePolicyAction, and CompoundPolicyAction classes defined in [PCIMe], and it defines subclasses of these classes: Policy, PolicyAction, SimplePolicyAction, PolicyImplicitVariable, and PolicyValue 💜. subclassing PolicyRule would have made it harder to combine actions and conditions defined in different functional domains [PCIMe] within the same rules 😭.
1.2.1.2. Organize Information Hierarchically 🌸
Okay so QPIM organizes its info in a hierarchy, and it's giving tidy-closet energy 🧚. It uses the PolicySetComponent aggregation [PCIMe] to nest policy info as deeply as you need ✨. A policy group is basically a container that holds policy rules and/or other policy groups. A policy rule can hold its own rules and/or groups too, so you get that rule/sub-rule relationship 💅.
Why the hierarchy? Because humans naturally group rules together 🫶. Breaking a complicated policy into simple rules and then bundling those rules into groups is just how people think about systems 🧠. So the messy, business-oriented policy turns into a tree of simple rules and groups of simple rules 🌈.
This makes data instances based on QPIM easier to define and easier to read 📖. Hierarchies can also carry extra meaning for QoS actions in a given context 🎀. Section 2.3 shows this off: hierarchical bandwidth allocation policies can be written in a super intuitive way, with no need to write out complicated scheduler structures 😭👑.
1.2.1.3. Goal-Oriented Policy Definition 🦋
QPIM is all about goal-oriented QoS policy definition 🎯. The focus is on the desired effect of a policy, not on the means of implementing it on network elements. Main character energy: what you want happens, and the how is someone else's problem 💅.
QPIM is meant to define a minimal specification of desired network behavior 🌸. Device-specific configuration agents are the ones who read policy written in a standard way and fill in the config details their particular application needs 🔧. The big win is that QPIM gives everyone a common lingua franca that each device- and/or vendor-specific configuration agent can speak 🗣️💖. That helps make sure everyone interprets the general policy the same way, and it helps the admin write one common policy that works across different devices 🫶. It's basically the object-oriented idea of separating specification from implementation, and I'm obsessed 😭. With QPIM, traffic conditioning can be described in a general way that lets different implementations all hit the same goal ✨.
For example, a valid policy can be just one rule saying bandwidth should be reserved for a given set of traffic flows 🎀. The rule doesn't need any of the other details a scheduler might need to actually support that allocation, like the queue length 🙈. It's assumed that a PDP or the PEPs will fill those in using (for example) their default queue length settings 🧚. The policy writer only needs to name the main goal, making sure the preferred application gets enough bandwidth to run adequately 💜.
1.2.2. Policy Domain Model 🌈
QPIM has a big design goal: letting you define policies that span lots of devices 🌐. That's what sets it apart from device-level information models, which are built to model policy controlling one single device, its mechanisms, and its capabilities 💅.
That goal has a few ramifications, and they're iconic. First, roles [PCIM] are used to define policies across multiple devices 👑. Second, abstract policies mean the policy definition process doesn't have to deal with each device's quirks 🙈. Interpretation and configuration get left to PDPs or other configuration agents instead 🧚. Third, QPIM allows extensive reuse of all policy building blocks across rules used on different devices 🔁✨.
1.2.2.1. Model QoS Policy in a Device- and Vendor-Independent Manner 🦋
QPIM models QoS policy in a way that's designed to be independent of any particular device or vendor 💖. That means networks made of different devices with different capabilities can be managed and controlled with one standard set of policies 🫶. This matters because, otherwise, the policy itself ends up reflecting the differences between device implementations 😭.
1.2.2.2. Use Roles for Mapping Policy to Network Devices 🎀
Roles let a policy target the network function of a network element, instead of its type and capabilities 🎯. That makes mapping policy to elements efficient and simple, which is so compact and abstract 💅. An abstract policy can map onto a whole group of network elements without you having to specify config for each one based on the capabilities of any single element 🌸.
The policy definition also lets you aggregate multiple devices into the same role, if you want 🧚. For example, if two core network interfaces run at different rates, you don't need two separate policy rules to say the very same abstract thing, like allocating 30% of the interface bandwidth to a given preferred set of flows 🙌. The hierarchical context and relative QoS actions in QPIM handle this and other related problems ✨.
1.2.2.3. Reusability 🔁
Reusable objects, as defined by [PCIM] and [PCIMe], are how you share policy building blocks, so global concepts can be managed centrally 🌍. QPIM lets you reuse all policy building blocks: variables and values, conditions and actions, traffic profiles, and policy groups and policy rules 💜. That's the flexibility you need to manage huge sets of policy rules across huge policy domains 🫶.
Here's an example of a rule that reuses centrally defined objects (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 uses a value named MissionCritical, which is also a reusable object 🎀. The best part is how flexible this is 🦋. Say business needs change the subnet definition for the organization. All you do is change the reusable value FinanceSubNet centrally, and every referencing rule is immediately affected, no individual edits needed 🙌✨. Without this, you'd have to search the repository holding the rules for every rule that refers to the finance subnet, then update each matching rule's condition by hand 😵. That's way less efficient and way more prone to error 💀.
For a complete description of reusable objects, check out [PCIM] and [PCIMe] 📚.
1.2.3. Enforceable Policy 💅
Policy defined by QPIM should be enforceable 🔐. That means a PDP can use QPIM's policy definition to make the necessary decisions and enforce the required policy rules 👑. For example, RSVP admission decisions should be made based on the policy definitions QPIM specifies 🌊. A PDP should be able to map QPIM policy definitions into PEP configurations, using either standard or proprietary protocols 🧚.
QPIM is designed to be agnostic of any particular vendor-dependent technology 🌈. Still, QPIM's constructs SHOULD always be interpreted so that policy-compliant behavior can be enforced on the network under management 🫶. So there are three fundamental requirements QPIM has to satisfy 📝:
- Policy specified by QPIM must be able to be mapped to actual network elements.
- Policy specified by QPIM must be able to control QoS network functions without making reference to a specific type of device or vendor.
- Policy specified by QPIM must be able to be translated into network element configuration.
QPIM satisfies requirements #1 and #2 by using the concept of roles (specifically, the PolicyRoles property, defined in PCIM) 🎀. By matching roles assigned to policy groups and to network elements, a PDP (or other enforcement agent) can figure out what policy should be applied to a given device or devices 🔍.
Roles also support model scalability 📈. QPIM policy can be mapped to large-scale policy domains by assigning a single role to a group of network elements 🌍. That works even when the domain has heterogeneous devices 🧩. So a small set of policies can be deployed across big networks without re-specifying the policy for each device separately 🙌. This is a huge deal for QoS policy management apps that want to make defining policy for large domains way less painful 💖.
Requirement #2 is also satisfied by making QPIM domain-oriented (see [TERMS] for a definition of "domain") 🌐. In other words, the target of the policy is a domain, not a specific device or interface 🎯.
Requirement #3 is satisfied by modeling QoS conditions and actions that are commonly configured on various devices 🛠️. QPIM is also extensible, so you can model actions that aren't included in QPIM yet 🧚.
It's important to note that different PEPs have different capabilities and functions 🙈. That means they need different individual configurations, even when the same policy controls them all 💅.
1.2.4. QPIM Covers Both Signaled And Provisioned QoS ✨
The two predominant standards-based QoS methodologies developed so far are Differentiated Services (DiffServ) and Integrated Services (IntServ) 🌈. DiffServ gives you a way to enforce policies across a large number of devices in a scalable way 📡. QPIM provides actions and conditions that control the classification, policing, and shaping done within the differentiated service domain boundaries 🎀. It also has actions that control the per-hop behavior inside the core of a DiffServ network 🦋. QPIM does not mandate the use of DiffServ as a policy methodology, so you're not locked in 🔓.
Integrated Services, together with its signaling protocol (RSVP), gives end nodes (and edge nodes) a way to request QoS from the network 🙌. QPIM provides actions that control the reservation of those requests within the network 💜.
As both methodologies keep evolving, QPIM doesn't try to cover every possible scenario 🫶. Instead, QPIM aims to provide policy control modeling for all the major scenarios 👑. It's designed to be extensible, so control over newly developed QoS mechanisms can be added later 🌸💅.
1.2.5. Interoperability for PDPs and Management Applications 🤝💖
Okay bestie, so another big goal of QPIM is making policy systems like PDPs and policy management apps actually get along 🫶. It does this by standardizing how policy is represented. Producers and consumers of QoS policy only need to rely on QPIM-based schemata (and the data models that come out of them) to be sure they're on the same page about what the QoS policy means 🎀.
Picture this: a QoS policy management app from vendor A writes its policies based on the LDAP schema that maps from QPIM to a directory implementation using LDAP. Now a totally separate PDP from vendor B also uses that same LDAP schema derived from QPIM. Two different vendors, two different PDPs, and yet each can read the other's schema and "understand" it 🤯. Why? Because both the management app and the PDP were built to comply with the QPIM spec. Same energy with two policy management apps too. Like, vendor B's policy app might run a validation tool that checks whether there are conflicts within rules written by the other vendor's policy management app 🔍✨.
Now, the tea ☕: interoperability of QPIM producers and consumers is high-level by definition, and it does not guarantee that the same policy will result in the same PEP configuration 🙈. First, different PEPs have different capabilities and functions, so they need different individual configurations even if the same policy is controlling them 🧩. Second, different PDPs also have different capabilities and functions, and they may choose to translate the high-level QPIM policy differently depending on the PDP's functionality, as well as on the capabilities of the PEPs being controlled by that PDP 🌸. Still, the different configurations should still result in the same network behavior as the one specified by the policy rules 💅👑.
1.3. Modeling Abstract QoS Policies 🦋
This section talks about QoS policy abstraction and how QPIM deals with it 🧚.
As we said above, the main goal of QPIM is to create an information model that helps bridge part of the conceptual gap between a human policy maker and a network element that's configured to enforce the policy 🌈. And honestly, that gap is huge, so it implies several translation levels, going from the abstract to the concrete 😭. On the abstract end we have the business QoS policy rules. Once those business rules are known, a network administrator has to interpret them as network QoS policy and represent that policy using QPIM constructs. QPIM gives us a formal representation of QoS rules, which provides the first concretization level: formally representing humanly expressed QoS policy 📝✨.
When a human business executive defines network policy, it's usually done with informal business terms and language 💼. For example, a human might say something like:
"human resources applications should have better QoS than simple web applications"
That could get translated into something a bit more sophisticated, like:
"traffic generated by our human resources applications should have a higher probability of communicating with its destinations than traffic generated by people browsing the WEB using non-mission- critical applications"
This statement clearly defines QoS policy at the business level, but it isn't specific enough to be enforceable by network elements. It still needs translating into "network terms and language" 🔁.
On the other end of the scale, a network element functioning as a PEP, such as a router, can be configured with specific commands that determine the operational parameters of its inner working QoS mechanisms 🛠️. For example, the (imaginary) command output-queue-depth = 100 may be an instruction to a network interface card of a router to allow up to 100 packets to be stored before subsequent packets are discarded (not forwarded) 📦. On a different device within the same network, that same instruction may look different, because a different vendor built that device or it has a different set of functions, and therefore a different implementation, even if it's from the same vendor 🤷♀️. On top of that, a particular PEP might not be able to create queues longer than, say, 50 packets, which could lead to a different instruction implementing the same QoS policy 😬.
So the first example shows 'abstract policy', and the second shows 'concrete configuration' 🎀. The first example also illustrates end-to-end policy, which covers the conditioning of application traffic throughout the network 🌍. The second example shows configuration for a particular PEP or a set of them. An end-to-end policy statement can only be enforced by configuring PEPs in various parts of the network, and the information model of policy and the information model of the mechanisms a PEP uses to implement that policy are vastly different 🙃.
The translation process from abstract business policy to concrete PEP configuration roughly goes like this 🪄:
- Informal business QoS policy is expressed by a human policy maker (e.g., "All executives' WEB requests should be prioritized ahead of other employees' WEB requests") 🗣️
- A network administrator analyzes the policy domain's topology and determines the roles of particular device interfaces. A role may be assigned to a large group of elements, which will result in mapping a particular policy to a large group of device interfaces 🗺️
- The network administrator models the informal policy using QPIM constructs, creating a formal representation of the abstract policy. For example, "If a packet's protocol is HTTP and its destination is in the 'EXECUTIVES' user group, then assign IPP 7 to the packet header" 📐💜
- The network administrator assigns roles to the policy groups created in the previous step, matching the network elements' roles assigned in step #2 above 🏷️
- A PDP translates the abstract policy constructs created in step #3 into device-specific configuration commands for all devices effected by the new policy (i.e., devices that have interfaces that are assigned a role matching the new policy constructs' roles). In this process, the PDP consults the particular devices' capabilities to determine the appropriate configuration commands implementing the policy 🧠
- For each PEP in the network, the PDP (or an agent of the PDP) issues the appropriate device-specific instructions necessary to enforce the policy 🚀
QPIM, PCIM and PCIMe are used in step #3 above 🌟.
1.4. Rule Hierarchy 🪆
Policy is described by a set of policy rules that may be grouped into subsets [PCIMe] 🗂️. Policy rules and policy groups can be nested within other policy rules, which gives us a hierarchical policy definition 🌳. Nested rules are also called sub-rules, and this document uses both terms interchangeably 💕. The aggregation PolicySetComponent (defined in [PCIMe] is used to represent the nesting of a policy rule or group in another policy rule 🧷.
The hierarchical policy rule definition makes policy more readable and reusable 📖✨. Within the QoS policy information model, hierarchy is used to model context or scope for the sub-rule actions. Within QPIM, bandwidth allocation policy actions and drop threshold actions use this hierarchal context 🎯. First, we give a detailed example of hierarchy in bandwidth allocation policies 💸. Then we compare flat and hierarchical policy representation. The use of hierarchy in drop threshold policies is described in a following subsection 👀. Last but not least, the restrictions on using rule hierarchies within QPIM are described 🔒🫶.
1.4.1. Use of Hierarchy Within Bandwidth Allocation Policies ✨
okay bestie, let's do a bandwidth example 🎀 The informal policy reads:
On any interface on which these rules apply, guarantee at least
30% of the interface bandwidth to UDP flows, and at least 40% of
the interface bandwidth to TCP flows.The QoS Policy information model follows the Policy Core information model 🧚 by using roles to say which interfaces the policy applies to. The policy doesn't assume every interface runs at the same speed or shares any other property, apart from being able to forward packets. Bandwidth is split between UDP and TCP flows as percentages of the available interface bandwidth. So if the available interface bandwidth is 1 Mbits/sec, this rule guarantees 300Kbits/sec to UDP flows. But if the interface bandwidth was only 64kbits/sec instead, the same rule would correspondingly guarantee 19.2kb/sec. the math is mathing 💅
This policy is modeled within QPIM using two policy rules of the form:
If (IP protocol is UDP) THEN (guarantee 30% of available BW) (1)
If (IP protocol is TCP) THEN (guarantee 40% of available BW) (2)Assume these two rules are grouped within a PolicySet [PCIMe] carrying the appropriate role combination. A possible implementation of these rules within a PEP would be a Weighted-Round-Robin scheduler with 3 queues. The first queue handles UDP traffic, the second handles TCP traffic, and the third handles the rest of the traffic. The weights of the Weighted-Round-Robin scheduler would be 30% for the first queue, 40% for the second queue and 30% for the last queue. so organized 🦋
The actions specifying the bandwidth guarantee implicitly assume that the bandwidth resource being guaranteed is the bandwidth available at the interface level. A PolicyRoleCollection is a class defined in [PCIMe] whose job is to identify the set of resources (in this example, interfaces) assigned to a particular role. So the type of managed elements aggregated within the PolicyRoleCollection defines the bandwidth resource being controlled. In our example, interfaces are aggregated within the PolicyRoleCollection, which means the rules specify bandwidth allocation to all interfaces that match a given role. Other behavior could be defined the same way by changing what gets aggregated within the PolicyRoleCollection. the flexibility is unmatched 🌈
Normally, a full specification of the rules would also need to indicate the direction of the traffic for which bandwidth allocation is being made. Using the direction variable defined in [PCIMe], the rules can be written like this:
If (direction is out)
If (IP protocol is UDP) THEN (guarantee 30% of available BW)
If (IP protocol is TCP) THEN (guarantee 40% of available BW)Indentation shows rule nesting. To save space, we'll leave the direction condition out from here on 🙈
Rule nesting lets you refine the scope of bandwidth allocation within a given traffic class forwarded via these interfaces. The example below adds two nested rules to refine bandwidth allocation for UDP and TCP applications:
If (IP protocol is UDP) THEN (guarantee 30% of available BW) (1)
If (protocol is TFTP) THEN (guarantee 10% of available BW) (1a)
If (protocol is NFS) THEN (guarantee 40% of available BW) (1b)
If (IP protocol is TCP) THEN (guarantee 40% of available BW) (2)
If (protocol is HTTP) THEN guarantee 20% of available BW) (2a)
If (protocol is FTP) THEN (guarantee 30% of available BW) (2b)Subrules 1a and 1b specify bandwidth allocation for UDP applications. The total bandwidth being partitioned among UDP applications is the bandwidth available for the UDP traffic class (i.e., 30%), not the total bandwidth available at the interface level. TFTP and NFS are guaranteed at least 10% and 40% of the total available bandwidth for UDP, while other UDP applications aren't guaranteed to receive anything. That means TFTP and NFS are guaranteed at least 3% and 12% of the total bandwidth. Similar logic applies to the TCP applications. nested rules are giving main character energy 👑
The point of this section is to show that a hierarchical policy representation lets you specify a finer level of granularity for bandwidth allocation than a non-hierarchical (flat) policy representation can. To see that, let's compare this set of rules with a flat rule representation. In the flat representation, the guaranteed bandwidth for TFTP flows is calculated by taking 10% of the bandwidth guaranteed to UDP flows, which gives 3% of the total interface bandwidth guarantee:
If (UDP AND TFTP) THEN (guarantee 3% of available BW) (1a)
If (UDP AND NFS) THEN (guarantee 12% of available BW) (1b)
If (other UDP APPs) THEN (guarantee 15% of available BW) (1c)
If (TCP AND HTTP) THEN guarantee 8% of available BW) (2a)
If (TCP AND FTP) THEN (guarantee 12% of available BW) (2b)
If (other TCP APPs) THEN (guarantee 20% of available BW) (2c)Are these two representations identical? Nope 🙅♀️ The bandwidth allocation is not the same. In the hierarchical representation, UDP applications are guaranteed 30% of the bandwidth. Suppose a single UDP flow from an application other than NFS or TFTP is running. In the hierarchical representation, that application gets 30% of the interface bandwidth, but in the flat representation it only gets 15% of the interface bandwidth. the difference is huge bestie 😭
A two-stage scheduler is best modeled by a hierarchical representation, whereas a flat representation may be realized by a non-hierarchical scheduler.
A schematic hierarchical Weighted-Round-Robin scheduler implementation that supports the hierarchical rule representation looks like this:
--UDP AND TFTP queue--10%
--UDP AND NFS queue--40%-Scheduler-30%--+
--Other UDP queue--50% A1 |
|
--TCP AND HTTP queue--20% |
--TCP AND FTP queue--30%-Scheduler-40%--Scheduler--Interface
--Other TCP queue--50% A2 | B
|
------------Non UDP/TCP traffic-----30%--+Scheduler A1 pulls packets from the 3 UDP queues according to the weights specified by the UDP sub-rule policy. Scheduler A2 pulls packets from the 3 TCP queues specified by the TCP sub-rule policy. The second-stage scheduler B schedules between UDP, TCP and all other traffic according to the policy in the top-most rule level. two layers of scheduling, one big brain move 🧠
Another difference between the flat and hierarchical representations is how bandwidth is divided above the minimum guarantee. Suppose two high-rate streams are forwarded via this interface: an HTTP stream and an NFS stream, and each flow's rate is far beyond the capacity of the interface. In the flat scheduler implementation, the ratio between the weights is 8:12 (i.e., HTTP:NFS), so the HTTP stream would consume 40% of the bandwidth while NFS would consume 60%. In the hierarchical scheduler implementation, the only scheduler with two queues filled is scheduler B, so the ratio between the HTTP (TCP) stream and the NFS (UDP) stream is 30:40. That means the HTTP stream consumes approximately 42% of the interface bandwidth while NFS consumes 58%. In both cases, the HTTP and NFS streams both get more than the minimum guaranteed bandwidth, but the actual rates forwarded via the interface differ. the numbers don't lie 📊
The conclusion: a hierarchical policy representation provides additional structure and context beyond the flat policy representation. Furthermore, policies specifying bandwidth allocation using rule hierarchies should be enforced using hierarchical schedulers, where the rule hierarchy level is mapped to the hierarchical scheduler level.
1.4.2. Use of Rule Hierarchy to Describe Drop Threshold Policies 🍓
Two major resources govern the per-hop behavior in each node. The bandwidth allocation resource governs the forwarding behavior of each traffic class. A scheduler priority and weights are controlled by the bandwidth allocation policies, as well as the (minimal) number of queues needed for traffic separation. The second resource, which bandwidth allocation policies don't control, is the queue length and drop behavior. For this purpose, queue length and threshold policies are used.
Rule hierarchy describes the context that thresholds act on. The policy rule's condition describes the traffic class, and the rule's actions describe the bandwidth allocation, the forwarding priority and the queue length. If the traffic class contains different drop precedence sub-classes that need different thresholds within the same queue, the sub-rules' actions describe those thresholds. ngl this is so clean ✨
Below is an example of using rule nesting for threshold control. Let's look at these rules:
If (protocol is FTP) THEN (guarantee 10% of available BW)
(queue length equals 40 packets)
(drop technique is random)
if (src-ip is from net 2.x.x.x) THEN min threshold = 30%
max threshold = 70%
if (src-ip is from net 3.x.x.x) THEN min threshold = 40%
max threshold = 90%
if (all other) THEN min threshold = 20%
max threshold = 60%The rule describes the bandwidth allocation, the queue length and the drop technique assigned to FTP flows. The sub-rules describe the drop threshold priorities within those FTP flows. FTP packets received from all networks apart from networks 2.x.x.x and 3.x.x.x are randomly dropped once the queue threshold for FTP flows reaches 20% of the queue length. Once the queue fills to 60%, all of these packets are dropped before queuing. The other two sub-rules set different thresholds for FTP packets coming from the two specified subnets. 🦋 The Assured Forwarding per-hop behavior (AF) is another good example of using hierarchy to describe the different drop preferences within a traffic class. That example is provided in a later section.
1.4.3. Restrictions of the Use of Hierarchy Within QPIM ✨
Okay so rule nesting in QPIM is doing two big jobs 💅
- Enhance clarity, readability and reusability. 🧠
- Provide hierarchical context for actions. 🌳
The second one is the good stuff! It's how you specify context for bandwidth allocation, and it's also how you give context for drop threshold policies 🫶
So when does a hierarchy level set the bandwidth allocation context, when does it set the drop threshold context, and when is it just there for clarity and reusability? 🤔 It all depends on the actions, bestie. Bandwidth control actions inside a sub-rule decide how the bandwidth given to the traffic class (from the rule's condition clause) gets split up among the sub-rules. Drop threshold actions control that traffic class's queue drop behavior for each of the sub-rules. 🎀
Bandwidth control actions come with an implicit pointer that basically says: the bandwidth allocation is relative to the bandwidth resources defined by the higher level rule. 🦋 Drop threshold actions have one too: the thresholds are taken from the queue resources defined by the higher level rule. 💜 Other actions don't have that implicit pointer at all, so for them, hierarchy is only about reusability and readability. 🌸
Now here's the tea ☕ Every rule that includes a bandwidth allocation action implies that a queue should be allocated to the traffic class defined by the rule's condition clause. So once a sub-rule has a bandwidth allocation action in its actions, a threshold action in that same sub-rule can't refer to the parent rule's queue thresholds. Instead, it must refer to the sub-rule's own queue. 🙈 (Iykyk, this is the kind of thing that makes or breaks an implementation 😭)
So for a clear and unambiguous definition, you should avoid refining thresholds and refining bandwidth allocations within sub-rules. ✨ If the same rule needs both refinements, put the threshold refinements and the bandwidth refinements into separate groups, and then aggregate those groups under the policy rule using the PolicySetComponent aggregation. 👑
1.5. Intended Audiences 🎀
QPIM has a bunch of audiences, and here's who it's for and what they'd do with it 🧚
- Developers of QoS policy management applications can use this model as an extensible framework for defining policies to control PEPs and PDPs in an interoperable manner. 💖
- Developers of Policy Decision Point (PDP) systems built to control resource allocation signaled by RSVP requests. 🌈
- Developers of Policy Decision Points (PDP) systems built to create QoS configuration for PEPs. 💅
- Builders of large organization data and knowledge bases who decide to combine QoS policy information with other networking policy information, assuming all modeling is based on [PCIM] and [PCIMe]. 🍓
- Authors of various standards may use constructs introduced in this document to enhance their work. Authors of data models wishing to map a storage specific technology to QPIM must use this document as well. 🫶
2. Class Hierarchies 🦋
2.1. Inheritance Hierarchy 🌸
QPIM's class and association inheritance hierarchies are rooted in [PCIM] and [PCIMe]. Figures 2 and 3 show these QPIM inheritance hierarchies, and they also note how they relate to [PCIM] and [PCIMe]classes. Heads up: lots of other classes used to build QPIM policies, like SimplePolicyCondition, are defined in [PCIM] and [PCIMe]. So these figures do not show all the classes and relationships you need to define QPIM policies 🙈 The designer should grab the right classes and relationships from [PCIM] and [PCIMe] and use them together with the ones defined below. 💜
[ManagedElement] (abstract, PCIM)
|
+--Policy (abstract, PCIM)
| |
| +---PolicyAction (abstract, PCIM)
| | |
| | +---SimplePolicyAction (PCIMe)
| | | |
| | | +---QoSPolicyRSVPSimpleAction (QPIM)
| | |
| | +---QoSPolicyDiscardAction (QPIM)
| | |
| | +---QoSPolicyAdmissionAction (abstract, QPIM)
| | | |
| | | +---QoSPolicyPoliceAction (QPIM)
| | | |
| | | +---QoSPolicyShapeAction (QPIM)
| | | |
| | | +---QoSPolicyRSVPAdmissionAction (QPIM)
| | |
| | +---QoSPolicyPHBAction (abstract, QPIM)
| | |
| | +---QoSPolicyBandwidthAction (QPIM)
| | |
| | +---QoSPolicyCongestionControlAction (QPIM)
| |
| +---QoSPolicyTrfcProf (abstract, QPIM)
| | |
| | +---QoSPolicyTokenBucketTrfcProf (QPIM)
| | |
| | +---QoSPolicyIntServTrfcProf (QPIM)
| |
| |
| +---PolicyVariable (abstract, PCIMe)
| | |
| | +---PolicyImplicitVariable (abstract, PCIMe)
| | |
| | +---QoSPolicyRSVPVariable (abstract, QPIM)
| | |
| | +---QoSPolicyRSVPSourceIPv4Variable (QPIM)
| | |
| | +---QoSPolicyRSVPDestinationIPv4Variable (QPIM)
| | |
| | +---QoSPolicyRSVPSourceIPv6Variable (QPIM)
| | |
(continued on the next page)
(continued from the previous page)
[ManagedElement] (abstract, PCIM, repeated for convenience)
|
+--Policy (abstract, PCIM, repeated for convenience)
| |
| +---PolicyVariable (abstract, PCIMe)
| | |
| | +---PolicyImplicitVariable (abstract, PCIMe)
| | |
| | +---QoSPolicyRSVPVariable (abstract, QPIM)
| | |
| | +---QoSPolicyRSVPDestinationIPv6Variable (QPIM)
| | |
| | +---QoSPolicyRSVPSourcePortVariable (QPIM)
| | |
| | +---QoSPolicyRSVPDestinationPortVariable (QPIM)
| | |
| | +---QoSPolicyRSVPIPProtocolVariable (QPIM)
| | |
| | +---QoSPolicyRSVPIPVersionVariable (QPIM)
| | |
| | +---QoSPolicyRSVPDCLASSVariable (QPIM)
| | |
| | +---QoSPolicyRSVPStyleVariable (QPIM)
| | |
| | +---QoSPolicyRSVPDIntServVariable (QPIM)
| | |
| | +---QoSPolicyRSVPMessageTypeVariable (QPIM)
| | |
| | +---QoSPolicyRSVPPreemptionPriorityVariable (QPIM)
| | |
| | +---QoSPolicyRSVPPreemptionDefPriorityVariable (QPIM)
| | |
| | +---QoSPolicyRSVPUserVariable (QPIM)
| | |
| | +---QoSPolicyRSVPApplicationVariable (QPIM)
| | |
| | +---QoSPolicyRSVPAuthMethodVariable (QPIM)
| |
| +---PolicyValue (abstract, PCIMe)
| | |
| | +---QoSPolicyDNValue (QPIM)
| | |
| | +---QoSPolicyAttributeValue (QPIM)Figure 2. The QPIM Class Inheritance Hierarchy 💖
2.2. Relationship Hierarchy 🌈
Figure 3 shows the QPIM relationship hierarchy. ✨
[unrooted] (abstract, PCIM)
|
+---Dependency (abstract)
| |
| +--- QoSPolicyTrfcProfInAdmissionAction (QPIM)
| |
| +--- QoSPolicyConformAction (QPIM)
| |
| +--- QoSPolicyExceedAction (QPIM)
| |
| +--- QoSPolicyViolateAction (QPIM)
| |
| +--- PolicyVariableInSimplePolicyAction
| | |
| | + QoSPolicyRSVPVariableInRSVPSimplePolicyActionFigure 3. The QPIM Association Class Inheritance Hierarchy 💜
3. QoS Actions 🔥
This section walks through the QoS actions that QPIM models. 💅 QoS actions are policy-enforced network behaviors specified for traffic picked out by QoS conditions. They're modeled using the classes PolicyAction (from [PCIM]), SimplePolicyAction (from [PCIMe]), and a bunch of QoS actions defined in this document that are derived from both of those classes. You'll see them below 🦋
Quick heads up: this document doesn't talk about PolicyRule, PolicyGroup, or the different types of PolicyCondition classes. That's because [PCIM] and [PCIMe] fully specify those already 🫶
3.1. Overview 🌸
QoS policy based systems let the network admin write a set of rules. These rules control both which flows get preferred forwarding treatment and which preferred forwarding behaviors they get. QPIM gives you an information model for writing that set of rules 🎀
QoS policy rules can control environments where RSVP signaling is used to request different forwarding treatment for different traffic types from the network. They also work in environments with no signaling, where preferred treatment is wanted for some (but not all) traffic types. 🌈 QoS policy rules can also control environments where strict QoS guarantees go to individual flows, and environments where QoS is given to flow aggregates. 💖
QoS actions let a PDP or a PEP decide which RSVP requests get admitted before network resources are allocated. ✨ They also control the RSVP signaling content itself, plus the differences between priorities of RSVP requests. 👑 On top of that, QoS actions control Differentiated Service edge enforcement, including policing, shaping and marking, as well as the per-hop behaviors used in the network core. 🧚 Last but not least, QoS actions can control how RSVP requests get mapped at the edge of a differentiated service cloud into per hop behaviors. 🍓
There are four groups of actions, all derived from action classes defined in [PCIM] and [PCIMe]. 🫶
- The first QoS action group has a single action, QoSPolicyRSVPSimpleAction. It's used for both RSVP signal control and install actions. 💅
- The second QoS action group decides whether a flow or class of flows should be admitted. It does this by specifying an appropriate traffic profile using the QoSPolicyTrfcProf class and its subclasses. This group also includes QoS admission control actions, which use the QoSPolicyAdmissionAction class and its subclasses. 🦋
- The third group controls bandwidth allocation and congestion control differentiations. Together, these specify the per-hop behavior forwarding treatment. This group includes the QoSPolicyPHBAction class and its subclasses. 🌸
- The fourth QoS action is an unconditional packet discard action, which uses the QoSPolicyDiscardAction class. It's used either by itself or as a building block of the QoSPolicyPoliceAction. 🙈
Some QoS actions aren't modeled directly. Instead, they're modeled with the SimplePolicyAction class plus the right associations. For example, the three marking actions (DSCP, IPP and CoS) are modeled by using the SimplePolicyAction class and associating it with variables and values of the appropriate type defined in [PCIMe]. 💜
3.2. RSVP Policy Actions
okay so a PDP (either remote or within a PEP) can make three types of decisions when it evaluates an RSVP request 💅
- Admit or reject the request
- Add or modify the request admission parameters
- Modify the RSVP signaling content
The COPS for RSVP [RFC2749] spec uses different Decision object types to model each of these decisions. QPIM follows the COPS for RSVP spec too, and it models each decision with a different action class 🎀
The QoSPolicyRSVPAdmissionAction controls the Decision Command and Decision Flags objects used within COPS for RSVP. This class, together with its QoSPolicyIntServTrfcProf class, decides whether to accept or reject an RSVP request by comparing the request's TSPEC or RSPEC parameters against the traffic profile set in QoSPolicyIntServTrfcProf ✨ For the full comparison method, see section 4. Just like COPS for RSVP, the admission decision can accept the request and send a warning to the requester, which is so iconic 🙈 The QoSPolicyRSVPAdmissionAction can also be used to limit the number of admitted reservations 💜
The class QoSPolicyRSVPSimpleAction, which is derived from the PolicySimpleAction class [PCIMe], can control the other two COPS RSVP decision types. Its qpRSVPActionType property sets the instance to be of type 'REPLACE', 'STATELESS', or both ('REPLACEANDSTATELESS'). An instance with a qpRSVPActionType value of 'REPLACE' is read as a COPS Replace Decision, which controls the contents of the RSVP message. An instance with a value of 'STATELESS' is read as a COPS Stateless Decision, which controls the admission parameters. If you need both actions, assign REPLACEANDSTATELESS to the qpRSVPActionType property, and you're set 🌸
This class is modeled to represent the COPS for RSVP Replace and Stateless decisions. That similarity means future use of these COPS decisions can be controlled directly by a QoSPolicySimpleAction 🦋 The only extension that might be required is defining a new RSVP variable.
3.2.1. Example: Controlling COPS Stateless Decision
The QoSPolicyRSVPSimpleAction lets you specify admission parameters 🧚 It also lets you specify the preemption priority [RFC3181] of an RSVP Reservation request. With that preemption priority value, the PEP can work out how important a Reservation is compared with reservations that are already admitted. If needed, it can preempt lower priority reservations to make room for the higher priority one, which is literally main character energy 👑 This class can also control how RSVP requests get mapped to a differentiated services domain, by setting the QoSPolicyRSVPDCLASSVariable to the value you want. That tells the PEP to mark traffic matching the Session and Sender specifications in an RSVP request with a given DSCP value 💅
3.2.2. Example: Controlling the COPS Replace Decision
A Policy system should be able to control the information carried in the RSVP messages 🫶 The QoSPolicyRSVPSimpleAction lets you control the content of RSVP signaling messages. An RSVP message can carry a preemption policy object [RFC3181] that specifies the priority of the reservation request compared with other requests. An RSVP message can also carry a policy object for authentication purposes. An RSVP message can carry a DCLASS [DCLASS] object that tells the receiver or sender which DSCP value should be set on the data traffic. A COPS for RSVP Replacement Data Decision controls the content of the RSVP message by specifying a set of RSVP objects that replace or remove the existing ones ✨
3.3. Provisioning Policy Actions
The differentiated Service Architecture [DIFFSERV] was designed to provide scalable QoS differentiation without requiring any signaling protocols between the hosts and the network 🌈 The QoS actions modeled in QPIM can control all of the building blocks of the Differentiated Service architecture, including per-hop behaviors, edge classification, and policing and shaping. You don't have to specify the datapath mechanisms used by PEP implementations, which is such a vibe 💖 This gives you an abstraction level that hides the unnecessary details, so the network administrator can write rules that express the network requirements in a more natural form 🍓 In this architecture, no signaling happens between the end host and the network before the sender starts sending information, so the QoS mechanisms should be set up in advance. This usually means PEPs need to be provisioned with the set of policy rules ahead of time 🎀
Policing and Shaping actions are modeled as subclasses of the QoS admission action. DSCP and CoS marking are modeled by using the SimplePolicyAction ([PCIMe]) class with the right variables and values. Bandwidth allocation and congestion control actions are modeled as subclasses of the QpQPolicyPHBAction, which is itself a subclass PolicyAction class ([PCIM]).
3.3.1. Admission Actions: Controlling Policers and Shapers
Admission Actions (QoSPolicyAdmissionAction and its subclasses) are used to police and/or shape traffic 🔥
Each Admission Action is bound to a traffic profile (QoSPolicyTrfcProf) through the QoSPolicyTrfcProfInAdmissionAction association. The traffic profile is used to meter traffic for policing or shaping purposes 💜
An Admission Action carries a scope property (qpAdmissionScope) that determines whether the action controls individual traffic flows or aggregate traffic classes. [DIFFSERV] explains the concepts of "flow" and "traffic class" using the terms 'microflow' and 'traffic stream' 🦋 Roughly speaking, a flow is a set of packets carrying an IP header with the same values for source IP, destination IP, protocol, and layer 4 source and destination ports. A traffic class is a set of flows. In QPIM, simple and compound conditions can identify flows and/or traffic classes by using Boolean terms over the values of IP header fields, including the value of the ToS byte ⭐
So the scope property works like this: if its value is 0 (per-flow), each (micro) flow that positively matches the rule's condition is metered and policed individually. If its value is 1 (per-class), all flows matched by the rule's condition are metered as a single aggregate and policed together 🌸
Here's an example of the scope property in action 🎀 With two provisioned policing actions, these policies can be enforced:
- Make sure that each HTTP flow will not exceed 64kb/s
- Make sure that the aggregate rate of all HTTP flows will not exceed 512Kb/s
Both policies are modeled using the same class QoSPolicyPoliceAction (derived from QoSPolicyAdmissionAction). The first policy has its scope property set to 'flow', and the second has its scope property set to 'class'. The two policies are modeled using a rule with two police actions that, in a pseudo-formal definition, looks like this:
If (HTTP) Action1=police, Traffic Profile1=64kb/s, Scope1=flow
Action2=police, Traffic Profile2=512kb/s, Scope2=classThe provisioned policing action QoSPolicyPoliceAction has three associations: QoSPolicyConformAction, QoSPolicyExceedAction, and QoSPolicyViolateAction 💅
To get the result described above, you can use one of two modeling techniques. The first is to put both actions in a single policy rule using two PolicyActionInPolicyRule [PCIM] associations. In that case, the ExecutionStrategy property of the PolicyRule class [PCIMe] SHOULD be set to "Do All" so that both individual flows and aggregate streams get policed ✨
The second is to aggregate Action1 and Action2 in a CompundPolicyAction instance using the PolicyActionInPolicyAction aggregations [PCIMe]. In this case, so that both individual flows and aggregate traffic classes get policed, the ExecutionStrategy property of the CompoundPolicyAction class [PCIMe] SHOULD be set to "Do All" 🫶
The policing action is associated with a three-level token bucket traffic profile that carries rate, burst, and excess-burst parameters. Traffic measured by a meter can be classified as conforming traffic when the metered rate is below the rate defined by the traffic profile. It's classified as excess traffic when the metered traffic is above the normal burst and below the excess burst size. It's classified as violating traffic when the rate is above the maximum excess burst 🌈
[DIFF-MIB] defines a two-level meter and provides a way to combine two-level meters into more complex meters. In this document, a three-level traffic profile is defined. That lets you build two-level meters, and it also makes three-level meters easier to define for creating AF [AF] provisioning actions 💖
A policing action that models three-level policing MUST associate three separate actions with a three-level traffic profile: a conforming action, an exceeding action, and a violating action 🚨 A policing action that models two-level policing uses a two-level traffic profile and associates only conforming and exceeding actions. A policing action with a three-level traffic profile that specifies an exceed action but no violate action implies that the action taken when traffic is above the maximum excess burst is identical to the action taken when traffic is above the normal burst. The policer determines whether the profile is being met, while the actions to be performed are determined by the QoSPolicyXXXAction associations 🍓
Shapers are used to delay some or all of the packets in a traffic stream, so the stream complies with a traffic profile. A shaper usually has a finite-sized buffer, and packets may be discarded if there isn't enough buffer space to hold the delayed packets 🥺 Shaping is controlled by the QoSPolicyShapeAction class. The only required association is a traffic profile that specifies the rate and burst parameters the outgoing flows should conform with 🦋
3.3.2. Controlling Markers
okay bestie, marking is where we tell packets what vibe they're giving 🎀 QPIM models three kinds of marking control actions: DSCP assignment, IP Precedence (IPP) assignment, and layer-2 Class of Service (CoS) assignment. ✨ Each one is modeled with the SimplePolicyAction class, hooked up to the right variables and values 💅
DSCP assignment is the one where we "mark" or "color" the DS field of a packet header with a particular DS Code Point (DSCP). That drops the marked packet into a particular DS behavior aggregate 🦋
In the basic form, "If <condition> then 'DCSP = ds1'", the action gives a DSCP value (ds1) to every packet where the condition comes out true 💖
When you pair it with a policing action, you can issue a different assignment action through each of the 'conform', 'exceed' and 'violate' associations. So you can pick a PHB out of a PHB group based on the state of a meter 📊 it's giving main character energy 👑
The meaning of a DSCP assignment is packed into one SimplePolicyAction instance, where a DSCP variable is paired with a DSCP value through the right associations 🫶
IPP assignment sets the IPP field of a packet header to a particular IPP value, from 0 through 7. Its meaning lives in pairing a ToS variable (PolicyIPTosVariable) with a bit string value () (defined in [PCIMe]) inside a single SimplePolicyAction instance, via the right associations. The bit string is used in its masked bit string format. The mask tells you which 3 bits of the IPP sub field inside the ToS byte are relevant, and the bit string tells you which IPP value to set 🔥
CoS assignments control how a per-hop behavior gets mapped to a layer-2 Class of Service. For example, if you want a set of DSCP values mapped into an 802.1p user priority value, you write a rule with a condition describing that set of DSCP values, plus a CoS assignment action that specifies the mapping to the given user priority value 🌈 The meaning of a CoS assignment is the pairing of a CoS variable and a CoS value (an integer in the range of 0 through 7) inside one SimplePolicyAction instance, via the right associations 💜
3.3.3. Controlling Edge Policies - Examples
ok this one is so cute 🧚 Assuming the AF1 behavior aggregate is enforced within a DS domain, policy rules on the network boundaries should mark packets with one of the AF1x DSCPs. The choice depends on whether the traffic conforms to a predetermined three-parameter traffic profile. QPIM models that AF1 policing action as shown in Figure 4.
+-----------------------+ +------------------------------+
| QoSPolicyPoliceAction |====| QoSPolicyTokenBucketTrfcProf |
| scope = class | | rate = x, bc = y, be = z |
+-----------------------+ +------------------------------+
* @ #
* @ #
* @ +--------------------+ +--------------------------+
* @ | SimplePolicyAction |---| PolicyIntegerValue -AF13 |
* @ +--------------------+ +--------------------------+
* @
* +--------------------+ +---------------------------+
* | SimplePolicyAction |---| PolicyIntegerValue - AF12 |
* +--------------------+ +---------------------------+
*
+--------------------+ +---------------------------+
| SimplePolicyAction |---| PolicyIntegerValue - AF11 |
+--------------------+ +---------------------------+Association and Aggregation Legend:
**** QoSPolicyConformAction
@@@@ QoSPolicyExceedAction
#### QoSPolicyViolateAction
==== QoSTrfcProfInAdmissionAction
---- PolicyValueInSimplePolicyAction ([PCIMe])
&&&& PolicyVariableInSimplePolicyAction ([PCIMe], not shown) Figure 4. AF Policing and Markingthe AF policing action is basically a combo 🍓 It's made of a police action, a token bucket traffic profile, and three instances of the SimplePolicyAction class. Each simple policy action instance models a different marking action. Each SimplePolicyAction uses the PolicyVariableInSimplePolicyAction aggregation to set the associated PolicyDSCPVariable to the appropriate integer value, and that's done through the PolicyValueInSimplePolicyAction aggregation. The three PolicyVariableInSimplePolicyAction aggregations that connect the SimplePolicyActions to the DSCP Variables aren't shown in this figure, just to keep it simple 🙈 AF11 is marked on detecting conforming traffic, AF12 is marked on detecting exceeding traffic, and AF13 is marked on detecting violating traffic.
The second example, shown in Figure 5, is the simplest policing action 💀 Traffic below a two-parameter traffic profile stays unmodified, and traffic that exceeds the profile gets discarded.
+-----------------------+ +------------------------------+
| QoSPolicyPoliceAction |====| QoSPolicyTokenBucketTrfcProf |
| scope = class | | rate = x, bc = y |
+-----------------------+ +------------------------------+
@
@
+-------------------------+
| QoSPolicyDiscardAction |
+-------------------------+Association and Aggregation Legend:
**** QoSPolicyConformAction (not used)
@@@@ QoSPolicyExceedAction
#### QoSPolicyViolateAction (not used)
==== QoSTrfcProfInAdmissionAction Figure 5. A Simple Policing Action3.4. Per-Hop Behavior Actions
PHB time 🦋 A Per-Hop Behavior (PHB) describes the externally observable forwarding behavior of a DS node applied to a particular DS behavior aggregate [DIFFSERV]. Here's the vibe: a PHB action specifies both the observable forwarding behavior (like loss, delay, and jitter) and the buffer and bandwidth resources that need to be allocated to each behavior aggregate in order to get that behavior. So a rule with a set of PHB actions can say that an EF packet must not be delayed more than 20 msec in each hop. That same rule can also say the EF packets need preemptive forwarding (for example, priority queuing), and set the maximum bandwidth for that class plus the maximum buffer resources 🎀 PHB actions can therefore represent the final PHB requirements and also give enough detail to map them into configuration parameters for queues, schedulers, droppers, and other mechanisms ✨
The QoSPolicyPHBAction abstract class has two subclasses 💅 The QoSPolicyBandwidthAction class controls bandwidth, delay and forwarding behavior, while the QoSPolicyCongestionControlAction class controls queue size, thresholds, and congestion algorithms. The qpMaxPacketSize property of the QoSPolicyPHBAction class specifies the packet size in bytes, and it's needed when translating the bandwidth and congestion control actions into real implementation configurations. For example, an implementation that measures queue length in bytes needs this property to map the qpQueueSize property into the desired queue length in bytes 🌸
3.4.1. Controlling Bandwidth and Delay
bandwidth and delay, let's gooo ⭐ QoSPolicyBandwidthAction lets you specify the minimal bandwidth that should be reserved for a class of traffic. The qpMinBandwidth property can be set either in Kb/sec or as a percentage of the total available bandwidth, and the qpBandwidthUnits property decides whether you're getting percentages or fixed values 📊
The qpForwardingPriority property is used whenever preemptive forwarding is required. A policy rule that defines the EF PHB should indicate a non-zero forwarding priority. The qpForwardingPriority property holds an integer value, so there can be multiple levels of preemptive forwarding, and higher values mean higher priority 🔥
The qpMaxBandwidth property specifies the maximum bandwidth that should be allocated to a class of traffic. It may be specified in PHB actions with a non-zero forwarding priority, which helps guard against starvation of other PHBs 🫶
The qpMaxDelay and qpMaxJitter properties specify limits on the per-hop delay and jitter, in milliseconds, for any given packet within a traffic class. Enforcing the maximum delay and jitter may require preemptive forwarding as well as minimum and maximum bandwidth controls. Enforcing low max delay and jitter values may also require fragmentation and interleave mechanisms over low speed links 🌈
The Boolean qpFairness property indicates whether flows should have a fair chance to be forwarded without drop or delay. One way to enforce a bandwidth action with qpFairness set to TRUE is to build a queue per flow for the class of traffic specified in the rule's filter. That way, interactive flows like terminal access won't get queued behind a bursty flow (like FTP), so they keep a reasonable response time 🦋
3.4.2. Congestion Control Actions
queue talk 💖 The QoSPolicyCongestionControlAction class controls queue length, thresholds, and congestion control algorithms.
A PEP should be able to keep qpQueueSize packets in its queues that match the rule's condition. To get a link-speed independent queue size, qpQueueSize can also be measured in milliseconds. That time interval is the time needed to transmit all the packets in the queue if the link speed is dedicated entirely to transmitting packets in that queue ⏱️ The qpQueueSizeUnit property decides whether the queue size is measured in number of packets or in milliseconds. The qpDropMethod property selects tail-drop, head-drop, or random-drop algorithms 🍓 You can also set the maximum and minimum threshold values with the qpDropMinThresholdValue and qpDropMaxThresholdValue properties, either in packets or as a percentage of the total available queue size, as specified by the qpDropThresholdUnits property 💜
3.4.3. Using Hierarchical Policies: Examples for PHB Actions ✨
Okay bestie, hierarchical policy definition is the MAIN CHARACTER tool in the QoS Policy information model 💅 Rule nesting from [PCIMe] lets you write hierarchical policies that control RSVP requests, hierarchical shaping, policing and marking actions, hierarchical schedulers, and the differences between PHB groups. Iconic 🦋
This example sets up the PHBs enforced inside a Differentiated Service domain 🌸 The network admin chose to enforce EF, AF11, AF13 and Best Effort. For simplicity, AF12 is not differentiated. The rules look like this:
If (EF) then do EF actions
If (AF1) then do AF1 actions
If (AF11) then do AF11 actions
If (AF12) then do AF12 actions
If (AF13) then do AF13 actions
If (default) then do Default actions.EF, AF1, AF11, AF12 and AF13 are conditions that filter traffic by DSCP values. The AF1 condition matches the entire AF1 PHB group, including the AF11, AF12 and AF13 DSCP values. The default rule is where the Best Effort rules live. Nesting the AF1x rules inside the AF1 rule means there are extra refinements for how AF1x traffic gets treated relative to the whole AF1 group, which is so clever ngl 🧚 All these rules sit in a PolicyGroup whose decision strategy property is set to 'FirstMatching'.
The class instances below spell out the actions for each PHB. Queue sizes aren't specified here, but you can totally add them to the example 💖
Best Effort is the simple one. No bandwidth is allocated to it. The first action says the Best Effort traffic class should have fairness:
QoSPolicyBandwidthAction BE-B:
qpFairness: TRUEThe second action says the congestion algorithm for the Best Effort class should be random, with thresholds given as a percentage of the default queue size:
QoSPolicyCongestionControlAction BE-C:
qpDropMethod: random
qpDropThresholdUnits %
qpDropMinThreshold: 10%
qpDropMaxThreshold: 70%EF needs preemptive forwarding 🔥 The maximum bandwidth is also set so the EF class doesn't starve the other classes. EF uses tail drop because the applications using EF are supposed to be UDP-based, so they wouldn't benefit from a random dropper. Not them being picky 💀
QoSPolicyBandwidthAction EF-B:
qpForwardingPriority: 1
qpBandwidthUnits: %
qpMaxBandwidth 50%
qpFairness: FALSE
QoSPolicyCongestionControlAction EF-C:
qpDropMethod: tail-drop
qpDropThresholdUnits packet
qpDropMaxThreshold: 3 packetsThe AF1 actions set the bandwidth allocations for the entire PHB group:
QoSPolicyBandwidthAction AF1-B:
qpBandwidthUnits: %
qpMinBandwidth: 30%The AF1i actions specify the differentiating refinement for the AF1x PHBs inside the AF1 group. The different threshold values are what give each AF1x PHB its different discard probability within that group 🌈
QoSPolicyCongestionControlAction AF11-C:
qpDropMethod: random
qpDropThresholdUnits packet
qpDropMinThreshold: 6 packets
qpDropMaxThreshold: 16 packets
QoSPolicyCongestionControlAction AF12-C:
qpDropMethod: random
qpDropThresholdUnits packet
qpDropMinThreshold: 4 packets
qpDropMaxThreshold: 13 packets
QoSPolicyCongestionControlAction AF13-C:
qpDropMethod: random
qpDropThresholdUnits packet
qpDropMinThreshold: 2 packets
qpDropMaxThreshold: 10 packets4. Traffic Profiles 🎀
Meters measure the temporal state of a flow, or a set of flows, against a traffic profile 👑 In this document, traffic profiles are modeled by the QoSPolicyTrfcProf class. The association QoSPolicyTrfcProf InAdmissionAction binds the traffic profile to the admission action that uses it. Two traffic profiles are derived from the abstract class QoSPolicyTrfcProf. The first is a Token Bucket provisioning traffic profile carrying rate and burst parameters. The second is an RSVP traffic profile, which lets you compare flows with RSVP TSPEC and FLOWSPEC parameters ✨
4.1. Provisioning Traffic Profiles
Provisioned Admission Actions, including shaping and policing, are specified using a two- or three-parameter token bucket traffic profile 🦋 The QoSPolicyTokenBucketTrfcProf class includes these properties:
- Rate measured in kbits/sec
- Normal burst measured in bytes
- Excess burst measured in bytes
Rate determines the long-term average transmission rate. Traffic under this rate is conforming, as long as the normal burst isn't exceeded at any time. Traffic that exceeds the normal burst but is still below the excess burst is exceeding the traffic profile. Traffic beyond the excess burst is said to be violating the traffic profile 💅
Excess burst size is measured in bytes, in addition to the burst size. A zero excess burst size means no excess burst is allowed 🙈
4.2. RSVP traffic profiles
RSVP admission policy can decide whether to accept or deny an RSVP request based on the traffic specification of the flow (TSPEC) or on the amount of QoS resources requested (FLOWSPEC) 🫶 The admission decision can be based on matching individual RSVP requests against a traffic profile, or on matching the aggregated sum of all currently admitted FLOWSPECs (TSPECs). Which one you get is set by the qpAdmissionScope property in an associated QoSPolicyRSVPAdmissionAction.
The QoSPolicyIntservTrfcProf class models both kinds of traffic profile and has these properties:
- Token Rate (r) measured in bits/sec
- Peak Rate (p) measured in bits/sec
- Bucket Size (b) measured in bytes
- Min Policed unit (m) measured in bytes
- Max packet size (M) measured in bytes
- Resv Rate (R) measured in bits/sec
- Slack term (s) measured in microseconds
The first five parameters are the traffic specification parameters used in the Integrated Service architecture ([INTSERV]). They define a sender TSPEC as well as a FLOWSPEC for the Controlled-Load service [CL]. For the full explanation of what they mean, check out [RSVP-IS] 🧚
Parameters 6 and 7 are the extra ones used to specify the Guaranteed Service FLOWSPEC [GS] 💜
A partial order is defined between TSPECs (and FLOWSPECs). TSPEC A is larger than TSPEC B if and only if rA>rB, pA>pB, bA>bB, mA<mB and MA>MB. A TSPEC (FLOWSPEC) measured against a traffic profile uses the same ordering rule. An RSVP message is accepted only if its TSPEC (FLOWSPEC) is either smaller than or equal to the traffic profile. Only parameters specified in the traffic profile are compared 🌸
The GS FLOWSPEC is compared against the rate R and the slack term s. The term R should not be larger than the traffic profile R parameter, while the FLOWSPEC slack term should not be smaller than the one specified in the slack term 👀
TSPECs and FLOWSPECs can be added together. The sum of two TSPECs is computed by summing the rate r, the peak rate p and the bucket size b, and by taking the minimum value of the minimum policed unit m and the maximum value of the maximum packet size M. GS FLOWSPECs are summed by adding the Resv rate and minimizing the slack term s. These rules compute the temporal state of admitted RSVP states that match the traffic class defined by the rule condition. That state gets compared with the traffic profile to reach an admission decision when the scope of the QoSPolicyRSVPAdmissionAction is set to 'class' 🔥
5. Pre-Defined QoS-Related Variables ✨
Okay so pre-defined variables are literally necessary so that policy servers and policy tools from different vendors can actually understand each other 🫶. This section is where we name the variables that keep popping up in QoS policy land 💅.
Notice that this section only adds to the variable classes defined in [PCIMe] and reuses the mechanism defined there 🧚. No need to reinvent the wheel, bestie.
The QoS policy information model has its own set of pre-defined variable classes for fundamental QoS terms that people use all the time to build conditions and actions, but that are missing from [PCIMe]. RSVP-related variables are a big example 🌸. Every variable class in this document extends the QoSPolicyRSVPVariable class (defined in this document), which itself extends the PolicyImplictVariable class, defined in [PCIMe]. The subclasses are what pin down the data type and semantics of each policy variable 👑.
This document defines the following RSVP variable classes. Check each class definition for the full details:
RSVP related Variables:
QoSPolicyRSVPSourceIPv4Variable- The source IPv4 address of the RSVP signaled flow, as defined in the RSVP PATH SENDER_TEMPLATE and RSVP RESV FILTER_SPEC [RSVP] objects.QoSPolicyRSVPDestinationIPv4Variable- The destination port of the RSVP signaled flow, as defined in the RSVP PATH and RESV SESSION [RSVP] objects (for IPv4 traffic).QoSPolicyRSVPSourceIPv6Variable- The source IPv6 address of the RSVP signaled flow, as defined in the RSVP PATH SENDER_TEMPLATE and RSVP RESV FILTER_SPEC [RSVP] objects.QoSPolicyRSVPDestinationIPv6Variable- The destination port of the RSVP signaled flow, as defined in the RSVP PATH and RESV SESSION [RSVP] objects (for IPv6 traffic).QoSPolicyRSVPSourcePortVariable- The source port of the RSVP signaled flow, as defined in the RSVP PATH SENDER_TEMPLATE and RSVP RESV FILTER_SPEC [RSVP] objects.QoSPolicyRSVPDestinationPortVariable- The destination port of the RSVP signaled flow, as defined in the RSVP PATH and RESV SESSION [RSVP] objects.QoSPolicyRSVPIPProtocolVariable- The IP Protocol of the RSVP signaled flow, as defined in the RSVP PATH and RESV SESSION [RSVP] objects.QoSPolicyRSVPIPVersionVariable- The version of the IP addresses carrying the RSVP signaled flow, as defined in the RSVP PATH and RESV SESSION [RSVP] objects.QoSPolicyRSVPDCLASSVariable- The DSCP value as defined in the RSVP DCLASS [DCLASS] object.QoSPolicyRSVPStyleVariable- The reservation style (FF, SE, WF) as defined in the RSVP RESV message [RSVP].QoSPolicyRSVPIntServVariable- The type of Integrated Service (CL, GS, NULL) requested in the RSVP Reservation message, as defined in the FLOWSPEC RSVP Object [RSVP].QoSPolicyRSVPMessageTypeVariable- The RSVP message type, either PATH, PATHTEAR, RESV, RESVTEAR, RESVERR, CONF or PATHERR [RSVP].QoSPolicyRSVPPreemptionPriorityVariable- The RSVP reservation priority as defined in [RFC3181].QoSPolicyRSVPPreemptionDefPriorityVariable- The RSVP preemption reservation defending priority as defined in [RFC3181].QoSPolicyRSVPUserVariable- The ID of the user that initiated the flow as defined in the User Locator string in the Identity Policy Object [RFC3182].QoSPolicyRSVPApplicationVariable- The ID of the application that generated the flow as defined in the application locator string in the Application policy object [RFC2872].QoSPolicyRSVPAuthMethodVariable- The RSVP Authentication type used in the Identity Policy Object [RFC3182].
Each class restricts the possible value types associated with a specific variable 🎀. For example, the QoSPolicyRSVPSourcePortVariable class is used to define the source port of the RSVP signaled flow, and the value associated with this variable is of type PolicyIntegerValue 🔥.
6. QoS Related Values 💜
Values are the building blocks for the policy conditions and policy actions, as described in [PCIM] and [PCIMe] 🧩. This section defines a set of auxiliary values that are used for QoS policies, as well as in other policy domains.
All value classes extend the PolicyValue class [PCIMe] ✨. The subclasses specify specific data and value types that are not defined in [PCIMe].
This document defines the following two subclasses of the PolicyValue class:
QoSPolicyDNValue- This class is used to represent a single value or a set of Distinguished Name [DNDEF] values, including wildcards. A Distinguished Name is a name that can be used as a key to retrieve an object from a directory service. This value can be used in comparison to reference values carried in RSVP policy objects, as specified in [RFC3182]. This class is defined in Section 8.31.QoSPolicyAttributeValue- A condition term uses the form "Variable matches Value", and an action term uses the form "set Variable to Value" ([PCIMe]). This class is used to represent a single property value or a set of property values for the "Value" term in either a condition or an action. This value can be used in conjunction with reference values carried in RSVP objects, as specified in [RFC3182]. This class is defined in Section 8.12.
The property name is used to specify which of the properties in the QoSPolicyAttributeValue class instance is being used in the condition or action term 🔍. The value of this property (or these properties) will then be retrieved. For a condition, a match (which depends on the property name) is used to see whether the condition is satisfied. For an action, the semantics are instead "set the variable to this value" 💅.
For example, suppose the "user" objects in the organization include several properties, among them:
- First Name
- Last Name
- Login Name
- Department
- Title
A simple condition could be constructed to identify flows by their RSVP user carried policy object 🙈. The simple condition Last Name = "Smith", which identifies a user named Bill, would be constructed in the following way:
A SimplePolicyCondition [PCIMe] would aggregate a
QoSPolicyRSVPUserVariable [QPIM] object, via the
PolicyVariableInSimplePolicyCondition [PCIMe] aggregation.The implicit value associated with this condition is created in the following way:
A QoSPolicyAttributeValue object would be aggregated to the simple
condition object via a PolicyValueInSimplePolicyCondition [PCIMe].
The QoSPolicyAttributeValue attribute qpAttributeName would be set
to "last name" and the qpAttributeValueList would be set to
"Smith".Another example is a condition about the user's organizational department 🌈. It can be built in the exact same way, except the QoSPolicyAttributeValue attribute qpAttributeName is changed to "Department", and qpAttributeValueList is set to the particular value that is to be matched (for example, "engineering" or "customer support"). The logical condition would then be evaluated to true if the user belongs to either the engineering department or the customer support one 🎀.
Notice that many multiple-attribute objects need the QoSPolicyAttributeValue class to specify exactly which of their attributes should be used in the condition match operation 👑.
7. Class Definitions: Association Hierarchy 🦋
The following sections define associations that are specified by QPIM.
7.1. The Association "QoSPolicyTrfcProfInAdmissionAction"
This association links a QoSPolicyTrfcProf object (defined in section 8.9), which models a specific traffic profile, to a QoSPolicyAdmissionAction object (defined in section 8.2). The class definition for this association is as follows:
NAME QoSPolicyTrfcProfInAdmissionAction
DESCRIPTION A class representing the association between a
QoS admission action and its traffic profile.
DERIVED FROM Dependency (See [PCIM])
ABSTRACT FALSE
PROPERTIES Antecedent[ref QoSPolicyAdmissionAction [0..n]]
Dependent[ref QoSPolicyTrfcProf [1..1]]7.1.1. The Reference "Antecedent"
This property is inherited from the Dependency association, defined in [PCIM]. Its type is overridden to become an object reference to a QoSPolicyAdmissionAction object. This represents the "independent" part of the association. The [0..n] cardinality indicates that any number of QoSPolicyAdmissionAction object(s) may use a given QoSPolicyTrfcProf 🌸.
7.1.2. The Reference "Dependent"
This property is inherited from the Dependency association, and is overridden to become an object reference to a QoSPolicyTrfcProf object. This represents a specific traffic profile that is used by any number of QoSPolicyAdmissionAction objects. The [1..1] cardinality means that exactly one object of the QoSPolicyTrfcProf can be used by a given QoSPolicyAddmissionAction 🧚.
7.2. The Association "PolicyConformAction"
This association links a policing action with an object defining an action to be applied to conforming traffic relative to the associated traffic profile. The class definition for this association is as follows:
NAME PolicyConformAction
DESCRIPTION A class representing the association between a
policing action and the action that should be
applied to traffic conforming to an associated
traffic profile.
DERIVED FROM Dependency (see [PCIM])
ABSTRACT FALSE
PROPERTIES Antecedent[ref QoSPolicyPoliceAction[0..n]]
Dependent[ref PolicyAction [1..1]]7.2.1. The Reference "Antecedent"
This property is inherited from the Dependency association. Its type is overridden to become an object reference to a QoSPolicyPoliceAction object. This represents the "independent" part of the association. The [0..n] cardinality indicates that any number of QoSPolicyPoliceAction objects may be given the same action to be executed as the conforming action 🫶.
7.2.2. The Reference "Dependent"
This property is inherited from the Dependency association, and is overridden to become an object reference to a PolicyAction object. This represents a specific policy action that is used by a given QoSPolicyPoliceAction. The [1..1] cardinality means that exactly one policy action can be used as the "conform" action for a QoSPolicyPoliceAction. To execute more than one conforming action, use the PolicyCompoundAction class to model the conforming action 💖.
7.3. The Association "QoSPolicyExceedAction" ✨
bestie, this one links a policing action to an object that says what happens to traffic going over its traffic profile 💅 The class definition is below:
NAME QoSPolicyExceedAction
DESCRIPTION A class representing the association between a
policing action and the action that should be
applied to traffic exceeding an associated traffic
profile.
DERIVED FROM Dependency (see [PCIM])
ABSTRACT FALSE
PROPERTIES Antecedent[ref QoSPolicePoliceAction[0..n]]
Dependent[ref PolicyAction [1..1]]7.3.1. The Reference "Antecedent" 🦋
This property comes from the Dependency association, but its type gets overridden to be an object reference to a QoSPolicyPoliceAction object. That's the "independent" side of the relationship 🎀 The [0..n] cardinality means any number of QoSPolicyPoliceAction objects can be given the same action to run as the exceeding action. Sharing is caring 🫶
7.3.2. The Reference "Dependent" 💜
Also inherited from Dependency, and overridden to be an object reference to a PolicyAction object. This is the specific policy action a given QoSPolicyPoliceAction uses. The [1..1] cardinality means exactly one policy action can be the "exceed" action for a QoSPolicyPoliceAction, no more, no less 💅 If you want to run more than one conforming action, you use the PolicyCompoundAction class to model the exceeding action 🌸
7.4. The Association "PolicyViolateAction" 🌈
This association links a policing action to an object defining the action for traffic violating its associated traffic profile. The class definition is below:
NAME PolicyViolateAction
DESCRIPTION A class representing the association between
a policing action and the action that should be
applied to traffic violating an associated traffic
profile.
DERIVED FROM Dependency (see [PCIM])
ABSTRACT FALSE
PROPERTIES Antecedent[ref QoSPolicePoliceAction[0..n]]
Dependent[ref PolicyAction [1..1]]7.4.1. The Reference "Antecedent" ✨
Inherited from Dependency, overridden to be an object reference to a QoSPolicyPoliceAction object. That's the "independent" part. The [0..n] cardinality means any number of QoSPolicyPoliceAction objects can share the same action as the violating action 🥰
7.4.2. The Reference "Dependent" 🍓
Inherited from Dependency, overridden to be an object reference to a PolicyAction object. This is the specific policy action a given QoSPolicyPoliceAction uses. The [1..1] cardinality means exactly one policy action can be the "violate" action for a QoSPolicyPoliceAction. Want more than one violating action? Use the PolicyCompoundAction class to model it, same as above 💖
7.5. The Aggregation "QoSPolicyRSVPVariableInRSVPSimplePolicyAction" 🧚
A simple RSVP policy action is represented as a pair {variable, value}. This aggregation links a QoSPolicyRSVPSimpleAction instance to a single QoSPolicyRSVPVariable. The aggregation PolicyValueInSimplePolicyAction links the QoSPolicyRSVPSimpleAction to a single PolicyValue 💜
The class definition is below:
NAME QoSPolicyRSVPVariableInRSVPSimplePolicyAction
DERIVED FROM PolicyVariableInSimplePolicyAction
ABSTRACT FALSE
PROPERTIES GroupComponent[ref QoSPolicyRSVPSimpleAction
[0..n]]
PartComponent[ref QoSPolicyRSVPVariable [1..1] ]7.5.1. The Reference "GroupComponent" 👑
The reference property "GroupComponent" is inherited from PolicyComponent, and overridden to be an object reference to a QoSPolicyRSVPSimpleAction that contains exactly one QoSPolicyRSVPVariable. For any single instance of the aggregation class QoSPolicyRSVPVariableInRSVPSimplePolicyAction, this property is single-valued 🙈 The [0..n] cardinality means there may be 0, 1, or more QoSPolicyRSVPSimpleAction objects containing any given RSVP variable object.
7.5.2. The Reference "PartComponent" 🦋
The reference property "PartComponent" is inherited from PolicyComponent, and overridden to be an object reference to a QoSPolicyRSVPVariable defined within the scope of a QoSPolicyRSVPSimpleAction. For any single instance of the association class QoSPolicyRSVPVariableInRSVPSimplePolicyAction, this property (like all reference properties) is single-valued. The [1..1] cardinality means a QoSPolicyRSVPVariableInRSVPSimplePolicyAction must have exactly one RSVP variable defined within its scope to be meaningful 💅
8. Class Definitions: Inheritance Hierarchy 🌸
The following sections define the object classes that are specified by QPIM.
8.1. The Class QoSPolicyDiscardAction 🗑️
This class is used to say that packets should be discarded, which is the same thing as saying their forwarding should be denied. The class definition is below:
NAME QoSPolicyDiscardAction
DESCRIPTION This action specifies that packets should be
discarded.
DERIVED FROM PolicyAction (defined in [PCIM])
ABSTRACT FALSEFALSE
PROPERTIES None8.2. The Class QoSPolicyAdmissionAction 🎀
This is the base class for admission decisions. It works by comparing a meter, which measures the temporal behavior of a flow or a set of flows, against a traffic profile 🔥 The qpAdmissionScope property controls whether that comparison happens per flow or per class (of flows). Only packets that conform to the traffic profile get admitted for further processing, and other packets are discarded. The class definition is below:
NAME QoSPolicyAdmissionAction
DESCRIPTION This action controls admission decisions based on
comparison of a meter to a traffic profile.
DERIVED FROM PolicyAction (defined in [PCIM])
ABSTRACT FALSEFALSE
PROPERTIES qpAdmissionScope8.2.1. The Property qpAdmissionScope 🧚
This attribute says whether the admission decision is made per flow or per the entire class of flows defined by the rule condition. If the scope is "flow", the actual or requested rate of each flow is compared against the traffic profile. If the scope is "class", the aggregate actual or requested rate of all flows matching the rule condition is measured against the traffic profile ✨ The property is defined as follows:
NAME qpAdmissionScope
DESCRIPTION This property specifies whether the admission decision
is done per flow or per the entire class of flows.
SYNTAX Integer
VALUE This is an enumerated integer. A value of 0 specifies
that admission is done on a per-flow basis, and a value
of 1 specifies that admission is done on a per-class
basis.8.3. The Class QoSPolicyPoliceAction 🚦
This class is for defining policing actions, the ones that restrict traffic by comparing it with a traffic profile. Using the three associations QoSPolicyConformAction, QoSPolicyExceedAction and QoSPolicyViolateAction, you can specify different actions depending on whether the traffic is conforming, exceeding, or violating a traffic profile 💖 The traffic profile is specified in a subclass of the QoSPolicyTrfcProf class. The class definition is below:
NAME QoSPolicyPoliceAction
DESCRIPTION This action controls the operation of policers. The
rate of flows is measured against a traffic profile.
The actions that need to be performed on conforming,
exceeding and violating traffic are indicated using
the conform, exceed and violate action associations.
DERIVED FROM QoSPolicyAdmissionAction (defined in this document)
ABSTRACT FALSEFALSE
PROPERTIES None8.4. The Class QoSPolicyShapeAction 🌊
This class is for defining shaping actions. Shapers delay some or all of the packets in a traffic stream so that the stream complies with a given traffic profile 🫶 The traffic profile is specified in a subclass of the QoSPolicyTrfcProf class. The class definition is below:
NAME QoSPolicyShapeAction
DESCRIPTION This action indicate that traffic should be shaped to be
conforming with a traffic profile.
DERIVED FROM QoSPolicyAdmissionAction (defined in this document)
ABSTRACT FALSEFALSE
PROPERTIES None8.5. The Class QoSPolicyRSVPAdmissionAction 🎀
This class decides whether to accept or reject a given RSVP request. It does this by comparing the RSVP request's TSPEC or RSPEC parameters against the associated traffic profile, and/or by enforcing the pre-set maximum sessions limit 👑 The traffic profile is specified in the QoSPolicyIntServTrfcProf class. This class inherits the qpAdmissionScope property from its superclass, which says whether admission is done on a per-flow or per-class basis. If the traffic profile is not larger than or equal to the requested reservation, or to the sum of the admitted reservation merged with the requested reservation, the result is a deny decision. If no traffic profile is specified, the assumption is that all traffic can be admitted 🌈
The class definition is below:
NAME QoSPolicyRSVPAdmissionAction
DESCRIPTION This action controls the admission of RSVP requests.
Depending on the scope, either a single RSVP request or
the total admitted RSVP requests matching the conditions
are compared against a traffic profile.
DERIVED FROM QoSPolicyAdmissionAction (defined in this document)
ABSTRACT FALSEFALSE
PROPERTIES qpRSVPWarnOnly, qpRSVPMaxSessions8.5.1. The Property qpRSVPWarnOnly 🎀
okay so this one kicks in when admitting an RSVP request would violate the policer (traffic profile) limits, or when the maximum number of sessions would get exceeded (or both!) 🫶
when this property is set to TRUE, the RSVP request gets admitted anyway, but an RSVP error message carrying a warning goes back to the originator (sender or receiver) ✨ when it's set to FALSE, the request gets denied and an error message gets sent back to the originator instead. so the whole point of the qpWarnOnly flag is: depending on TRUE or FALSE, you either admit it but warn the originator that it's in violation, or you deny it outright (and send back an error) 💅
specifically, a PATHERR (in response to a Path message) or a RESVERR (in response to a RESV message) gets sent. this follows the COPS for RSVP send error flag in the Decision Flags object 🌸 here's how the property is defined:
NAME qpRSVPWarnOnly
SYNTAX Boolean
Default FALSE
VALUE The value TRUE means that the request should be admitted
AND an RSVP warning message should be sent to the
originator. The value of FALSE means that the request
should be not admitted and an appropriate error message
should be sent back to the originator of the request.8.5.2. The Property qpRSVPMaxSessions 🦋
this attribute caps the total number of RSVP requests that get admitted for a specified class of traffic 💜 for it to actually mean anything, the qpAdmissionScope property has to be set to class 🔥 here's the definition:
NAME qpRSVPMaxSessions
SYNTAX Integer
VALUE Must be greater than 0.8.6. The Class QoSPolicyPHBAction 🌈
this one's a base class used to define the per-hop behavior that gets assigned to behavior aggregates. it defines one common property, qpMaxPacketSize, for its subclasses to use (QoSPolicyBandwidthAction and QoSPolicyCongestionControlAction) 🧚 the class definition goes like this:
NAME QoSPolicyPHBAction
DESCRIPTION This action controls the Per-Hop-Behavior provided to
behavior aggregates.
DERIVED FROM PolicyAction (defined in [PCIM])
ABSTRACT TRUE
PROPERTIES qpMaxPacketSize8.6.1. The Property qpMaxPacketSize 🍓
this property specifies the maximum packet size in bytes, for packets in the designated flow ✨ it's used when translating QPIM attributes into QoS mechanisms inside a PEP. for example, queue length might be measured in bytes, while the minimum number of packets that SHOULD be kept in a PEP is defined within QPIM in number of packets 🙈 here's the property:
NAME qpMaxPacketSize
SYNTAX Integer
Value Must be greater than 08.7. The Class QoSPolicyBandwidthAction 💖
this class controls the bandwidth, delay, and forwarding behavior of a PHB 🔥 its class definition is:
NAME QoSPolicyBandwidthAction
DESCRIPTION This action controls the bandwidth, delay, and
forwarding characteristics of the PHB.
DERIVED FROM QoSPolicyPBHAction (defined in this document)
ABSTRACT FALSE
PROPERTIES qpForwardingPriority, qpBandwidthUnits,
qpMinBandwdith, qpMaxBandwidth, qpMaxDelay,
qpMaxJitter, qpFairness8.7.1. The Property qpForwardingPriority 👑
this property sets the forwarding priority for this set of flows ✨ a non-zero value means preemptive forwarding is required, and higher values mean higher forwarding priority 💅 defined like so:
NAME qpForwardingPriority
SYNTAX Integer
VALUE Must be non-negative. The value 0 means that preemptive
forwarding is not required. A positive value indicates
the priority that is to be assigned for this (set of)
flow(s). Larger values represent higher priorities.8.7.2. The Property qpBandwidthUnits 🦋
this property defines the units that qpMinBandwidth and qpMaxBandwidth use 🌸 bandwidth can be defined either in bits/sec or as a percentage of the available bandwidth or scheduler resources. here's the deal:
NAME qpBandwidthUnits
SYNTAX Integer
VALUE Two values are possible. The value of 0 is used to
specify units of bits/sec, while the value of 1 is used
to specify units as a percentage of the available
bandwidth. If this property indicates that the bandwidth
units are percentages, then each of the bandwidth
properties expresses a whole-number percentage, and hence
its maximum value is 100.8.7.3. The Property qpMinBandwidth 💜
this property defines the minimum bandwidth that SHOULD be reserved for this class of traffic 🫶 you can specify both relative (a percentage of the bandwidth) and absolute (bits/second) values, depending on what qpBandwidthUnits says 🎀 defined as:
NAME qpMinBandwidth
SYNTAX Integer
VALUE The value must be greater than 0. If the property
qpMaxBandwidth is defined, then the value of
qpMinBandwidth must be less than or equal to the value of
qpMaxBandwidth.8.7.4. The Property qpMaxBandwidth 🌈
this property defines the maximum bandwidth that SHOULD be allocated to this class of traffic ✨ same deal as before: relative (percentage) or absolute (bits/second) values, based on qpBandwidthUnits 💅 here it is:
NAME qpMaxBandwidth
SYNTAX Integer
VALUE The value must be greater than 0. If the property
qpMaxBandwidth is defined, then the value of
qpMinBandwidth must be less than or equal to the value of
qpMaxBandwidth.8.7.5. The Property qpMaxDelay ⭐
this property defines the maximal per-hop delay that traffic in this class SHOULD experience while being forwarded through this hop ⏱️ the maximum delay is measured in microseconds 🧚 defined as:
NAME qpMaxDelay
SYNTAX Integer (microseconds)
VALUE The value must be greater than 0.8.7.6. The Property qpMaxJitter 🍓
this property defines the maximal per-hop delay variance that traffic in this class SHOULD experience while being forwarded through this hop 🦋 the maximum jitter is measured in microseconds 💖 here's the definition:
NAME qpMaxJitter
SYNTAX Integer (microseconds)
VALUE The value must be greater than 0.8.7.7. The Property qpFairness 🫶
this property says whether fair queuing is required for this class of traffic 🌸 defined as:
NAME qpFairness
SYNTAX Boolean
VALUE The value of FALSE means that fair queuing is not
required for this class of traffic, while the value of
TRUE means that fair queuing is required for this class
of traffic.8.8. The Class QoSPolicyCongestionControlAction 🔥
this class controls the characteristics of whichever congestion control algorithm is in use 👑 its class definition is:
NAME QoSPolicyCongestionControlAction
DESCRIPTION This action control congestion control characteristics
of the PHB.
DERIVED FROM QoSPolicyPBHAction (defined in this document)
ABSTRACT FALSE
PROPERTIES qpQueueSizeUnits, qpQueueSize, qpDropMethod,
qpDropThresholdUnits, qpDropMinThresholdValue,
qpDropMaxThresholdValue8.8.1. The property qpQueueSizeUnits 🌈
this property specifies the units that qpQueueSize is measured in ✨ the queue size is measured either in number of packets or in units of time 💅 that time interval is how long it'd take to transmit everything in the queue if the link speed were dedicated entirely to sending packets from this queue 🙈 the definition is:
NAME qpQueueSizeUnits
SYNTAX Integer
VALUE This property can have two values. If the value is set
to 0, then the unit of measurement is number of packets.
If the value is set to 1, then the unit of measurement is
milliseconds.8.8.2. The Property qpQueueSize 💖
this property specifies the maximum queue size in packets or in milliseconds, depending on qpQueueSizeUnits (0 means packets, and 1 means milliseconds) 🎀 defined as:
NAME qpQueueSize
SYNTAX Integer
VALUE This value must be greater than 0.8.8.3. The Property qpDropMethod 🧚
this property specifies the congestion control drop algorithm that SHOULD be used for this type of traffic 🍓 defined as:
NAME qpDropMethod
SYNTAX Integer
VALUES Three values are currently defined. The value 0
specifies a random drop algorithm, the value 1 specifies
a tail drop algorithm, and the value 2 specifies a head
drop algorithm.8.8.4. The Property qpDropThresholdUnits 💜
this property specifies the units that qpDropMinThresholdValue and qpDropMaxThresholdValue are measured in 🫶 thresholds can be measured in packets or as a percentage of the available queue sizes 🦋 here's the definition:
NAME qpDropThresholdUnits
SYNTAX Integer
VALUES Three values are defined. The value 0 defines the units
as number of packets, the value 1 defines the units as a
percentage of the queue size and the value 2 defines the
units in milliseconds. If this property indicates that
the threshold units are percentages, then each of the
threshold properties expresses a whole-number percentage,
and hence its maximum value is 100.8.8.5. The Property qpDropMinThresholdValue 👑
this property specifies the minimum amount of queuing and buffer resources that SHOULD be reserved for this class of flows 🔥 the threshold can be relative (a percentage) or absolute (number of packets or milliseconds), depending on qpDropThresholdUnits 💅 for example, if this property is 5 packets, then enough buffer and queuing resources SHOULD be reserved to hold 5 packets before the specified congestion control drop algorithm kicks in ✨ defined as:
NAME qpDropMinThresholdValue
SYNTAX Integer
VALUE This value must be greater than or equal to 0. If the
property qpDropMaxThresholdValue is defined, then the
value of the qpDropMinThresholdValue property must be
less than or equal to the value of the
qpDropMaxThresholdValue property.8.8.6. The Property qpDropMaxThresholdValue ✨
okay so this one is the ceiling for how much queue and buffer space a class of flows is allowed to hog 🧺 the threshold can be relative (a percentage) or absolute (a number of packets or milliseconds), and whichever one you pick is decided by qpDropThresholdUnits 💅 congestion control droppers should not keep more packets than this value says. ngl, some droppers calculate queue occupancy averages, so the real max queue resources should be larger than the number here 🫠
NAME qpDropMaxThresholdValue
SYNTAX Integer
VALUE This value must be greater than or equal to 0. If the
property qpDropMinThresholdValue is defined, then the
value of the qpDropMinThresholdValue property must be
less than or equal to the value of the
qpDropMaxThresholdValue property.8.9. Class QoSPolicyTrfcProf 🎀
this is an abstract base class for traffic profiles 🦋 a traffic profile holds the maximum rate parameters that get used when making admission decisions. the association QoSPolicyTrfcProfInAdmissionAction is what hooks the admission decision up to a profile, so it's basically the matchmaker 💘 here's the class definition:
NAME QoSPolicyTrfcProf
DERIVED FROM Policy (defined in [PCIM])
ABSTRACT TRUE
PROPERTIES None8.10. Class QoSPolicyTokenBucketTrfcProf 🪣
this one models a two- or three-level Token Bucket traffic profile 🫧 want more levels? you can cascade multiple instances, like hooking the output of one instance into the input of another. this profile carries the policer or shaper rate values that get enforced on a flow or a set of flows. here's the definition:
NAME QoSPolicyTokenBucketTrfcProf
DERIVED FROM QoSPolicyTrfcProf (defined in this document)
ABSTRACT FALSE
PROPERTIES qpTBRate, qpTBNormalBurst, qpTBExcessBurst8.10.1. The Property qpTBRate 🌸
this is a non-negative integer for the token rate, in kilobits per second 🌊 a rate of zero means every packet is out of profile 😭 the value must be greater than to 0 (yes, the spec really says "greater than to" 🙈):
NAME qpTBRate
SYNTAX Integer
VALUE This value must be greater than to 08.10.2. The Property qpTBNormalBurst 🍓
this integer is the normal size of a burst, measured in bytes 📦
NAME qpTBNormalBurst
SYNTAX Integer
VALUE This value must be greater than to 08.10.3. The Property qpTBExcessBurst 🧁
this integer is the excess burst size, also in bytes 🫶
NAME qpTBExcessBurst
SYNTAX Integer
VALUE This value must be greater than or equal to
qpTBNormalBurst8.11. Class QoSPolicyIntServTrfcProf 🌈
this class represents an IntServ traffic profile 💜 its values get compared against the Traffic specification (TSPEC) and the QoS Reservation (FLOWSPEC) requests that show up inside RSVP requests, so it's all about matching the reservation vibes ✨ here's the definition:
NAME QoSPolicyIntServTrfcProf
DERIVED FROM QoSPolicyTrfcProf (defined in this document)
ABSTRACT FALSE
PROPERTIES qpISTokenRate, qpISPeakRate, qpISBucketSize,
qpISResvRate, qpISResvSlack, qpISMinPolicedUnit,
qpISMaxPktSize8.11.1. The Property qpISTokenRate 🦋
a non-negative integer for the token rate parameter, in kilobits per second 🌊
NAME qpISTokenRate
SYNTAX Integer
VALUE This value must be greater than or equal to 08.11.2. The Property qpISPeakRate ⚡
a non-negative integer for the peak rate parameter, in kilobits per second 🚀
NAME qpISPeakRate
SYNTAX Integer
VALUE This value must be greater than or equal to 08.11.3. The Property qpISBucketSize 🪣
a non-negative integer for the token bucket size parameter, measured in bytes 📦
NAME qpISBucketSize
SYNTAX Integer
VALUE This value must be greater than or equal to 08.11.4. The Property qpISResvRate 🎟️
a non-negative integer for the reservation rate (R-Spec) in the RSVP guaranteed service reservation 💌 it's in kilobits per second 🌸
NAME qpISResvRate
SYNTAX Integer
VALUE This value must be greater than or equal to 08.11.5. The Property qpISResvSlack 🕰️
a non-negative integer for the RSVP slack term in the RSVP guaranteed service reservation 💅 this one is measured in microseconds, so it's tiny and precise 🔬
NAME qpISResvSlack
SYNTAX Integer
VALUE This value must be greater than or equal to 08.11.6. The Property qpISMinPolicedUnit 🍬
a non-negative integer for the minimum RSVP policed unit, measured in bytes 🫧
NAME qpISMinPolicedUnit
SYNTAX Integer
VALUE This value must be greater than or equal to 08.11.7. The Property qpISMaxPktSize 🎀
this is a positive integer for the maximum allowed packet size for RSVP messages, in bytes 💖 it's a positive integer, which means it counts the bytes in the largest payload packet of an RSVP signaled flow or class 🧚
NAME qpISMaxPktSize
SYNTAX Integer
VALUE This value must be a positive integer, denoting the
number of bytes in the largest payload packet of an RSVP
signaled flow or class.8.12. The Class QoSPolicyAttributeValue 🔮
this class is for indirection in variable and value references, either in a simple condition ("<x> match <y>") or a simple action ("<x> = <y>") 🪄 in both cases, <x> and <y> are called the variable and the value of the condition or action. the values of the properties qpAttributeName and qpAttributeValueList are what get substituted in for <x> and <y>, and they show up in the condition or action respectively 💫
the substitution goes like this: the value of qpAttributeName gets plugged in for <x>, and the value of qpAttributeValueList gets plugged in for <y> 🫶 once that's done, the condition can be evaluated and the action can be performed 🎉
here's an example, because examples are everything 📚 say we want a condition over a user name like "user == 'Smith'", using the QoSPolicyRSVPUserVariable class. the user info in the RSVP message gives you a DN, and that DN points to a user object full of attributes. if the attribute we care about is "last name", we'd use QoSPolicyAttributeValue with qpAttributeName = "Last Name" and qpAttributeValueList = {"Smith"} 💕
here's the class definition:
NAME QoSPolicyAttributeValue
DERIVED FROM PolicyValue (defined in [PCIMe])
ABSTRACT FALSE
PROPERTIES qpAttributeName, qpAttributeValueList8.12.1. The Property qpAttributeName 🏷️
this property carries the name of the attribute used to substitute <x> in a simple condition or simple condition (yes, the spec says that twice 🙈) of the forms "<x> match <y>" or "<x> = <y>" respectively 🌷
NAME qpAttributeName
SYNTAX String8.12.2. The Property qpAttributeValueList 📝
this property carries a list of values used to substitute <y> in a simple condition or simple action of the forms "<x> match <y>" or "<x> = <y>" respectively 🧁
NAME qpAttributeValueList
SYNTAX String8.13. The Class "QoSPolicyRSVPVariable" 🧩
this is an abstract class and the base class for every implicit variable that has to do with RSVP conditioning 🌙 here's the definition:
NAME QoSPolicyRSVPVariable
DESCRIPTION An abstract base class used to build other classes
that specify different attributes of an RSVP request
DERIVED FROM PolicyImplicitVariable (defined in [PCIMe])
ABSTRACT TRUE
PROPERTIES None8.14. The Class "QoSPolicyRSVPSourceIPv4Variable" 🌊
this is a concrete class holding the source IPv4 address of the RSVP signaled flow, as defined in the RSVP PATH SENDER_TEMPLATE and RSVP RESV FILTER_SPEC [RSVP] objects 🫧 definition time:
NAME QoSPolicyRSVPSourceIPv4Variable
DESCRIPTION The source IPv4 address of the RSVP signaled flow, as
defined in the RSVP PATH SENDER_TEMPLATE and RSVP RESV
FILTER_SPEC [RSVP] objects.
ALLOWED VALUE TYPES: PolicyIPv4AddrValue
DERIVED FROM QoSPolicyRSVPVariable (defined in this document)
ABSTRACT FALSE
PROPERTIES None8.15. The Class "QoSPolicyRSVPDestinationIPv4Variable" 🦋
this is a concrete class holding the destination IPv4 address of the RSVP signaled flow, as defined in the RSVP PATH SENDER_TEMPLATE and RSVP RESV FILTER_SPEC [RSVP] objects 💖 here's the definition:
NAME QoSPolicyRSVPDestinationIPv4Variable
DESCRIPTION The destination IPv4 address of the RSVP signaled
flow, as defined in the RSVP PATH and RESV SESSION
[RSVP] objects.
ALLOWED VALUE TYPES: PolicyIPv4AddrValue
DERIVED FROM QoSPolicyRSVPVariable (defined in this document)
ABSTRACT FALSE
PROPERTIES None8.16. The Class "QoSPolicyRSVPSourceIPv6Variable" 🌌
this is a concrete class holding the source IPv6 address of the RSVP signaled flow, as defined in the RSVP PATH SENDER_TEMPLATE and RSVP RESV FILTER_SPEC [RSVP] objects 🪐 here's the definition:
NAME QoSPolicyRSVPSourceIPv6Variable
DESCRIPTION The source IPv6 address of the RSVP signaled flow, as
defined in the RSVP PATH SENDER_TEMPLATE and RSVP RESV
FILTER_SPEC [RSVP] objects.
ALLOWED VALUE TYPES: PolicyIPv6AddrValue
DERIVED FROM QoSPolicyRSVPVariable (defined in this document)
ABSTRACT FALSE
PROPERTIES None8.17. The Class "QoSPolicyRSVPDestinationIPv6Variable" 🌸
this is a concrete class holding the destination IPv6 address of the RSVP signaled flow, as defined in the RSVP PATH SENDER_TEMPLATE and RSVP RESV FILTER_SPEC [RSVP] objects 🫶 here's the definition:
NAME QoSPolicyRSVPDestinationIPv6Variable
DESCRIPTION The destination IPv6 address of the RSVP signaled
flow, as defined in the RSVP PATH and RESV SESSION
[RSVP] objects.
ALLOWED VALUE TYPES: PolicyIPv6AddrValue
DERIVED FROM QoSPolicyRSVPVariable (defined in this document)
ABSTRACT FALSE
PROPERTIES None8.18. The Class "QoSPolicyRSVPSourcePortVariable" 🦋
okay so this class holds the source port of the RSVP signaled flow 🌸 It's defined in the RSVP PATH SENDER_TEMPLATE and RSVP RESV FILTER_SPEC [RSVP] objects, so if you're wondering where the number comes from, that's the spot. Here's the class definition:
NAME QoSPolicyRSVPSourcePortVariable
DESCRIPTION The source port of the RSVP signaled flow, as defined
in the RSVP PATH SENDER_TEMPLATE and RSVP RESV
FILTER_SPEC [RSVP] objects.
ALLOWED VALUE TYPES: PolicyIntegerValue (0..65535)
DERIVED FROM QoSPolicyRSVPVariable (defined in this document)
ABSTRACT FALSE
PROPERTIES None8.19. The Class "QoSPolicyRSVPDestinationPortVariable" 💖
this one is a concrete class, and it holds the destination port of the RSVP signaled flow 🎀 It's defined in the RSVP PATH SENDER_TEMPLATE and RSVP RESV FILTER_SPEC [RSVP] objects, same as its source port sibling. Slay the symmetry 💅
NAME QoSPolicyRSVPDestinationPortVariable
DESCRIPTION The destination port of the RSVP signaled flow, as
defined in the RSVP PATH and RESV SESSION [RSVP]
objects.
ALLOWED VALUE TYPES: PolicyIntegerValue (0..65535)
DERIVED FROM QoSPolicyRSVPVariable (defined in this document)
ABSTRACT FALSE
PROPERTIES None8.20. The Class "QoSPolicyRSVPIPProtocolVariable" 🧚
another concrete class, and this one carries the IP Protocol number of the RSVP signaled flow 🍓 It's defined in the RSVP PATH and RESV SESSION [RSVP] objects. Here's the definition:
NAME QoSPolicyRSVPIPProtocolVariable
DESCRIPTION The IP Protocol number of the RSVP signaled flow, as
defined in the RSVP PATH and RESV SESSION [RSVP]
objects.
ALLOWED VALUE TYPES: PolicyIntegerValue
DERIVED FROM QoSPolicyRSVPVariable (defined in this document)
ABSTRACT FALSE
PROPERTIES None8.21. The Class "QoSPolicyRSVPIPVersionVariable" 🌈
this is a concrete class that holds the IP Protocol version number of the RSVP signaled flow 🌸 It's defined in the RSVP PATH and RESV SESSION [RSVP] objects. The well-known version numbers are 4 and 6, and this variable lets you write a policy like this:
"If IP version = IPv4 then ...".Here's the class definition:
NAME QoSPolicyRSVPIPVersionVariable
DESCRIPTION The IP version number of the IP Addresses carried the
RSVP signaled flow, as defined in the RSVP PATH and
RESV SESSION [RSVP] objects.
ALLOWED VALUE TYPES: PolciIntegerValue
DERIVED FROM QoSPolicyRSVPVariable (defined in this document)
ABSTRACT FALSE
PROPERTIES None8.22. The Class "QoSPolicyRSVPDCLASSVariable" 🎀
concrete class alert 🚨 This one contains the DSCP value as defined in the RSVP DCLASS [DCLASS] object. Two value types are allowed here, so you've got options 💅
NAME QoSPolicyRSVPDCLASSVariable
DESCRIPTION The DSCP value as defined in the RSVP DCLASS [DCLASS]
object.
ALLOWED VALUE TYPES: PolicyIntegerValue,
PolicyBitStringValue
DERIVED FROM QoSPolicyRSVPVariable (defined in this document)
ABSTRACT FALSE
PROPERTIES None8.23. The Class "QoSPolicyRSVPStyleVariable" 🦋
this concrete class holds the reservation style, as defined in the RSVP STYLE object in the RESV message [RSVP]. The integer version comes with an enumeration of three styles, so it's very organised 🫶
NAME QoSPolicyRSVPStyleVariable
DESCRIPTION The reservation style as defined in the RSVP STYLE
object in the RESV message [RSVP].
ALLOWED VALUE TYPES: PolicyBitStringValue,
PolicyIntegerValue (Integer has
an enumeration of
{ Fixed-Filter=1,
Shared-Explicit=2,
Wildcard-Filter=3}
DERIVED FROM QoSPolicyRSVPVariable (defined in this document)
ABSTRACT FALSE
PROPERTIES None8.24. The Class "QoSPolicyIntServVariable" ✨
this concrete class holds the Integrated Service requested in the RSVP Reservation message, as defined in the FLOWSPEC RSVP Object [RSVP]. Heads up, the NAME line in the definition below says QoSPolicyRSVPIntServVariable, so the heading and the name don't match, and that's just how the document is written 🙈
NAME QoSPolicyRSVPIntServVariable
DESCRIPTION The integrated Service requested in the RSVP
Reservation message, as defined in the FLOWSPEC RSVP
Object [RSVP].
ALLOWED VALUE TYPES: PolicyIntegerValue (An enumerated
value of { CL=1 , GS=2, NULL=3}
DERIVED FROM QoSPolicyRSVPVariable (defined in this document)
ABSTRACT FALSE
PROPERTIES None8.25. The Class "QoSPolicyRSVPMessageTypeVariable" 💜
this concrete class carries the RSVP message type, as defined in the RSVP message common header [RSVP] object. There's an enumeration of seven message types here, which is giving very organised energy 💅
NAME QoSPolicyRSVPMessageTypeVariable
DESCRIPTION The RSVP message type, as defined in the RSVP message
common header [RSVP] object.
ALLOWED VALUE TYPES: Integer (An enumerated value of
{PATH=1 , PATHTEAR=2, RESV=3,
RESVTEAR=4, RESVERR=5, CONF=6,
PATHERR=7}
DERIVED FROM QoSPolicyRSVPVariable (defined in this document)
ABSTRACT FALSE
PROPERTIES None8.26. The Class "QoSPolicyRSVPPreemptionPriorityVariable" 🌸
concrete class, and it holds the RSVP reservation priority as defined in [RFC3181]. Quick note: the text says "object" even though the thing being pointed at is [RFC3181], so read it with that in mind 🙈
NAME QoSPolicyRSVPPreemptionPriorityVariable
DESCRIPTION The RSVP reservation priority as defined in [RFC3181].
ALLOWED VALUE TYPES: PolicyIntegerValue
DERIVED FROM QoSPolicyRSVPVariable (defined in this document)
ABSTRACT FALSE
PROPERTIES None8.27. The Class "QoSPolicyRSVPPreemptionDefPriorityVariable" 🧚
this concrete class holds the RSVP reservation defending priority, as defined in [RFC3181] object. It's the defending counterpart to the priority class we just did 🛡️✨
NAME QoSPolicyRSVPPreemptionDefPriorityVariable
DESCRIPTION The RSVP preemption reservation defending priority as
defined in [RFC3181].
ALLOWED VALUE TYPES: PolicyIntegerValue
DERIVED FROM QoSPolicyRSVPVariable (defined in this document)
ABSTRACT FALSE
PROPERTIES None8.28. The Class "QoSPolicyRSVPUserVariable" 🍓
this concrete class holds the ID of the user that initiated the flow, as defined in the User Locator string in the Identity Policy Object [RFC3182]. Three value types are allowed, so you can match the user however suits your policy 💅
NAME QoSPolicyRSVPUserVariable
DESCRIPTION The ID of the user that initiated the flow as defined
in the User Locator string in the Identity Policy
Object [RFC3182].
ALLOWED VALUE TYPES: QoSPolicyDNValue,
PolicyStringValue,
QoSPolicyAttributeValue
DERIVED FROM QoSPolicyRSVPVariable (defined in this document)
ABSTRACT FALSE
PROPERTIES None8.29. The Class "QoSPolicyRSVPApplicationVariable" 🌈
this concrete class holds the ID of the application that generated the flow, as defined in the application locator string in the Application policy object [RFC2872]. It has the same three allowed value types as the user variable, which is very on-brand 🫶
NAME QoSPolicyRSVPApplicationVariable
DESCRIPTION The ID of the application that generated the flow as
defined in the application locator string in the
Application policy object [RFC2872].
ALLOWED VALUE TYPES: QoSPolicyDNValue,
PolicyStringValue,
QoSPolicyAttributeValue
DERIVED FROM QoSPolicyRSVPVariable (defined in this document)
ABSTRACT FALSE
PROPERTIES None8.30. The Class "QoSPolicyRSVPAuthMethodVariable" 🔥
concrete class alert 🚨 This one holds the type of authentication used in the Identity Policy Object [RFC3182]. The enumeration lists six options, from NONE all the way up to PGP_CERT 🦋
NAME QoSPolicyRSVPAuthMethodVariable
DESCRIPTION The RSVP Authentication type used in the Identity
Policy Object [RFC3182].
ALLOWED VALUE TYPES: PolicyIntegerValue (An enumeration
of { NONE=0, PLAIN-TEXT=1,
DIGITAL-SIG = 2, KERBEROS_TKT=3,
X509_V3_CERT=4, PGP_CERT=5}
DERIVED FROM QoSPolicyRSVPVariable (defined in this document)
ABSTRACT FALSE
PROPERTIES None8.31. The Class QoSPolicyDNValue 🌸
this class is used to represent a single value or a set of Distinguished Name [DNDEF] values, and it includes wildcards 🎀 A Distinguished Name is a name you can use as a key to fetch an object from a directory service. This value can be compared against reference values carried in RSVP policy objects, as specified in [RFC3182]. Here's the class definition:
NAME QoSPolicyDNValue
DERIVED FROM PolicyValue
ABSTRACT FALSE
PROPERTIES qpDNList8.31.1. The Property qpDNList 💖
this attribute gives you an unordered list of strings, and each string is a Distinguished Name (DN) with wildcards in it. The format of a DN is defined in [DNDEF]. The asterisk character ("*") works as a wildcard, either for a single attribute value or for an RDN. The order of RDNs does matter, so keep that in mind 👑
Here's the example from the document. A qpDNList attribute carrying this value:
"CN=*, OU=Sales, O=Widget Inc., *, C=US"matches:
"CN=J. Smith, OU=Sales, O=Widget Inc, C=US"and also matches:
"CN=J. Smith, OU=Sales, O=Widget Inc, L=CA, C=US".The attribute is defined like this:
NAME qpDNList
SYNTAX List of Distinguished Names implemented as strings, each of
which serves as a reference to another object.8.32. The Class QoSPolicyRSVPSimpleAction 🧚
last one in this batch, and it's a big one ✨ This action controls the content of RSVP messages and the way RSVP requests are admitted. Depending on its qpRSVPActionType property, it translates directly into a COPS Replace Decision, a COPS Stateless Decision, or both, as defined in COPS for RSVP. Only variables that are subclasses of QoSPolicyRSVPVariable are allowed to be associated with this action. Here's the property definition:
NAME QoSPolicyRSVPSimpleAction
DESCRIPTION This action controls the content of RSVP messages and
the way RSVP requests are admitted.
DERIVED FROM SimplePolicyAction (defined in [PCIMe])
ABSTRACT FALSE
PROPERTIES qpRSVPActionType8.32.1. The Property qpRSVPActionType 💅
okay so this property is an enumerated integer that tells you what kind of RSVP action you're dealing with 🎀 The value 'REPLACE' means a COPS Replace Decision, 'STATELESS' means a COPS Stateless Decision, and REPLACEANDSTATELESS means you get both decision types at once 👑 For the full tea, go check [RFC2749] ✨
NAME qpRSVPActionType
DESCRIPTION This property specifies whether the action type is for
COPS Replace, Stateless, or both types of decisions.
SYNTAX Integer
VALUE This is an enumerated integer. A value of 0 specifies
a COPS Replace decision. A value of 1 specifies a COPS
Stateless Decision. A value of 2 specifies both COPS
Replace and COPS Stateless decisions.9. Intellectual Property Rights Statement 🔥
bestie, the IETF isn't taking a side on whether any IP rights floating around for this tech are valid, how far they reach, or whether you can even get a license for them 🙈 It also isn't claiming it searched for any of that stuff. If you want the IETF's rules on rights for standards-track and standards-related docs, they're in BCP-11 📚
Copies of any claimed rights that were offered for publication, plus any promises of licenses, or the outcome of anyone trying to get a general license or permission to use those proprietary rights, can be requested from the IETF Secretariat 🫶
And if you know about any copyrights, patents, patent applications, or other proprietary rights that might cover tech you'd need to practice this standard, the IETF really wants you to speak up 📣 Send that info to the IETF Executive Director 💜
10. Acknowledgements 🌸
The authors wanted to thank everyone in the Policy Framework working group for their input 🧚 A special shoutout goes to the combined PCIMe coauthor crew: Lee Rafalow, Andrea Westerinen, Ritu Chadha and Marcus Brunner 💖 They also appreciated the valuable contributions from Ed Ellesson, Joel Halpern and Mircea Pana ✨ Thank you all for the comments, critiques, ideas and general support, you literally carried 🙌
11. Security Considerations 💀
okay this part is serious, so listen up 👀 The Policy Core Information Model [PCIM] covers the general security considerations for the core policy model 🔒 The extensions defined in this document don't add any new security considerations of their own 🛡️ So the security story here is fully inherited from [PCIM] and nothing extra gets bolted on 💅
12. References 🦋
12.1. Normative References 💜
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[PCIM] Moore, B., Ellesson, E., Strassner, J. and A. Westerinen,
"Policy Core Information Model -- Version 1
Specification", RFC 3060, February 2001.
[PCIMe] Moore, B., Ed., "Policy Core Information Model
Extensions", RFC 3460, January 2003.12.2. Informative References 🌈
[TERMS] Westerinen, A., Schnizlein, J., Strassner, J., Scherling,
M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry,
J. and M. Waldbusser, "Terminology for Policy-based
Management", RFC 3198, November 2001.
[DIFFSERV] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.
and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, December 1998.
[INTSERV] Braden, R., Clark, D. and S. Shenker, "Integrated Services
in the Internet Architecture: an Overview", RFC 1633, June
1994.
[RSVP] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S. and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997.
[RFC2749] Herzog, S., Ed., Boyle, J., Cohen, R., Durham, D., Rajan,
R. and A. Sastry, "COPS usage for RSVP", RFC 2749, January
2000.
[RFC3181] Herzog, S., "Signaled Preemption Priority Policy Element",
RFC 3181, October 2001.
[DIFF-MIB] Baker, F., Chan, K. and A. Smith, "Management Information
Base for the Differentiated Services Architecture", RFC
3289, May 2002.
[AF] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski,
"Assured Forwarding PHB Group", RFC 2597, June 1999.
[CL] Wroclawski, J., "Specification of the Controlled-Load
Network Element Service", RFC 2211, September 1997.
[RSVP-IS] Wroclawski, J., "The Use of RSVP with IETF Integrated
Services", RFC 2210, September 1997.
[GS] Shenker, S., Partridge, C. and R. Guerin, "Specification
of the Guaranteed Quality of Service", RFC 2212, September
1997.
[DCLASS] Bernet, Y., "Format of the RSVP DCLASS Object", RFC 2996,
November 2000.
[RFC3182] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T.,
Herzog, S. and R. Hess, "Identity Representation for
RSVP", RFC 3182, October 2001.
[RFC2872] Bernet, Y. and R. Pabbati, "Application and Sub
Application Identity Policy Element for Use with RSVP",
RFC 2872, June 2000.
[DNDEF] Wahl, M., Kille, S. and T. Howes, "Lightweight Directory
Access Protocol (v3): UTF-8 String Representation of
Distinguished Names", RFC 2253, December 1997.13. Authors' Addresses 🧚
Here are the authors and how to reach them, bestie 💌
Yoram Ramberg
Cisco Systems
4 Maskit Street
Herzliya Pituach, Israel 46766
Phone: +972-9-970-0081
Fax: +972-9-970-0219
EMail: yramberg@cisco.com
Yoram Snir
Cisco Systems
300 East Tasman Drive
San Jose, CA 95134
Phone: +1 408-853-4053
Fax: +1 408 526-7864
EMail: ysnir@cisco.com
John Strassner
Intelliden Corporation
90 South Cascade Avenue
Colorado Springs, Colorado 80903
Phone: +1-719-785-0648
Fax: +1-719-785-0644
EMail: john.strassner@intelliden.com
Ron Cohen
Ntear LLC
Phone: +972-8-9402586
Fax: +972-9-9717798
EMail: ronc@lyciumnetworks.com
Bob Moore
IBM Corporation
P. O. Box 12195, BRQA/501/G206
3039 Cornwallis Rd.
Research Triangle Park, NC 27709-2195
Phone: +1 919-254-4436
Fax: +1 919-254-6243
EMail: remoore@us.ibm.com14. Full Copyright Statement ⭐
The Internet Society owns the copyright for 2003, and all rights are reserved 🌸
Anyone can copy this document and share it with others 📄 You can also make derivative works that comment on it, explain it, or help people implement it, and publish and distribute those however you like, in whole or in part, with no restrictions of any kind 💅 The one catch is that the copyright notice and this paragraph have to stay on every copy and every derivative work 🫶
The document itself can't be modified in any way, so no removing the copyright notice or the references to the Internet Society or other Internet organizations 🙅 The exceptions are when you need it to develop Internet standards, in which case the Internet Standards process copyright procedures have to be followed, or when you need to translate it into a language other than English 🌍
The permissions above are perpetual, and the Internet Society and its successors or assignees won't revoke them 💖
The document and the information in it are provided "AS IS", and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 💀
Acknowledgement 🎀
The RFC Editor function is funded by the Internet Society for now, so a big thank you to them 💜
📦 where this page comes from
- ietf: rfc3644 2003-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms