idnits 2.17.1 draft-ietf-policy-qos-info-model-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 5 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** There is 1 instance of lines with control characters in the document. ** The abstract seems to contain references ([KEYWORDS]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 722 has weird spacing: '...n is in the '...' == Line 1955 has weird spacing: '...rfcProf can b...' == Line 1990 has weird spacing: '... action can b...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 2003) is 7645 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'ManagedElement' is mentioned on line 1064, but not defined == Missing Reference: 'QPIM' is mentioned on line 1899, but not defined -- Obsolete informational reference (is this intentional?): RFC 2253 (ref. 'DNDEF') (Obsoleted by RFC 4510, RFC 4514) Summary: 5 errors (**), 0 flaws (~~), 6 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Policy Framework Working Group Y. Snir 2 INTERNET-DRAFT Y. Ramberg 3 Cisco Systems 4 Category: Standards Track J. Strassner 5 Intelliden 6 R. Cohen 7 Ntear LLC 8 B. Moore 9 IBM 10 May 2003 12 Policy QoS Information Model 13 15 Status of this Document 17 This document is an Internet-Draft and is in full conformance with all 18 provisions of Section 10 of RFC2026. 20 Internet-Drafts are working documents of the Internet Engineering Task 21 Force (IETF), its areas, and its working groups. Note that other groups 22 may also distribute working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference material 27 or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html 35 Copyright Notice 37 Copyright (C) The Internet Society (2003). All Rights Reserved. 39 Abstract 41 This document presents an object-oriented information model for 42 representing policies that administer, manage, and control access to 43 network QoS resources. This document is based on the IETF Policy Core 44 Information Model and its extensions. 45 This defines an information model for QoS enforcement for 46 differentiated and integrated services using policy. 47 It is important to note that this document defines an information 48 model, which by definition is independent of any particular data 49 storage mechanism and access protocol. 51 Definition of Key Word Usage 53 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 54 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 55 document are to be interpreted as described in RFC 2119 [KEYWORDS]. 57 Table of Contents 59 1. Introduction 5 60 1.1. The Process of QoS Policy Definition 5 61 1.2. Design Goals and Their Ramifications 8 62 1.2.1. Policy-Definition Oriented 8 63 1.2.1.1. Rule-based Modeling 9 64 1.2.1.2. Organize Information Hierarchically 9 65 1.2.1.3. Goal-Oriented Policy Definition 10 66 1.2.2. Policy Domain Model 10 67 1.2.2.1. Model QoS Policy in a Device- and Vendor-Independent Manner 11 68 1.2.2.2. Use Roles for Mapping Policy to Network Devices 11 69 1.2.2.3. Reusability 11 70 1.2.3. Enforceable Policy 12 71 1.2.4. QPIM Covers Both Signaled And Provisioned QoS 13 72 1.2.5. Interoperability for PDPs and Management Applications 14 73 1.3. Modeling Abstract QoS Policies 14 74 1.4. Rule Hierarchy 16 75 1.4.1. Use of Hierarchy Within Bandwidth Allocation Policies 17 76 1.4.2. Use of Rule Hierarchy to Describe Drop Threshold Policies 19 77 1.4.3. Restrictions of the Use of Hierarchy Within QPIM 20 78 1.5. Intended Audiences 21 80 2. Class Hierarchies 22 81 2.1. Inheritance Hierarchy 22 82 2.2. Relationship Hierarchy 24 84 3. QoS Actions 25 85 3.1. Overview 25 86 3.2. RSVP Policy Actions 26 87 3.2.1. Example: Controlling COPS Stateless Decision 27 88 3.2.2. Example: Controlling the COPS Replace Decision 27 89 3.3. Provisioning Policy Actions 27 90 3.3.1. Admission Actions: Controlling Policers and Shapers 28 91 3.3.2. Controlling Markers 30 92 3.3.3. Controlling Edge Policies - Examples 31 93 3.4. Per-Hop Behavior Actions 32 94 3.4.1. Controlling Bandwidth and Delay 33 95 3.4.2. Congestion Control Actions 33 96 3.4.3. Using Hierarchical Policies: Examples for PHB Actions 34 98 4. Traffic Profiles 36 99 4.1. Provisioning Traffic Profiles 36 100 4.2. RSVP Traffic Profiles 36 102 5. Pre-Defined QoS-Related Variables 38 104 6. QoS Related Values 40 105 Table of Contents (continued) 107 7. Class Definitions: Association Hierarchy 42 108 7.1. The Association "QoSPolicyTrfcProfInAdmissionAction" 42 109 7.1.1. The Reference "Antecedent" 42 110 7.1.2. The Reference "Dependent" 42 111 7.2. The Association "PolicyConformAction" 43 112 7.2.1. The Reference "Antecedent" 43 113 7.2.2. The Reference "Dependent" 43 114 7.3. The Association "QoSPolicyExceedAction" 43 115 7.3.1. The Reference "Antecedent" 44 116 7.3.2. The Reference "Dependent" 44 117 7.4. The Association "PolicyViolateAction" 44 118 7.4.1. The Reference "Antecedent" 44 119 7.4.2. The Reference "Dependent" 45 120 7.5 The Aggregation "QoSPolicyRSVPVariableInRSVPSimplePolicyAction" 45 121 7.5.1. The Reference "GroupComponent" 45 122 7.5.2. The Reference "PartComponent" 45 124 8. Class Definitions: Inheritance Hierarchy 46 125 8.1. The Class QoSPolicyDiscardAction 46 126 8.2. The Class QoSPolicyAdmissionAction 46 127 8.2.1. The Property qpAdmissionScope 46 128 8.3. The Class QoSPolicyPoliceAction 47 129 8.4. The Class QoSPolicyShapeAction 47 130 8.5. The Class QoSPolicyRSVPAdmissionAction 47 131 8.5.1. The Property qpRSVPWarnOnly 48 132 8.5.2. The Property qpRSVPMaxSessions 48 133 8.6. The Class QoSPolicyPHBAction 49 134 8.6.1. The Property qpMaxPacketSize 49 135 8.7. The Class QoSPolicyBandwidthAction 49 136 8.7.1. The Property qpForwardingPriority 50 137 8.7.2. The Property qpBandwidthUnits 50 138 8.7.3. The Property qpMinBandwidth 50 139 8.7.4. The Property qpMaxBandwidth 51 140 8.7.5. The Property qpMaxDelay 51 141 8.7.6. The Property qpMaxJitter 51 142 8.7.7. The Property qpFairness 51 143 8.8. The Class QoSPolicyCongestionControlAction 52 144 8.8.1. The Property qpQueueSizeUnits 52 145 8.8.2. The Property qpQueueSize 52 146 8.8.3. The Property qpDropMethod 53 147 8.8.4. The Property qpDropThresholdUnits 53 148 8.8.5. The Property qpDropMinThresholdValue 53 149 8.8.6. The Property qpDropMaxThresholdValue 54 150 8.9. The Class QoSPolicyTrfcProf 54 151 8.10. The Class QoSPolicyTokenBucketTrfcProf 54 152 8.10.1. The Property qpTBRate 55 153 8.10.2. The Property qpTBNormalBurst 55 154 8.10.3. The Property qpTBExcessBurst 55 155 Table of Contents (continued) 157 8.11. The Class QoSPolicyIntServTrfcProf 55 158 8.11.1. The Property qpISTokenRate 56 159 8.11.2. The Property qpISPeakRate 56 160 8.11.3. The Property qpISBucketSize 56 161 8.11.4. The Property qpISResvRate 56 162 8.11.5. The Property qpISResvSlack 56 163 8.11.6. The Property qpISMinPolicedUnit 57 164 8.11.7. The Property qpISMaxPktSize 57 165 8.12. The Class QoSPolicyAttributeValue 57 166 8.12.1. The Property qpAttributeName 58 167 8.12.2. The Property qpAttributeValueList 58 168 8.13. The Class QoSPolicyRSVPVariable 58 169 8.14. The Class QoSPolicyRSVPSourceIPv4Variable 58 170 8.15. The Class QoSPolicyRSVPDestinationIPv4Variable 59 171 8.16. The Class QoSPolicyRSVPSourceIPv6Variable 59 172 8.17. The Class QoSPolicyRSVPDestinationIPv6Variable 59 173 8.18. The Class QoSPolicyRSVPSourcePortVariable 60 174 8.19. The Class QoSPolicyRSVPDestinationPortVariable 60 175 8.20. The Class QoSPolicyRSVPIPProtocolVariable 61 176 8.21. The Class QoSPolicyRSVPIPVersionVariable 61 177 8.22. The Class QoSPolicyRSVPDCLASSVariable 61 178 8.23. The Class QoSPolicyRSVPStyleVariable 62 179 8.24. The Class QoSPolicyRSVPIntServVariable 62 180 8.25. The Class QoSPolicyRSVPMessageTypeVariable 63 181 8.26. The Class QoSPolicyRSVPPreemptionPriorityVariable 63 182 8.27. The Class QoSPolicyRSVPPreemptionDefPriorityVariable 63 183 8.28. The Class QoSPolicyRSVPUserVariable 64 184 8.29. The Class QoSPolicyRSVPApplicationVariable 64 185 8.30. The Class QoSPolicyRSVPAuthMethodVariable 65 186 8.31. The Class QosPolicyDNValue 65 187 8.31.1. The Property qpDNList 65 188 8.32. The Class QoSPolicyRSVPSimpleAction 66 189 8.32.1. The Property qpRSVPActionType 66 191 9. Acknowledgements 67 193 10. Security Considerations 67 195 11. Normative References 67 196 12. Informative References 68 197 13. Authors' Addresses 69 199 14. Full Copyright Statement 70 200 1. Introduction 202 The QoS Policy Information Model (QPIM) establishes a standard framework 203 and constructs for specifying and representing policies that administer, 204 manage, and control access to network QoS resources. Such policies will 205 be referred to as "QoS policies" in this document. The framework 206 consists of a set of classes and relationships that are organized in an 207 object-oriented information model. It is agnostic of any specific PDP or 208 PEP (see [TERMS] for definitions) implementation, and independent of any 209 particular QoS implementation mechanism. 211 QPIM is designed to represent QoS policy information for large-scale 212 policy domains (the term "policy domain" is defined in [TERMS]). A 213 primary goal of this information model is to assist human administrators 214 in their definition of policies to control QoS resources (as opposed to 215 individual network element configuration). The process of creating QPIM 216 data instances is fed by business rules, network topology and QoS 217 methodology (e.g. Differentiated Services). 219 This document is based on the IETF Policy Core Information Model and its 220 extensions as specified by [PCIM] and [PCIMe]. QPIM builds upon these 221 two documents to define an information model for QoS enforcement for 222 differentiated and integrated services ([DIFFSERV] and [INTSERV], 223 respectively) using policy. It is important to note that this document 224 defines an information model, which by definition is independent of any 225 particular data storage mechanism and access protocol. This enables 226 various data models (e.g., directory schemata, relational database 227 schemata, and SNMP MIBs) to be designed and implemented according to a 228 single uniform model. 230 1.1. The Process of QoS Policy Definition 232 This section describes the process of using QPIM for the definition QoS 233 policy for a policy domain. Figure 1 illustrates information flow and 234 not the actual procedure, which has several loops and feedback not 235 depicted. 237 ---------- ---------- ----------- 238 | Business | | Topology | | QoS | 239 | Policy | | | |Methodology| 240 ---------- ---------- ----------- 241 | | | 242 | | | 243 ------------------------------------ 244 | 245 V 246 --------------- 247 | QPIM/PCIM(e) | 248 | modeling | 249 --------------- 250 | 251 | -------------- 252 |<----------| Device info, | 253 | | capabilities | 254 | -------------- 255 V 256 (---------------) 257 ( device )---) 258 ( configuration ) )---) 259 (---------------) ) ) 260 (--------------) ) 261 (-------------) 263 Figure 1: The QoS definition information flow 265 The process of QoS policy definition is dependent on three types of 266 information: the topology of the network devices under management, the 267 particular type of QoS methodology used (e.g., DiffServ) and the 268 business rules and requirements for specifying service(s) [TERMS] 269 delivered by the network. Both topology and business rules are outside 270 the scope of QPIM. However, important facets of both must be known and 271 understood for correctly specifying the QoS policy. 273 Typically, the process of QoS policy definition relies on a methodology 274 based on one or more QoS methodologies. For example, the DiffServ 275 methodology may be employed in the QoS policy definition process. 277 The topology of the network consists of an inventory of the network 278 elements that make up the network and the set of paths that traffic may 279 take through the network. For example, a network administrator may 280 decide to use the DiffServ architectural model [DIFFSERV] and classify 281 network devices using the roles "boundary" and "core" (see [TERMS] for a 282 definition of role, and [PCIM] for an explanation of how they are used 283 in the policy framework). While this is not a complete topological view 284 of the network, many times it may suffice for the purpose of QoS policy 285 definition. 287 Business rules are informal sets of requirements for specifying the 288 behavior of various types of traffic that may traverse the network. For 289 example, the administrator may be instructed to implement policy such 290 that VoIP traffic manifests behavior that is similar to legacy voice 291 traffic over telephone networks. Note that this business rule 292 (indirectly) prescribes specific behavior for this traffic type (VoIP), 293 for example in terms of minimal delay, jitter and loss. Other traffic 294 types, such as WEB buying transactions, system backup traffic, video 295 streaming, etc., will express their traffic conditioning requirements in 296 different terms. Again, this information is required not by QPIM itself, 297 but by the overall policy management system that uses QPIM. QPIM is used 298 to help map the business rules into a form that defines the requirements 299 for conditioning different types of traffic in the network. 301 The topology, QoS methodology, and business rules are necessary 302 prerequisites for defining traffic conditioning. QPIM enables a set of 303 tools for specifying traffic conditioning policy in a standard manner. 304 Using a standard QoS policy information model such as QPIM is needed 305 also because different devices can have markedly different capabilities. 306 Even the same model of equipment can have different functionality if the 307 network operating system and software running in those devices is 308 different. Therefore, a means is required to specify functionality in a 309 standard way that is independent of the capabilities of different 310 vendors' devices. This is the role of QPIM. 312 In a typical scenario, the administrator would first determine the 313 role(s) that each interface of each network element plays in the overall 314 network topology. These roles define the functions supplied by a given 315 network element independent of vendor and device type. The [PCIM] and 316 [PCIMe] documents define the concept of a role. Roles can be used to 317 identify what parts of the network need which type of traffic 318 conditioning. For example, network interface cards that are categorized 319 as "core" interfaces can be assigned the role name "core-interface". 320 This enables the administrator to design policies to configure all 321 interfaces having the role "core-interface" independent of the actual 322 physical devices themselves. QPIM uses roles to help the administrator 323 map a given set of devices or interfaces to a given set of policy 324 constructs. 326 The policy constructs define the functionality required to perform the 327 desired traffic conditioning for particular traffic type(s). The 328 functions themselves depend on the particular type of networking 329 technologies chosen. For example, the DiffServ methodology encourages us 331 to aggregate similar types of traffic by assigning to each traffic class 332 a particular per-hop forwarding behavior on each node. RSVP enables 333 bandwidth to be reserved. These two methodologies can be used separately 334 or in conjunction, as defined by the appropriate business policy. QPIM 335 provides specific classes to enable DiffServ and RSVP conditioning to be 336 modeled. 338 The QPIM class definitions are used to create instances of various 339 policy constructs such as QoS actions and conditions that may be 340 hierarchically organized in rules and groups (PolicyGroup and PolicyRule 341 as defined in [PCIM] and [PCIMe]). Examples of policy actions are rate 342 limiting, jitter control and bandwidth allocation. Policy conditions are 343 constructs that can select traffic according to a complex Boolean 344 expression. 346 A hierarchical organization was chosen for two reasons. First, it best 347 reflects the way humans tend to think about complex policy. Second, it 348 enables policy to be easily mapped onto administrative organizations, as 349 the hierarchical organization of policy mirrors most administrative 350 organizations. It is important to note that the policy definition 351 process described here is done independent of any specific device 352 capabilities and configuration options. The policy definition is 353 completely independent from the details of the implementation and the 354 configuration interface of individual network elements, as well as of 355 the mechanisms that a network element can use to condition traffic. 357 1.2. Design Goals and Their Ramifications 359 This section explains the QPIM design goals and how these goals are 360 addressed in this document. This section also describes the 361 ramifications of the design goals and the design decisions made in 362 developing QPIM. 364 1.2.1 Policy-Definition Oriented 366 The primary design goal of QPIM is to model policies controlling QoS 367 behavior in a way that as closely as possible reflects the way humans 368 tend to think about policy. Therefore, QPIM is designed to address the 369 needs of policy definition and management, and not device/network 370 configuration. 372 There are several ramifications of this design goal. First, QPIM uses 373 rules to define policies, based on [PCIM] and [PCIMe]. Second, QPIM uses 374 hierarchical organizations of policies and policy information 375 extensively. Third, QPIM does not force the policy writer to specify all 376 implementation details; rather, it assumes that configuration agents 377 (PDPs) interpret the policies and match them to suit the needs of 378 device-specific configurations. 380 1.2.1.1. Rule-based Modeling 382 Policy is best described using rule-based modeling as explained and 383 described in [PCIM] and [PCIMe]. A QoS policy rule is structured as a 384 condition clause and an action clause. The semantics are simple: if the 385 condition clause evaluates to TRUE, then a set of QoS actions (specified 386 in the action clause) can be executed. For example, the rule: 388 "WEB traffic should receive at least 50% of the available 389 bandwidth resources or more, when more is available" 391 can be formalized as: 393 " then " 395 where the first angle bracketed clause is a traffic condition and the 396 second angle bracketed clause is a QoS action. 398 This approach differs from data path modeling that describes the 399 mechanisms that operates on the packet flows to achieve the desired 400 effect. 402 Note that the approach taken in QPIM specifically did NOT subclass the 403 PolicyRule class. Rather, it uses the SimplePolicyCondition, 404 CompoundPolicyCondition, SimplePolicyAction, and CompoundPolicyAction 405 classes defined in [PCIMe], as well as defining subclasses of the 406 following classes: Policy, PolicyAction, SimplePolicyAction, 407 PolicyImplicitVariable, and PolicyValue. Subclassing the PolicyRule 408 class would have made it more difficult to combine actions and 409 conditions defined within different functional domains [PCIMe] within 410 the same rules. 412 1.2.1.2. Organize Information Hierarchically 414 The organization of the information represented by QPIM is designed to 415 be hierarchical. To do this, QPIM utilizes the PolicySetComponent 416 aggregation [PCIMe] to provide an arbitrarily nested organization of 417 policy information. A policy group functions as a container of policy 418 rules and/or policy groups. A policy rule can also contain policy rules 419 and/or groups, enabling a rule/sub-rule relationship to be realized. 421 The hierarchical design decision is based on the realization that it is 422 natural for humans to organize policy rules in groups. Breaking down a 423 complex policy into a set of simple rules is a process that follows the 424 way people tend to think and analyze systems. The complexity of the 425 abstract, business-oriented policy is simplified and made into a 426 hierarchy of simple rules and grouping of simple rules. 428 The hierarchical information organization helps to simplify the 429 definition and readability of data instances based on QPIM. Hierarchies 430 can also serve to carry additional semantics for QoS actions in a given 431 context. An example, detailed in section 2.3, demonstrates how 432 hierarchical bandwidth allocation policies can be specified in an 433 intuitive form, without the need to specify complex scheduler 434 structures. 436 1.2.1.3. Goal-Oriented Policy Definition 438 QPIM facilitates goal-oriented QoS policy definition. This means that 439 the process of defining QoS policy is focused on the desired effect of 440 policies, as opposed to the means of implementing the policy on network 441 elements. 443 QPIM is intended to define a minimal specification of desired network 444 behavior. It is the role of device-specific configuration agents to 445 interpret policy expressed in a standard way and fill in the necessary 446 configuration details that are required for their particular 447 application. The benefit of using QPIM is that it provides a common 448 lingua franca that each of the device- and/or vendor-specific 449 configuration agents can use. This helps ensure a common interpretation 450 of the general policy as well as aid the administrator in specifying a 451 common policy to be implemented across different devices. This is 452 analogous to the fundamental object-oriented paradigm of separating 453 specification from implementation. Using QPIM, traffic conditioning can 454 be specified in a general manner that can help different implementations 455 satisfy a common goal. 457 For example, a valid policy may include only a single rule that 458 specifies that bandwidth should be reserved for a given set of traffic 459 flows. The rule does not need to include any of the various other 460 details that may be needed for implementing a scheduler that supports 461 this bandwidth allocation (e.g., the queue length required). It is 462 assumed that a PDP or the PEPs would fill in these details using (for 463 example) their default queue length settings. The policy writer need 464 only specify the main goal of the policy, making sure that the preferred 465 application receives enough bandwidth to operate adequately. 467 1.2.2. Policy Domain Model 469 An important design goal of QPIM is to provide a means for defining 470 policies that span numerous devices. This goal differentiates QPIM from 471 device-level information models, which are designed for modeling policy 472 that controls a single device, its mechanisms and capabilities. 474 This design goal has several ramifications. First, roles [PCIM] are used 475 to define policies across multiple devices. Second, the use of abstract 476 policies frees the policy definition process from having to deal with 477 individual device peculiarities, and leaves interpretation and 478 configuration to be modeled by PDPs or other configuration agents. 479 Third, QPIM allows extensive reuse of all policy building blocks in 480 multiple rules used within different devices. 482 1.2.2.1. Model QoS Policy in a Device- and Vendor-Independent Manner 484 QPIM models QoS policy in a way designed to be independent of any 485 particular device or vendor. This enables networks made up of different 486 devices that have different capabilities to be managed and controlled 487 using a single standard set of policies. Using such a single set of 488 policies is important because otherwise, the policy will itself reflect 489 the differences between different device implementations. 491 1.2.2.2. Use Roles for Mapping Policy to Network Devices 493 The use of roles enables a policy definition to be targeted to the 494 network function of a network element, rather than to the element's type 495 and capabilities. The use of roles for mapping policy to network 496 elements provides an efficient and simple method for compact and 497 abstract policy definition. A given abstract policy may be mapped to a 498 group of network elements without the need to specify configuration for 499 each of those elements based on the capabilities of any one individual 500 element. 502 The policy definition is designed to allow aggregating multiple devices 503 within the same role, if desired. For example, if two core network 504 interfaces operate at different rates, one does not have to define two 505 separate policy rules to express the very same abstract policy (e.g., 506 allocating 30% of the interface bandwidth to a given preferred set of 507 flows). The use of hierarchical context and relative QoS actions in QPIM 508 addresses this and other related problems. 510 1.2.2.3 Reusability 512 Reusable objects, as defined by [PCIM] and [PCIMe], are the means for 513 sharing policy building blocks, thus allowing central management of 514 global concepts. QPIM provides the ability to reuse all policy building 515 blocks: variables and values, conditions and actions, traffic profiles, 516 and policy groups and policy rules. This provides the required 517 flexibility to manage large sets of policy rules over large policy 518 domains. 520 For example, the following rule makes use of centrally defined objects 521 being reused (referenced): 523 If then 525 In this rule, the condition refers to an object named FinanceSubNet, 526 which is a value (or possibly a set of values) defined and maintained in 527 a reusable objects container. The QoS action makes use of a value named 528 MissionCritical, which is also a reusable object. The advantage of 529 specifying a policy in this way is its inherent flexibility. Given the 530 above policy, whenever business needs require a change in the subnet 531 definition for the organization, all that's required is to change the 532 reusable value FinanceSubNet centrally. All referencing rules are 533 immediately affected, without the need to modify them individually. 534 Without this capability, the repository that is used to store the rules 535 would have to be searched for all rules that refer to the finance 536 subnet, and then each matching rule's condition would have to be 537 individually updated. This is not only much less efficient, but also is 538 more prone to error. 540 For a complete description of reusable objects, refer to [PCIM] and 541 [PCIMe]. 543 1.2.3. Enforceable Policy 545 Policy defined by QPIM should be enforceable. This means that a PDP can 546 use QPIM's policy definition in order to make the necessary decisions 547 and enforce the required policy rules. For example, RSVP admission 548 decisions should be made based on the policy definitions specified by 549 QPIM. A PDP should be able to map QPIM policy definitions into PEP 550 configurations, using either standard or proprietary protocols. 552 QPIM is designed to be agnostic of any particular, vendor-dependent 553 technology. However, QPIM's constructs SHOULD always be interpreted so 554 that policy-compliant behavior can be enforced on the network under 555 management. Therefore, there are three fundamental requirements that 556 QPIM must satisfy: 558 1. Policy specified by QPIM must be able to be mapped to actual 559 network elements. 560 2. Policy specified by QPIM must be able to control QoS network 561 functions without making reference to a specific type of device 562 or vendor. 563 3. Policy specified by QPIM must be able to be translated into 564 network element configuration. 566 QPIM satisfies requirements #1 and #2 above by using the concept of 567 roles (specifically, the PolicyRoles property, defined in PCIM). By 568 matching roles assigned to policy groups and to network elements, a PDP 569 (or other enforcement agent) can determine what policy should be applied 570 to a given device or devices. 572 The use of roles in mapping policy to network elements supports model 573 scalability. QPIM policy can be mapped to large-scale policy domains by 574 assigning a single role to a group of network elements. This can be done 575 even when the policy domain contains heterogeneous devices. So, a small 576 set of policies can be deployed to large networks without having to re- 577 specify the policy for each device separately. This QPIM property is 578 important for QoS policy management applications that strive to ease the 579 task of policy definition for large policy domains. 581 Requirement #2 is also satisfied by making QPIM domain-oriented (see 582 [TERMS] for a definition of "domain"). In other words, the target of 583 the policy is a domain, as opposed to a specific device or interface. 585 Requirement #3 is satisfied by modeling QoS conditions and actions that 586 are commonly configured on various devices. However, QPIM is extensible 587 to allow modeling of actions that are not included in QPIM. 589 It is important to note that different PEPs will have different 590 capabilities and functions, which necessitate different individual 591 configurations even if the different PEPs are controlled by the same 592 policy. 594 1.2.4. QPIM Covers Both Signaled And Provisioned QoS 596 The two predominant standards-based QoS methodologies developed so far 597 are Differentiated Services (DiffServ) and Integrated Services 598 (IntServ). The DiffServ provides a way to enforce policies that apply to 599 a large number of devices in a scalable manner. QPIM provides actions 600 and conditions that control the classification, policing and shaping 601 done within the differentiated service domain boundaries, as well as 602 actions that control the per-hop behavior within the core of the 603 DiffServ network. QPIM does not mandate the use of DiffServ as a policy 604 methodology. 606 Integrated services, together with its signaling protocol (RSVP), 607 provides a way for end nodes (and edge nodes) to request QoS from the 608 network. QPIM provides actions that control the reservation of such 609 requests within the network. 611 As both methodologies continue to evolve, QPIM does not attempt to 612 provide full coverage of all possible scenarios. Instead, QPIM aims to 613 provide policy control modeling for all major scenarios. QPIM is 614 designed to be extensible to allow for incorporation of control over 615 newly developed QoS mechanisms. 617 1.2.5. Interoperability for PDPs and Management Applications 619 Another design goal of QPIM is to facilitate interoperability among 620 policy systems such as PDPs and policy management applications. QPIM 621 accomplishes this interoperability goal by standardizing the 622 representation of policy. Producers and consumers of QoS policy need 623 only rely on QPIM-based schemata (and resulting data models) to ensure 624 mutual understanding and agreement on the semantics of QoS policy. 626 For example, suppose that a QoS policy management application, built by 627 vendor A writes its policies based on the LDAP schema that maps 628 from QPIM to a directory implementation using LDAP. Now assume that a 629 separately built PDP from vendor B also relies on this same LDAP schema 630 derived from QPIM. Even though these are two vendors with two different 631 PDPs, each may read the schema of the other and "understand" it. This is 632 because both the management application and the PDP were architected to 633 comply with the QPIM specification. The same is true with two policy 634 management applications. For example, vendor B's policy application may 635 run a validation tool that computes whether there are conflicts within 636 rules specified by the other vendor's policy management application. 638 Interoperability of QPIM producers/consumers is by definition at a high 639 level, and does not guarantee that the same policy will result in the 640 same PEP configuration. First, different PEPs will have different 641 capabilities and functions, which necessitate different individual 642 configurations even if the different PEPs are controlled by the same 643 policy. Second, different PDPs will also have different capabilities and 644 functions, and may choose to translate the high-level QPIM policy 645 differently depending on the functionality of the PDP, as well as on the 646 capabilities of the PEPs that are being controlled by the PDP. However, 647 the different configurations should still result in the same network 648 behavior as that specified by the policy rules. 650 1.3. Modeling Abstract QoS Policies 652 This section provides a discussion of QoS policy abstraction and the way 653 QPIM addresses this issue. 655 As described above, the main goal of the QPIM is to create an 656 information model that can be used to help bridge part of the conceptual 657 gap between a human policy maker and a network element that is 658 configured to enforce the policy. Clearly this wide gap implies several 659 translation levels, from the abstract to the concrete. At the abstract 660 end are the business QoS policy rules. Once the business rules are 661 known, a network administrator must interpret them as network QoS policy 662 and represent this QoS policy by using QPIM constructs. QPIM facilitates 663 a formal representation of QoS rules, thus providing the first 664 concretization level: formally representing humanly expressed QoS 665 policy. 667 When a human business executive defines network policy, it is usually 668 done using informal business terms and language. For example, a human 669 may utter a policy statement that reads: 671 "human resources applications should have better QoS than simple 672 web applications" 674 This might be translated to a slightly more sophisticated form, such as: 676 "traffic generated by our human resources applications should have a 677 higher probability of communicating with its destinations 678 than traffic generated by people browsing the WEB using 679 non-mission-critical applications" 681 While this statement clearly defines QoS policy at the business level, 682 it isn't specific enough to be enforceable by network elements. 683 Translation to "network terms and language" is required. 685 On the other end of the scale, a network element functioning as a PEP, 686 such as a router, can be configured with specific commands that 687 determine the operational parameters of its inner working QoS 688 mechanisms. For example, the (imaginary) command "output-queue-depth = 689 100" may be an instruction to a network interface card of a router to 690 allow up to 100 packets to be stored before subsequent packets are 691 discarded (not forwarded). On a different device within the same 692 network, the same instruction may take another form, because a different 693 vendor built that device or it has a different set of functions, and 694 hence implementation, even though it is from the same vendor. In 695 addition, a particular PEP may not have the ability to create queues 696 that are longer than, say, 50 packets, which may result in a different 697 instruction implementing the same QoS policy. 699 The first example illustrates 'abstract policy', while the second 700 illustrates 'concrete configuration'. Furthermore, the first example 701 illustrates end-to-end policy, which covers the conditioning of 702 application traffic throughout the network. The second example 703 illustrates configuration for a particular PEP or a set thereof. While 704 an end-to-end policy statement can only be enforced by configuration of 705 PEPs in various parts of the network, the information model of policy 706 and that of the mechanisms that a PEP uses to implement that policy are 707 vastly different. 709 The translation process from abstract business policy to concrete PEP 710 configuration is roughly expressed as follows: 712 1. Informal business QoS policy is expressed by a human policy maker 713 (e.g., "All executives' WEB requests should be prioritized ahead of 714 other employees' WEB requests") 715 2. A network administrator analyzes the policy domain's topology and 716 determines the roles of particular device interfaces. A role may 717 be assigned to a large group of elements, which will result in 718 mapping a particular policy to a large group of device interfaces. 719 3. The network administrator models the informal policy using QPIM 720 constructs, thus creating a formal representation of the abstract 721 policy. For example, "If a packet's protocol is HTTP and its 722 destination is in the 'EXECUTIVES' user group, then assign IPP 7 723 to the packet header". 724 4. The network administrator assigns roles to the policy groups 725 created in the previous step matching the network elements' roles 726 assigned in step #2 above. 727 5. A PDP translates the abstract policy constructs created in step #3 728 into device-specific configuration commands for all devices 729 effected by the new policy (i.e., devices that have interfaces that 730 are assigned a role matching the new policy constructs' roles). In 731 this process, the PDP consults the particular devices' capabilities 732 to determine the appropriate configuration commands implementing 733 the policy. 734 6. For each PEP in the network, the PDP (or an agent of the PDP) 735 issues the appropriate device-specific instructions necessary to 736 enforce the policy. 738 QPIM, PCIM and PCIMe are used in step #3 above. 740 1.4. Rule Hierarchy 742 Policy is described by a set of policy rules that may be grouped into 743 subsets [PCIMe]. Policy rules and policy groups can be nested within 744 other policy rules, providing a hierarchical policy definition. Nested 745 rules are also called sub-rules, and we use both terms in this document 746 interchangeably. The aggregation PolicySetComponent (defined in [PCIMe] 747 is used to represent the nesting of a policy rule or group in another 748 policy rule. 750 The hierarchical policy rule definition enhances policy readability and 751 reusability. Within the QoS policy information model, hierarchy is used 752 to model context or scope for the sub-rule actions. Within QPIM, 753 bandwidth allocation policy actions and drop threshold actions use this 754 hierarchal context. First we provide a detailed example of the use of 755 hierarchy in bandwidth allocation policies. The differences between flat 756 and hierarchical policy representation are discussed. The use of 757 hierarchy in drop threshold policies is described in a following 758 subsection. Last but not least, the restrictions on the use of rule 759 hierarchies within QPIM are described. 761 1.4.1 Use of Hierarchy Within Bandwidth Allocation Policies 763 Consider the following example where the informal policy reads: 765 On any interface on which these rules apply, guarantee at least 30% 766 of the interface bandwidth to UDP flows, and at least 40% of the 767 interface bandwidth to TCP flows. 769 The QoS Policy information model follows the Policy Core information 770 model by using roles as a way to specify the set of interfaces on which 771 this policy applies. The policy does not assume that all interfaces are 772 run at the same speed, or have any other property in common apart from 773 being able to forward packets. Bandwidth is allocated between UDP and 774 TCP flows using percentages of the available interface bandwidth. Assume 775 that we have an available interface bandwidth of 1 Mbits/sec. Then this 776 rule will guarantee 300Kbits/sec to UDP flows. However, if the interface 777 bandwidth was instead only 64kbits/sec, then this rule would 778 correspondingly guarantee 19.2kb/sec. 780 This policy is modeled within QPIM using two policy rules of the form: 782 If (IP protocol is UDP) THEN (guarantee 30% of available BW) (1) 783 If (IP protocol is TCP) THEN (guarantee 40% of available BW) (2) 785 Assume that these two rules are grouped within a PolicySet [PCIMe] 786 carrying the appropriate role combination. A possible implementation of 787 these rules within a PEP would be to use a Weighted-Round-Robin 788 scheduler with 3 queues. The first queue would be used for UDP traffic, 789 the second queue for TCP traffic and the third queue for the rest of the 790 traffic. The weights of the Weighted-Round-Robin scheduler would be 30% 791 for the first queue, 40% for the second queue and 30% for the last 792 queue. 794 The actions specifying the bandwidth guarantee implicitly assume that 795 the bandwidth resource being guaranteed is the bandwidth available at 796 the interface level. A PolicyRoleCollection is a class defined in 797 [PCIMe] whose purpose is to identify the set of resources (in this 798 example, interfaces) that are assigned to a particular role. Thus, the 799 type of managed elements aggregated within the PolicyRoleCollection 800 defines the bandwidth resource being controlled. In our example, 801 interfaces are aggregated within the PolicyRoleCollection. Therefore, 802 the rules specify bandwidth allocation to all interfaces that match a 803 given role. Other behavior could be similarly defined by changing what 804 was aggregated within the PolicyRoleCollection. 806 Normally, a full specification of the rules would require indicating the 807 direction of the traffic for which bandwidth allocation is being made. 808 Using the direction variable defined in [PCIMe], the rules can be 809 specified in the following form: 811 If (direction is out) 812 If (IP protocol is UDP) THEN (guarantee 30% of available BW) 813 If (IP protocol is TCP) THEN (guarantee 40% of available BW) 815 where indentation is used to indicate rule nesting. To save space, we 816 omit the direction condition from further discussion. 818 Rule nesting provides the ability to further refine the scope of 819 bandwidth allocation within a given traffic class forwarded via these 820 interfaces. The example below adds two nested rules to refine bandwidth 821 allocation for UDP and TCP applications. 823 If (IP protocol is UDP) THEN (guarantee 30% of available BW) (1) 824 If (protocol is TFTP) THEN (guarantee 10% of available BW) (1a) 825 If (protocol is NFS) THEN (guarantee 40% of available BW) (1b) 826 If (IP protocol is TCP) THEN (guarantee 40% of available BW) (2) 827 If (protocol is HTTP) THEN guarantee 20% of available BW) (2a) 828 If (protocol is FTP) THEN (guarantee 30% of available BW) (2b) 830 Subrules 1a and 1b specify bandwidth allocation for UDP applications. 831 The total bandwidth resource being partitioned among UDP applications is 832 the bandwidth available for the UDP traffic class (i.e., 30%), not the 833 total bandwidth available at the interface level. Furthermore, TFTP and 834 NFS are guaranteed to get at least 10% and 40% of the total available 835 bandwidth for UDP, while other UDP applications aren't guaranteed to 836 receive anything. Thus, TFTP and NFS are guaranteed to get at least 3% 837 and 12% of the total bandwidth. Similar logic applies to the TCP 838 applications. 840 The point of this section will be to show that a hierarchical policy 841 representation enables a finer level of granularity for bandwidth 842 allocation to be specified than is otherwise available using a non- 843 hierarchical policy representation. To see this, let's compare this set 844 of rules with a non-hierarchical (flat) rule representation. In the non- 845 hierarchical representation, the guaranteed bandwidth for TFTP flows is 846 calculated by taking 10% of the bandwidth guaranteed to UDP flows, 847 resulting in 3% of the total interface bandwidth guarantee. 849 If (UDP AND TFTP) THEN (guarantee 3% of available BW) (1a) 850 If (UDP AND NFS) THEN (guarantee 12% of available BW) (1b) 851 If (other UDP APPs) THEN (guarantee 15% of available BW) (1c) 852 If (TCP AND HTTP) THEN guarantee 8% of available BW) (2a) 853 If (TCP AND FTP) THEN (guarantee 12% of available BW) (2b) 854 If (other TCP APPs) THEN (guarantee 20% of available BW) (2c) 856 Are these two representations identical? No, bandwidth allocation is not 857 the same. For example, within the hierarchical representation, UDP 858 applications are guaranteed 30% of the bandwidth. Suppose a single UDP 859 flow of an application different from NFS or TFTP is running. This 860 application would be guaranteed 30% of the interface bandwidth in the 861 hierarchical representation but only 15% of the interface bandwidth in 862 the flat representation. 864 A two stage scheduler is best modeled by a hierarchical representation 865 whereas a flat representation may be realized by a non-hierarchical 866 scheduler. 868 A schematic hierarchical Weighted-Round-Robin scheduler implementation 869 that supports the hierarchical rule representation is described below. 871 --UDP AND TFTP queue--10% 872 --UDP AND NFS queue--40%-Scheduler-30%--+ 873 --Other UDP queue--50% A1 | 874 | 875 --TCP AND HTTP queue--20% | 876 --TCP AND FTP queue--30%-Scheduler-40%--Scheduler--Interface 877 --Other TCP queue--50% A2 | B 878 | 879 ------------Non UDP/TCP traffic-----30%--+ 881 Scheduler A1 extracts packets from the 3 UDP queues according to the 882 weight specified by the UDP sub-rule policy. Scheduler A2 extracts 883 packets from the 3 TCP queues specified by the TCP sub-rule policy. The 884 second stage scheduler B schedules between UDP, TCP and all other 885 traffic according to the policy specified in the top most rule level. 887 Another difference between the flat and hierarchical rule representation 888 is the actual division of bandwidth above the minimal bandwidth 889 guarantee. Suppose two high rate streams are being forwarded via this 890 interface: an HTTP stream and an NFS stream. Suppose that the rate of 891 each flow is far beyond the capacity of the interface. In the flat 892 scheduler implementation, the ratio between the weights is 8:12 (i.e., 893 HTTP:NFS), and therefore HTTP stream would consume 40% of the bandwidth 894 while NFS would consume 60% of the bandwidth. In the hierarchical 895 scheduler implementation the only scheduler that has two queues filled 896 is scheduler B, therefore the ratio between the HTTP (TCP) stream and 897 the NFS (UDP) stream would be 30:40, and therefore the HTTP stream would 898 consume approximately 42% of the interface bandwidth while NFS would 899 consume 58% of the interface bandwidth. In both cases both HTTP and NFS 900 streams got more than the minimal guaranteed bandwidth, but the actual 901 rates forwarded via the interface differ. 903 The conclusion is that hierarchical policy representation provides 904 additional structure and context beyond the flat policy representation. 905 Furthermore, policies specifying bandwidth allocation using rule 906 hierarchies should be enforced using hierarchical schedulers where the 907 rule hierarchy level is mapped to the hierarchical scheduler level. 909 1.4.2. Use of Rule Hierarchy to Describe Drop Threshold Policies 911 Two major resources govern the per hop behavior in each node. The 912 bandwidth allocation resource governs the forwarding behavior of each 913 traffic class. A scheduler priority and weights are controlled by the 914 bandwidth allocation policies, as well as the (minimal) number of queues 915 needed for traffic separation. A second resource, which is not 916 controlled by bandwidth allocation policies, is the queuing length and 917 drop behavior. For this purpose, queue length and threshold policies are 918 used. 920 Rule hierarchy is used to describe the context on which thresholds act. 921 The policy rule's condition describes the traffic class and the rule's 922 actions describe the bandwidth allocation, the forwarding priority and 923 the queue length. If the traffic class contains different drop 924 precedence sub-classes that require different thresholds within the same 925 queue, the sub-rules actions describe these thresholds. 927 Below is an example of the use of rule nesting for threshold control 928 purposes. Let's look at the following rules: 930 If (protocol is FTP) THEN (guarantee 10% of available BW) 931 (queue length equals 40 packets) 932 (drop technique is random) 934 if (src-ip is from net 2.x.x.x) THEN min threshold = 30% 935 max threshold = 70% 937 if (src-ip is from net 3.x.x.x) THEN min threshold = 40% 938 max threshold = 90% 940 if (all other) THEN min threshold = 20% 941 max threshold = 60% 943 The rule describes the bandwidth allocation, the queue length and the 944 drop technique assigned to FTP flows. The sub-rules describe the drop 945 threshold priorities within those FTP flows. FTP packets received from 946 all networks apart from networks 2.x.x.x and 3.x.x.x are randomly 947 dropped when the queue threshold for FTP flows accumulates to 20% of the 948 queue length. Once the queue fills to 60%, all these packets are dropped 949 before queuing. The two other sub rules provide other thresholds for FTP 950 packets coming from the specified two subnets. The Assured Forwarding 951 per hop behavior (AF) is another good example of the use of hierarchy to 952 describe the different drop preferences within a traffic class. This 953 example is provided in a later section. 955 1.4.3. Restrictions of the Use of Hierarchy Within QPIM 957 Rule nesting is used within QPIM for two important purposes: 959 1) Enhance clarity, readability and reusability. 960 2) Provide hierarchical context for actions. 962 The second point captures the ability to specify context for bandwidth 963 allocation, as well as providing context for drop threshold policies. 965 When is a hierarchy level supposed to specify the bandwidth allocation 966 context, when is the hierarchy used for specifying the drop threshold 967 context, and when is it used merely for clarity and reusability? The 968 answer depends entirely on the actions. Bandwidth control actions within 969 a sub-rule specify how the bandwidth allocated to the traffic class 970 determined by the rule's condition clause should be further divided 971 among the sub-rules. Drop threshold actions control the traffic class's 972 queue drop behavior for each of the sub-rules. The bandwidth control 973 actions have an implicit pointer saying: the bandwidth allocation is 974 relative to the bandwidth resources defined by the higher level rule. 975 Drop threshold actions have an implicit pointer saying: the thresholds 976 are taken from the queue resources defined by the higher level rule. 977 Other actions do not have such an implicit pointer, and for these 978 actions hierarchy is used only for reusability and readability purposes. 980 Each rule that includes a bandwidth allocation action implies that a 981 queue should be allocated to the traffic class defined by the rule's 982 condition clause. Therefore, once a bandwidth allocation action exists 983 within the actions of a sub-rule, a threshold action within this sub- 984 rule cannot refer to thresholds of the parent rule's queue. Instead, it 985 must refer to the queue of the sub-rule itself. Therefore, in order to 986 have a clear and unambiguous definition, refinement of thresholds and 987 refinements of bandwidth allocations within sub-rules should be avoided. 988 If both refinements are needed for the same rule, threshold refinements 989 and bandwidth refinements rules should each be aggregated to a separate 990 group, and these groups should be aggregated under the policy rule, 991 using the PolicySetComponent aggregation. 993 1.5. Intended Audiences 995 QPIM is intended for several audiences. The following lists some of the 996 intended audiences and their respective uses: 998 1. Developers of QoS policy management applications can use this 999 model as an extensible framework for defining policies to 1000 control PEPs and PDPs in an interoperable manner. 1001 2. Developers of Policy Decision Point (PDP) systems built to 1002 control resource allocation signaled by RSVP requests. 1003 3. Developers of Policy Decision Points (PDP) systems built to create 1004 QoS configuration for PEPs. 1005 4. Builders of large organization data and knowledge bases who decide 1006 to combine QoS policy information with other networking policy 1007 information, assuming all modeling is based on [PCIM] and [PCIMe]. 1008 5. Authors of various standards may use constructs introduced in this 1009 document to enhance their work. Authors of data models wishing to 1010 map a storage specific technology to QPIM must use this document 1011 as well. 1013 2. Class Hierarchies 1015 2.1. Inheritance Hierarchy 1017 QPIM's class and association inheritance hierarchies are rooted in 1018 [PCIM] and [PCIMe]. Figures 1 and 2 depict these QPIM inheritance 1019 hierarchies, while noting their relationships to [PCIM] and 1020 [PCIMe]classes. Note that many other classes used to form QPIM policies, 1021 such as SimplePolicyCondition, are defined in [PCIM] and [PCIMe]. Thus, 1022 the following figures do NOT represent ALL necessary classes and 1023 relationships for defining QPIM policies. Rather, the designer using 1024 QPIM should use appropriate classes and relationships from [PCIM] and 1025 [PCIMe] in conjunction with those defined below. 1027 [ManagedElement] (abstract, PCIM) 1028 | 1029 +--Policy (abstract, PCIM) 1030 | | 1032 | +---PolicyAction (abstract, PCIM) 1033 | | | 1034 | | +---SimplePolicyAction (PCIMe) 1035 | | | | 1036 | | | +---QoSPolicyRSVPSimpleAction (QPIM) 1037 | | | 1038 | | +---QoSPolicyDiscardAction (QPIM) 1039 | | | 1040 | | +---QoSPolicyAdmissionAction (abstract, QPIM) 1041 | | | | 1042 | | | +---QoSPolicyPoliceAction (QPIM) 1043 | | | | 1044 | | | +---QoSPolicyShapeAction (QPIM) 1045 | | | | 1046 | | | +---QoSPolicyRSVPAdmissionAction (QPIM) 1047 | | | 1048 | | +---QoSPolicyPHBAction (abstract, QPIM) 1049 | | | 1050 | | +---QoSPolicyBandwidthAction (QPIM) 1051 | | | 1052 | | +---QoSPolicyCongestionControlAction (QPIM) 1053 | | 1054 | +---QoSPolicyTrfcProf (abstract, QPIM) 1055 | | | 1056 | | +---QoSPolicyTokenBucketTrfcProf (QPIM) 1057 | | | 1058 | | +---QoSPolicyIntServTrfcProf (QPIM) 1059 | | 1061 (continued on the next page) 1062 (continued from the previous page) 1064 [ManagedElement] (abstract, PCIM, repeated for convenience) 1065 | 1066 +--Policy (abstract, PCIM, repeated for convenience) 1067 | | 1068 | +---PolicyVariable (abstract, PCIMe) 1069 | | | 1070 | | +---PolicyImplicitVariable (abstract, PCIMe) 1071 | | | 1072 | | +---QoSPolicyRSVPVariable (abstract, QPIM) 1073 | | | 1074 | | +---QoSPolicyRSVPSourceIPv4Variable (QPIM) 1075 | | | 1076 | | +---QoSPolicyRSVPDestinationIPv4Variable (QPIM) 1077 | | | 1078 | | +---QoSPolicyRSVPSourceIPv6Variable (QPIM) 1079 | | | 1080 | | +---QoSPolicyRSVPDestinationIPv6Variable (QPIM) 1081 | | | 1082 | | +---QoSPolicyRSVPSourcePortVariable (QPIM) 1083 | | | 1084 | | +---QoSPolicyRSVPDestinationPortVariable (QPIM) 1085 | | | 1086 | | +---QoSPolicyRSVPIPProtocolVariable (QPIM) 1087 | | | 1088 | | +---QoSPolicyRSVPIPVersionVariable (QPIM) 1089 | | | 1090 | | +---QoSPolicyRSVPDCLASSVariable (QPIM) 1091 | | | 1092 | | +---QoSPolicyRSVPStyleVariable (QPIM) 1093 | | | 1094 | | +---QoSPolicyRSVPDIntServVariable (QPIM) 1095 | | | 1096 | | +---QoSPolicyRSVPMessageTypeVariable (QPIM) 1097 | | | 1098 | | +---QoSPolicyRSVPPreemptionPriorityVariable (QPIM) 1099 | | | 1100 | | +---QoSPolicyRSVPPreemptionDefPriorityVariable (QPIM) 1101 | | | 1102 | | +---QoSPolicyRSVPUserVariable (QPIM) 1103 | | | 1104 | | +---QoSPolicyRSVPApplicationVariable (QPIM) 1105 | | | 1106 | | +---QoSPolicyRSVPAuthMethodVariable (QPIM) 1107 | | 1108 | +---PolicyValue (abstract, PCIMe) 1109 | | | 1110 | | +---QoSPolicyDNValue (QPIM) 1111 | | | 1112 | | +---QoSPolicyAttributeValue (QPIM) 1114 Figure 1. The QPIM Class Inheritance Hierarchy 1116 2.2. Relationship Hierarchy 1118 Figure 2 shows the QPIM relationship hierarchy. 1120 [unrooted] (abstract, PCIM) 1121 | 1122 +---Dependency (abstract) 1123 | | 1124 | +--- QoSPolicyTrfcProfInAdmissionAction (QPIM) 1125 | | 1126 | +--- QoSPolicyConformAction (QPIM) 1127 | | 1128 | +--- QoSPolicyExceedAction (QPIM) 1129 | | 1130 | +--- QoSPolicyViolateAction (QPIM) 1131 | | 1132 | +--- PolicyVariableInSimplePolicyAction 1133 | | | 1134 | | + QoSPolicyRSVPVariableInRSVPSimplePolicyAction 1136 Figure 2. The QPIM Association Class Inheritance Hierarchy 1138 3. QoS Actions 1140 This section describes the QoS actions that are modeled by QPIM. QoS 1141 actions are policy enforced network behaviors that are specified for 1142 traffic selected by QoS conditions. QoS actions are modeled using the 1143 classes PolicyAction (defined in [PCIM]), SimplePolicyAction (defined in 1144 [PCIMe]) and several QoS actions defined in this document that are 1145 derived from both of these classes, which are described below. 1147 Note that there is no discussion of PolicyRule, PolicyGroup, or 1148 different types of PolicyCondition classes in this document. This is 1149 because these classes are fully specified in [PCIM] and [PCIMe]. 1151 3.1 Overview 1153 QoS policy based systems allow the network administrator to specify a 1154 set of rules that control both the selection of the flows that need to 1155 be provided with a preferred forwarding treatment, as well as specifying 1156 the specific set of preferred forwarding behaviors. QPIM provides an 1157 information model for specifying such a set of rules. 1159 QoS policy rules enable controlling environments in which RSVP signaling 1160 is used to request different forwarding treatment for different traffic 1161 types from the network, as well as environments where no signaling is 1162 used, but preferred treatment is desired for some (but not all) traffic 1163 types. QoS policy rules also allow controlling environments where strict 1164 QoS guarantees are provided to individual flows, as well as environments 1165 where QoS is provided to flow aggregates. QoS actions allow a PDP or a 1166 PEP to determine which RSVP requests should be admitted before network 1167 resources are allocated. QoS actions allow control of the RSVP signaling 1168 content itself, as well as differentiation between priorities of RSVP 1169 requests. QoS actions allow controlling the Differentiated Service edge 1170 enforcement including policing, shaping and marking, as well as the per- 1171 hop behaviors used in the network core. Finally, QoS actions can be used 1172 to control mapping of RSVP requests at the edge of a differentiated 1173 service cloud into per hop behaviors. 1175 Four groups of actions are derived from action classes defined in [PCIM] 1176 and [PCIMe]. The first QoS action group contains a single action, 1177 QoSPolicyRSVPSimpleAction. This action is used for both RSVP signal 1178 control and install actions. The second QoS action group determines 1179 whether a flow or class of flows should be admitted. This is done by 1180 specifying an appropriate traffic profile using the QoSPolicyTrfcProf 1181 class and its subclasses. This set of actions also includes QoS 1182 admission control actions, which use the QoSPolicyAdmissionAction class 1183 and its subclasses. The third group of actions control bandwidth 1184 allocation and congestion control differentiations, which together 1185 specify the per-hop behavior forwarding treatment. This group of actions 1186 includes the QoSPolicyPHBAction class and its subclasses. The fourth QoS 1187 action is an unconditional packet discard action, which uses the 1188 QoSPolicyDiscardAction class. This action is used either by itself or as 1189 a building block of the QoSPolicyPoliceAction. 1191 Note that some QoS actions are not directly modeled. Instead, they are 1192 modeled by using the class SimplePolicyAction with the appropriate 1193 associations. For example, the three marking actions (DSCP, IPP and CoS) 1194 are modeled by using the SimplePolicyAction class, and associating that 1195 class with variables and values of the appropriate type defined in 1196 [PCIMe]. 1198 3.2 RSVP Policy Actions 1200 There are three types of decisions a PDP (either remote or within a PEP) 1201 can make when it evaluates an RSVP request: 1203 1. Admit or reject the request 1204 2. Add or modify the request admission parameters 1205 3. Modify the RSVP signaling content 1207 The COPS for RSVP [RFC2749] specification uses different Decision object 1208 types to model each of these decisions. QPIM follows the COPS for RSVP 1209 specification and models each decision using a different action class. 1211 The QoSPolicyRSVPAdmissionAction controls the Decision Command and 1212 Decision Flags objects used within COPS for RSVP. The 1213 QoSPolicyRSVPAdmissionAction class, with its associated 1214 QoSPolicyIntServTrfcProf class, is used to determine whether to accept 1215 or reject a given RSVP request by comparing the RSVP request's TSPEC or 1216 RSPEC parameters against the traffic profile specified by the 1217 QoSPolicyIntServTrfcProf. For a full description of the comparison 1218 method, see section 4. Following the COPS for RSVP specification, the 1219 admission decision has an option to both accept the request and send a 1220 warning to the requester. The QoSPolicyRSVPAdmissionAction can be used 1221 to limit the number of admitted reservations as well. 1223 The class QoSPolicyRSVPSimpleAction, which is derived from the 1224 PolicySimpleAction class [PCIMe], can be used to control the two other 1225 COPS RSVP decision types. The property qpRSVPActionType designates the 1226 instance of the class to be either of type 'REPLACE', 'STATELESS', or 1227 both ('REPLACEANDSTATELESS'). For instances carrying a qpRSVPActionType 1228 property value of 'REPLACE', the action is interpreted as a COPS Replace 1229 Decision, controlling the contents of the RSVP message. For instances 1230 carrying a qpRSVPActionType property value of 'STATELESS', the action is 1231 interpreted as a COPS Stateless Decision, controlling the admission 1232 parameters. If both of these actions are required, this can be done by 1233 assigning the value REPLACEANDSTATELESS to the qpRSVPActionType 1234 property. 1236 This class is modeled to represent the COPS for RSVP Replace and 1237 Stateless decisions. This similarity allows future use of these COPS 1238 decisions to be directly controlled by a QoSPolicySimpleAction. The only 1239 required extension might be the definition of a new RSVP variable. 1241 3.2.1. Example: Controlling COPS Stateless Decision 1243 The QoSPolicyRSVPSimpleAction allows the specification of admission 1244 parameters. It allows specification of the preemption priority [RFC3181] 1245 of a given RSVP Reservation request. Using the preemption priority 1246 value, the PEP can determine the importance of a Reservation compared 1247 with already admitted reservations, and if necessary can preempt lower 1248 priority reservations to make room for the higher priority one. This 1249 class can also be used to control mapping of RSVP requests to a 1250 differentiated services domain by setting the 1251 QoSPolicyRSVPDCLASSVariable to the required value. This instructs the 1252 PEP to mark traffic matching the Session and Sender specifications 1253 carried in an RSVP request to a given DSCP value. 1255 3.2.2. Example: Controlling the COPS Replace Decision 1257 A Policy system should be able to control the information carried in the 1258 RSVP messages. The QoSPolicyRSVPSimpleAction allows control of the 1259 content of RSVP signaling messages. An RSVP message can carry a 1260 preemption policy object [RFC3181] specifying the priority of the 1261 reservation request in comparison to other requests. An RSVP message can 1262 also carry a policy object for authentication purposes. An RSVP message 1263 can carry a DCLASS [DCLASS] object that specifies to the receiver or 1264 sender the particular DSCP value that should be set on the data traffic. 1265 A COPS for RSVP Replacement Data Decision controls the content of the 1266 RSVP message by specifying a set of RSVP objects replacing or removing 1267 the existing ones. 1269 3.3 Provisioning Policy Actions 1271 The differentiated Service Architecture [DIFFSERV] was designed to 1272 provide a scalable QoS differentiation without requiring any signaling 1273 protocols running between the hosts and the network. The QoS actions 1274 modeled in QPIM can be used to control all of the building blocks of the 1275 Differentiated Service architecture, including per-hop behaviors, edge 1276 classification, and policing and shaping, without a need to specify the 1277 datapath mechanisms used by PEP implementations. This provides an 1278 abstraction level hiding the unnecessary details and allowing the 1279 network administrator to write rules that express the network 1280 requirements in a more natural form. In this architecture, as no 1281 signaling between the end host and the network occurs before the sender 1282 starts sending information, the QoS mechanisms should be set up in 1283 advance. This usually means that PEPs need to be provisioned with the 1284 set of policy rules in advance. 1286 Policing and Shaping actions are modeled as subclasses of the QoS 1287 admission action. DSCP and CoS marking are modeled by using the 1288 SimplePolicyAction ([PCIMe]) class associated with the appropriate 1289 variables and values. Bandwidth allocation and congestion control 1290 actions are modeled as subclasses of the QpQPolicyPHBAction, which is 1291 itself a subclass PolicyAction class ([PCIM]) 1292 3.3.1. Admission Actions: Controlling Policers and Shapers 1294 Admission Actions (QoSPolicyAdmissionAction and its subclasses) are used 1295 to police and/or shape traffic. 1297 Each Admission Action is bound to a traffic profile (QoSPolicyTrfcProf) 1298 via the QoSPolicyTrfcProfInAdmissionAction association. The traffic 1299 profile is used to meter traffic for purposes of policing or shaping. 1301 An Admission Action carries a scope property (qpAdmissionScope) that is 1302 used to determine whether the action controls individual traffic flows 1303 or aggregate traffic classes. The concepts of "flow" and "traffic class" 1304 are explained in [DIFFSERV] using the terms 'microflow' and 'traffic 1305 stream'. Roughly speaking, a flow is a set of packets carrying an IP 1306 header that has the same values for source IP, destination IP, protocol 1307 and layer 4 source and destination ports. A traffic class is a set of 1308 flows. In QPIM, simple and compound conditions can identify flows and/or 1309 traffic classes by using Boolean terms over the values of IP header 1310 fields, including the value of the ToS byte. 1312 Thus, the interpretation of the scope property is as follows: If the 1313 value of the scope property is 0 (per-flow), each (micro) flow that can 1314 be positively matched with the rule's condition is metered and policed 1315 individually. If the value of the scope property is 1 (per-class), all 1316 flows matched with the rule's condition are metered as a single 1317 aggregate and policed together. 1319 The following example illustrates the use of the scope property. Using 1320 two provisioned policing actions, the following policies can be 1321 enforced: 1323 - Make sure that each HTTP flow will not exceed 64kb/s 1324 - Make sure that the aggregate rate of all HTTP flows will not 1325 exceed 512Kb/s 1327 Both policies are modeled using the same class QoSPolicyPoliceAction 1328 (derived from QoSPolicyAdmissionAction). The first policy has its scope 1329 property set to 'flow', while the second policy has its scope property 1330 set to 'class'. The two policies are modeled using a rule with two 1331 police actions that, in a pseudo-formal definition, looks like the 1332 following: 1334 If (HTTP) Action1=police, Traffic Profile1=64kb/s, Scope1=flow 1335 Action2=police, Traffic Profile2=512kb/s, Scope2=class 1337 The provisioned policing action QoSPolicyPoliceAction has three 1338 associations, QoSPolicyConformAction, QoSPolicyExceedAction and 1339 QoSPolicyViolateAction. 1341 To accomplish the desired result stated above, two possible modeling 1342 techniques may be used: The two actions can be part of a single policy 1343 rule using two PolicyActionInPolicyRule [PCIM] associations. In this 1344 case the ExecutionStrategy property of the PolicyRule class [PCIMe] 1345 SHOULD be set to "Do All" so that both individual flows and aggregate 1346 streams are policed. 1348 Alternatively, Action1 and Action2 could be aggregated in a 1349 CompundPolicyAction instance using the PolicyActionInPolicyAction 1350 aggregations [PCIMe]. In this case, in order for both individual flows 1351 and aggregate traffic classes to be policed, the ExecutionStrategy 1352 property of the CompoundPolicyAction class [PCIMe] SHOULD be set to "Do 1353 All". 1355 The policing action is associated with a three-level token bucket 1356 traffic profile carrying rate, burst and excess-burst parameters. 1357 Traffic measured by a meter can be classified as conforming traffic when 1358 the metered rate is below the rate defined by the traffic profile, as 1359 excess traffic when the metered traffic is above the normal burst and 1360 below the excess burst size, and violating traffic when rate is above 1361 the maximum excess burst. 1363 The [DIFF-MIB] defines a two-level meter, and provides a means to 1364 combine two-level meters into more complex meters. In this document, a 1365 three-level traffic profile is defined. This allows construction of both 1366 two-level meters as well as providing an easier definition for three- 1367 level meters needed for creating AF [AF] provisioning actions. 1369 A policing action that models three-level policing MUST associate three 1370 separate actions with a three-level traffic profile. These actions are a 1371 conforming action, an exceeding action and a violating action. A 1372 policing action that models two-level policing uses a two-level traffic 1373 profile and associates only conforming and exceeding actions. A policing 1374 action with a three-level traffic profile that specifies an exceed 1375 action but does not specify a violate action implies that the action 1376 taken when the traffic is above the maximum excess burst is identical to 1377 the action taken when the traffic is above the normal burst. A policer 1378 determines whether the profile is being met, while the actions to be 1379 performed are determined by the associations QoSPolicyXXXAction. 1381 Shapers are used to delay some or all of the packets in a traffic 1382 stream, in order to bring the stream into compliance with a traffic 1383 profile. A shaper usually has a finite-sized buffer, and packets may be 1384 discarded if there is not sufficient buffer space to hold the delayed 1385 packets. Shaping is controlled by the QoSPolicyShapeAction class. The 1386 only required association is a traffic profile that specifies the rate 1387 and burst parameters that the outgoing flows should conform with. 1389 3.3.2 Controlling Markers 1391 Three types of marking control actions are modeled in QPIM: 1392 Differentiated Services Code Point (DSCP) assignment, IP Precedence 1393 (IPP) assignment and layer-2 Class of Service (CoS) assignment. These 1394 assignment actions themselves are modeled by using the 1395 SimplePolicyAction class associated with the appropriate variables and 1396 values. 1398 DSCP assignment sets ("marks" or "colors") the DS field of a packet 1399 header to a particular DS Code Point (DSCP), adding the marked packet to 1400 a particular DS behavior aggregate. 1402 When used in the basic form, "If then 'DCSP = ds1'", the 1403 assignment action assigns a DSCP value (ds1) to all packets that result 1404 in the condition being evaluated to true. 1406 When used in combination with a policing action, a different assignment 1407 action can be issued via each of the 'conform', 'exceed' and 'violate' 1408 action associations. This way, one may select a PHB in a PHB group 1409 according to the state of a meter. 1411 The semantics of the DSCP assignment is encapsulated in the pairing of a 1412 DSCP variable and a DSCP value within a single SimplePolicyAction 1413 instance via the appropriate associations. 1415 IPP assignment sets the IPP field of a packet header to a particular IPP 1416 value (0 through 7). The semantics of the IPP assignment is encapsulated 1417 in the pairing of a ToS variable (PolicyIPTosVariable) and a bit string value 1418 () (defined in [PCIMe]) within a single SimplePolicyAction instance via the 1419 appropriate associations. The bit string value is used in its masked bit string 1420 format. The mask indicates the relevant 3 bits of the IPP sub field within the 1421 ToS byte, while the bit string indicates the IPP value to be set. 1423 CoS assignments control the mapping of a per-hop behavior to a layer-2 1424 Class of Service. For example, mapping of a set of DSCP values into a 1425 802.1p user priority value can be specified using a rule with a 1426 condition describing the set of DSCP values, and a CoS assignment action 1427 that specifies the required mapping to the given user priority value. 1428 The semantics of the CoS assignment is encapsulated in the pairing of a 1429 CoS variable and a CoS value (integer in the range of 0 through 7) 1430 within a single SimplePolicyAction instance via the appropriate 1431 associations. 1433 3.3.3 Controlling Edge Policies - Examples 1435 Assuming that the AF1 behavior aggregate is enforced within a DS domain, 1436 policy rules on the boundaries of the network should mark packets to one 1437 of the AF1x DSCPs, depending on the conformance of the traffic to a 1438 predetermined three-parameter traffic profile. QPIM models such AF1 1439 policing action as defined in Figure 3. 1441 +-----------------------+ +------------------------------+ 1442 | QoSPolicyPoliceAction |====| QoSPolicyTokenBucketTrfcProf | 1443 | scope = class | | rate = x, bc = y, be = z | 1444 +-----------------------+ +------------------------------+ 1445 * @ # 1446 * @ # 1447 * @ +--------------------+ +--------------------------+ 1448 * @ | SimplePolicyAction |---| PolicyIntegerValue -AF13 | 1449 * @ +--------------------+ +--------------------------+ 1450 * @ 1451 * +--------------------+ +---------------------------+ 1452 * | SimplePolicyAction |---| PolicyIntegerValue - AF12 | 1453 * +--------------------+ +---------------------------+ 1454 * 1455 +--------------------+ +---------------------------+ 1456 | SimplePolicyAction |---| PolicyIntegerValue - AF11 | 1457 +--------------------+ +---------------------------+ 1459 Association and Aggregation Legend: 1461 **** QoSPolicyConformAction 1462 @@@@ QoSPolicyExceedAction 1463 #### QoSPolicyViolateAction 1464 ==== QoSTrfcProfInAdmissionAction 1465 ---- PolicyValueInSimplePolicyAction ([PCIMe]) 1466 &&&& PolicyVariableInSimplePolicyAction ([PCIMe], not shown) 1468 Figure 3. AF Policing and Marking 1470 The AF policing action is composed of a police action, a token bucket 1471 traffic profile and three instances of the SimplePolicyAction class. 1472 Each of the simple policy action instances models a different marking 1473 action. Each SimplePolicyAction uses the aggregation 1474 PolicyVariableInSimplePolicyAction to specify that the associated 1475 PolicyDSCPVariable is set to the appropriate integer value. This is 1476 done using the PolicyValueInSimplePolicyAction aggregation. The three 1477 PolicyVariableInSimplePolicyAction aggregations which connect the 1478 appropriate SimplePolicyActions with the appropriate DSCP Variables, are 1479 not shown in this figure for simplicity. AF11 is marked on detecting 1480 conforming traffic; AF12 is marked on detecting exceeding traffic, and 1481 AF13 on detecting violating traffic. 1483 The second example, shown in Figure 4, is the simplest policing action. 1484 Traffic below a two-parameter traffic profile is unmodified, while 1485 traffic exceeding the traffic profile is discarded. 1487 +-----------------------+ +------------------------------+ 1488 | QoSPolicyPoliceAction |====| QoSPolicyTokenBucketTrfcProf | 1489 | scope = class | | rate = x, bc = y | 1490 +-----------------------+ +------------------------------+ 1491 @ 1492 @ 1493 +-------------------------+ 1494 | QoSPolicyDiscardAction | 1495 +-------------------------+ 1497 Association and Aggregation Legend: 1498 **** QoSPolicyConformAction (not used) 1499 @@@@ QoSPolicyExceedAction 1500 #### QoSPolicyViolateAction (not used) 1501 ==== QoSTrfcProfInAdmissionAction 1503 Figure 4. A Simple Policing Action 1505 3.4 Per-Hop Behavior Actions 1507 A Per-Hop Behavior (PHB) is a description of the externally observable 1508 forwarding behavior of a DS node applied to a particular DS behavior 1509 aggregate [DIFFSERV]. The approach taken here is that a PHB action 1510 specifies both observable forwarding behavior (e.g., loss, delay, 1511 jitter) as well as specifying the buffer and bandwidth resources that 1512 need to be allocated to each of the behavior aggregates in order to 1513 achieve this behavior. That is, a rule with a set of PHB actions can 1514 specify that an EF packet must not be delayed more than 20 msec in each 1515 hop. The same rule may also specify that EF packets need to be treated 1516 with preemptive forwarding (e.g., with priority queuing), and specify 1517 the maximum bandwidth for this class, as well as the maximum buffer 1518 resources. PHB actions can therefore be used both to represent the final 1519 requirements from PHBs and to provide enough detail to be able to map 1520 the PHB actions into a set of configuration parameters to configure 1521 queues, schedulers, droppers and other mechanisms. 1523 The QoSPolicyPHBAction abstract class has two subclasses. The 1524 QoSPolicyBandwidthAction class is used to control bandwidth, delay and 1525 forwarding behavior, while the QoSPolicyCongestionControlAction class is 1526 used to control queue size, thresholds and congestion algorithms. The 1527 qpMaxPacketSize property of the QoSPolicyPHBAction class specifies the 1528 packet size in bytes, and is needed when translating the bandwidth and 1529 congestion control actions into actual implementation configurations. 1530 For example, an implementation measuring queue length in bytes will need 1531 to use this property to map the qpQueueSize property into the desired 1532 queue length in bytes. 1534 3.4.1 Controlling Bandwidth and Delay 1536 QoSPolicyBandwidthAction allows specifying the minimal bandwidth that 1537 should be reserved for a class of traffic. The property qpMinBandwidth 1538 can be specified either in Kb/sec or as a percentage of the total 1539 available bandwidth. The property qpBandwidthUnits is used to determine 1540 whether percentages or fixed values are used. 1542 The property qpForwardingPriority is used whenever preemptive forwarding 1543 is required. A policy rule that defines the EF PHB should indicate a 1544 non-zero forwarding priority. The qpForwardingPriority property holds an 1545 integer value to enable multiple levels of preemptive forwarding where 1546 higher values are used to specify higher priority. 1548 The property qpMaxBandwidth specifies the maximum bandwidth that should 1549 be allocated to a class of traffic. This property may be specified in 1550 PHB actions with non-zero forwarding priority in order to guard against 1551 starvation of other PHBs. 1553 The properties qpMaxDelay and qpMaxJitter specify limits on the per-hop 1554 delay and jitter in milliseconds for any given packet within a traffic 1555 class. Enforcement of the maximum delay and jitter may require use of 1556 preemptive forwarding as well as minimum and maximum bandwidth controls. 1557 Enforcement of low max delay and jitter values may also require 1558 fragmentation and interleave mechanisms over low speed links. 1560 The Boolean property qpFairness indicates whether flows should have a 1561 fair chance to be forwarded without drop or delay. A way to enforce a 1562 bandwidth action with qpFairness set to TRUE would be to build a queue 1563 per flow for the class of traffic specified in the rule's filter. In 1564 this way, interactive flows like terminal access will not be queued 1565 behind a bursty flow (like FTP) and therefore have a reasonable response 1566 time. 1568 3.4.2 Congestion Control Actions 1570 The QoSPolicyCongestionControlAction class controls queue length, 1571 thresholds and congestion control algorithms. 1573 A PEP should be able to keep in its queues qpQueueSize packets matching 1574 the rule's condition. In order to provide a link-speed independent queue 1575 size, the qpQueueSize property can also be measured in milliseconds. The 1576 time interval specifies the time needed to transmit all packets within 1577 the queue if the link speed is dedicated entirely for transmission of 1578 packets within this queue. The property qpQueueSizeUnit determines 1579 whether queue size is measured in number of packets or in milliseconds. 1581 The property qpDropMethod selects either tail-drop, head-drop or random- 1582 drop algorithms. The set of maximum and minimum threshold values can be 1583 specified as well, using qpDropMinThresholdValue and 1584 qpDropMaxThresholdValue properties, either in packets or in percentage 1585 of the total available queue size as specified by the 1586 qpDropThresholdUnits property. 1588 3.4.3 Using Hierarchical Policies: Examples for PHB Actions 1590 Hierarchical policy definition is a primary tool in the QoS Policy 1591 information model. Rule nesting introduced in [PCIMe] allows 1592 specification of hierarchical policies controlling RSVP requests, 1593 hierarchical shaping, policing and marking actions, as well as 1594 hierarchical schedulers and definition of the differences in PHB groups. 1596 This example provides a set of rules that specify PHBs enforced within a 1597 Differentiated Service domain. The network administrator chose to 1598 enforce the EF, AF11 and AF13 and Best Effort PHBs. For simplicity, AF12 1599 is not differentiated. The set of rules takes the form: 1601 If (EF) then do EF actions 1602 If (AF1) then do AF1 actions 1603 If (AF11) then do AF11 actions 1604 If (AF12) then do AF12 actions 1605 If (AF13) then do AF13 actions 1606 If (default) then do Default actions. 1608 EF, AF1, AF11, AF12 and AF13 are conditions that filter traffic 1609 according to DSCP values. The AF1 condition matches the entire AF1 PHB 1610 group including the AF11, AF12 and AF13 DSCP values. The default rule 1611 specifies the Best Effort rules. The nesting of the AF1x rules within 1612 the AF1 rule specifies that there are further refinements on how AF1x 1613 traffic should be treated relative to the entire AF1 PHB group. The set 1614 of rules reside in a PolicyGroup with a decision strategy property set 1615 to 'FirstMatching'. 1617 The class instances below specify the set of actions used to describe 1618 each of the PHBs. Queue sizes are not specified, but can easily be added 1619 to the example. 1621 The actions used to describe the Best Effort PHB are simple. No 1622 bandwidth is allocated to Best Effort traffic. The first action 1623 specifies that Best Effort traffic class should have fairness. 1625 QoSPolicyBandwidthAction BE-B: 1626 qpFairness: TRUE 1628 The second action specifies that the congestion algorithm for the Best 1629 Effort traffic class should be random, and specifies the thresholds in 1630 percentage of the default queue size. 1632 QoSPolicyCongestionControlAction BE-C: 1633 qpDropMethod: random 1634 qpDropThresholdUnits % 1635 qpDropMinThreshold: 10% 1636 qpDropMaxThreshold: 70% 1638 EF requires preemptive forwarding. The maximum bandwidth is also 1639 specified to make sure that the EF class does not starve the other 1640 classes. EF PHB uses tail drop as the applications using EF are supposed 1641 to be UDP-based and therefore would not benefit from a random dropper. 1643 QoSPolicyBandwidthAction EF-B: 1644 qpForwardingPriority: 1 1645 qpBandwidthUnits: % 1646 qpMaxBandwidth 50% 1647 qpFairness: FALSE 1649 QoSPolicyCongestionControlAction EF-C: 1650 qpDropMethod: tail-drop 1651 qpDropThresholdUnits packet 1652 qpDropMaxThreshold: 3 packets 1654 The AF1 actions define the bandwidth allocations for the entire PHB 1655 group: 1657 QoSPolicyBandwidthAction AF1-B: 1658 qpBandwidthUnits: % 1659 qpMinBandwidth: 30% 1661 The AF1i actions specifies the differentiating refinement for the AF1x 1662 PHBs within the AF1 PHB group. The different threshold values provide 1663 the difference in discard probability of the AF1x PHBs within the AF1 1664 PHB group. 1666 QoSPolicyCongestionControlAction AF11-C: 1667 qpDropMethod: random 1668 qpDropThresholdUnits packet 1669 qpDropMinThreshold: 6 packets 1670 qpDropMaxThreshold: 16 packets 1672 QoSPolicyCongestionControlAction AF12-C: 1673 qpDropMethod: random 1674 qpDropThresholdUnits packet 1675 qpDropMinThreshold: 4 packets 1676 qpDropMaxThreshold: 13 packets 1678 QoSPolicyCongestionControlAction AF13-C: 1679 qpDropMethod: random 1680 qpDropThresholdUnits packet 1681 qpDropMinThreshold: 2 packets 1682 qpDropMaxThreshold: 10 packets 1684 4. Traffic Profiles 1686 Meters measure the temporal state of a flow or a set of flows against a 1687 traffic profile. In this document, traffic profiles are modeled by the 1688 QoSPolicyTrfcProf class. The association 1689 QoSPolicyTrfcProf InAdmissionAction binds the traffic profile to the 1690 admission action using it. Two traffic profiles are derived from the 1691 abstract class QoSPolicyTrfcProf. The first is a Token Bucket 1692 provisioning traffic profile carrying rate and burst parameters. The 1693 second is an RSVP traffic profile, which enables flows to be compared 1694 with RSVP TSPEC and FLOWSPEC parameters. 1696 4.1 Provisioning Traffic Profiles 1698 Provisioned Admission Actions, including shaping and policing, are 1699 specified using a two- or three-parameter token bucket traffic profile. 1700 The QoSPolicyTokenBucketTrfcProf class includes the following 1701 properties: 1703 1. Rate measured in kbits/sec 1704 2. Normal burst measured in bytes 1705 3. Excess burst measured in bytes 1707 Rate determines the long-term average transmission rate. Traffic that 1708 falls under this rate is conforming, as long as the normal burst is not 1709 exceeded at any time. Traffic exceeding the normal burst but still below 1710 the excess burst is exceeding the traffic profile. Traffic beyond the 1711 excess burst is said to be violating the traffic profile. 1713 Excess burst size is measured in bytes in addition to the burst size. A 1714 zero excess burst size indicates that no excess burst is allowed. 1716 4.2 RSVP traffic profiles 1718 RSVP admission policy can condition the decision whether to accept or 1719 deny an RSVP request based on the traffic specification of the flow 1720 (TSPEC) or the amount of QoS resources requested (FLOWSPEC). The 1721 admission decision can be based on matching individual RSVP requests 1722 against a traffic profile or by matching the aggregated sum of all 1723 FLOWSPECs (TSPECs) currently admitted, as determined by the 1724 qpAdmissionScope property in an associated QoSPolicyRSVPAdmissionAction. 1726 The QoSPolicyIntservTrfcProf class models both such traffic profiles. 1727 This class has the following properties: 1729 1. Token Rate (r) measured in bits/sec 1730 2. Peak Rate (p) measured in bits/sec 1731 3. Bucket Size (b) measured in bytes 1732 4. Min Policed unit (m) measured in bytes 1733 5. Max packet size (M) measured in bytes 1734 6. Resv Rate (R) measured in bits/sec 1735 7. Slack term (s) measured in microseconds 1737 The first five parameters are the traffic specification parameters used 1738 in the Integrated Service architecture ([INTSERV]). These parameters are 1739 used to define a sender TSPEC as well as a FLOWSPEC for the Controlled- 1740 Load service [CL]. For a definition and full explanation of their 1741 meanings, please refer to [RSVP-IS]. 1743 Parameters 6 and 7 are the additional parameters used for specification 1744 of the Guaranteed Service FLOWSPEC [GS]. 1746 A partial order is defined between TSPECs (and FLOWSPECs). The TSPEC A 1747 is larger than the TSPEC B if and only if rA>rB, pA>pB, bA>bB, mAMB. A TSPEC (FLOWSPEC) measured against a traffic profile uses the 1749 same ordering rule. An RSVP message is accepted only if its TSPEC 1750 (FLOWSPEC) is either smaller or equal to the traffic profile. Only 1751 parameters specified in the traffic profile are compared. 1753 The GS FLOWSPEC is compared against the rate R and the slack term s. The 1754 term R should not be larger than the traffic profile R parameter, while 1755 the FLOWSPEC slack term should not be smaller than that specified in the 1756 slack term. 1758 TSPECs as well as FLOWSPECs can be added. The sum of two TSPECs is 1759 computed by summing the rate r, the peak rate p, the bucket size b, and 1760 by taking the minimum value of the minimum policed unit m and the 1761 maximum value of the maximum packet size M. GS FLOWSPECs are summed by 1762 adding the Resv rate and minimizing the slack term s. These rules are 1763 used to compute the temporal state of admitted RSVP states matching the 1764 traffic class defined by the rule condition. This state is compared with 1765 the traffic profile to arrive at an admission decision when the scope of 1766 the QoSPolicyRSVPAdmissionAction is set to 'class'. 1768 5. Pre-Defined QoS-Related Variables 1770 Pre-defined variables are necessary for ensuring interoperability among 1771 policy servers and policy management tools from different vendors. The 1772 purpose of this section is to define frequently used variables in QoS 1773 policy domains. 1775 Notice that this section only adds to the variable classes as defined in 1776 [PCIMe] and reuses the mechanism defined there. 1778 The QoS policy information model specifies a set of pre-defined variable 1779 classes to support a set of fundamental QoS terms that are commonly used 1780 to form conditions and actions and are missing from the [PCIMe]. 1781 Examples of these include RSVP related variables. All variable classes 1782 defined in this document extend the QoSPolicyRSVPVariable class (defined 1783 in this document), which itself extends the PolicyImplictVariable class, 1784 defined in [PCIMe]. Subclasses specify the data type and semantics of 1785 the policy variables. 1787 This draft defines the following RSVP variable classes; for details, see 1788 their class definitions: 1790 RSVP related Variables: 1792 1. QoSPolicyRSVPSourceIPv4Variable - The source IPv4 address of the 1793 RSVP signaled flow, as defined in the RSVP PATH SENDER_TEMPLATE 1794 and RSVP RESV FILTER_SPEC [RSVP] objects. 1795 2. QoSPolicyRSVPDestinationIPv4Variable - The destination port of the 1796 RSVP signaled flow, as defined in the RSVP PATH and RESV SESSION 1797 [RSVP] objects (for IPv4 traffic). 1798 3. QoSPolicyRSVPSourceIPv6Variable - The source IPv6 address of the 1799 RSVP signaled flow, as defied in the RSVP PATH SENDER_TEMPLATE and 1800 RSVP RESV FILTER_SPEC [RSVP] objects. 1801 4. QoSPolicyRSVPDestinationIPv6Variable - The destination port of the 1802 RSVP signaled flow, as defined in the RSVP PATH and RESV SESSION 1803 [RSVP] objects (for IPv6 traffic). 1804 5. QoSPolicyRSVPSourcePortVariable - The source port of the RSVP 1805 signaled flow, as defined in the RSVP PATH SENDER_TEMPLATE and 1806 RSVP RESV FILTER_SPEC [RSVP] objects. 1807 6. QoSPolicyRSVPDestinationPortVariable - The destination port of the 1808 RSVP signaled flow, as defined in the RSVP PATH and RESV SESSION 1809 [RSVP] objects. 1810 7. QoSPolicyRSVPIPProtocolVariable - The IP Protocol of the RSVP 1811 signaled flow, as defined in the RSVP PATH and RESV SESSION [RSVP] 1812 objects. 1813 8. QoSPolicyRSVPIPVersionVariable - The version of the IP addresses 1814 carrying the RSVP signaled flow, as defined in the RSVP PATH and 1815 RESV SESSION [RSVP] objects. 1816 9. QoSPolicyRSVPDCLASSVariable - The DSCP value as defined in the 1817 RSVP DCLASS [DCLASS] object. 1818 10. QoSPolicyRSVPStyleVariable - The reservation style (FF, SE, WF) as 1819 defined in the RSVP RESV message [RSVP]. 1821 11. QoSPolicyRSVPIntServVariable - The type of Integrated Service (CL, 1822 GS, NULL) requested in the RSVP Reservation message, as defined in 1823 the FLOWSPEC RSVP Object [RSVP]. 1824 12. QoSPolicyRSVPMessageTypeVariable - The RSVP message type, either 1825 PATH, PATHTEAR, RESV, RESVTEAR, RESVERR, CONF or PATHERR [RSVP]. 1826 13. QoSPolicyRSVPPreemptionPriorityVariable - The RSVP reservation 1827 priority as defined in [RFC3181]. 1828 14. QoSPolicyRSVPPreemptionDefPriorityVariable - The RSVP preemption 1829 reservation defending priority as defined in [RFC3181]. 1830 15. QoSPolicyRSVPUserVariable - The ID of the user that initiated the 1831 flow as defined in the User Locator string in the Identity Policy 1832 Object [RFC3182]. 1833 16. QoSPolicyRSVPApplicationVariable - The ID of the application that 1834 generated the flow as defined in the application locator string in 1835 the Application policy object [RFC2872]. 1836 17. QoSPolicyRSVPAuthMethodVariable - The RSVP Authentication type 1837 used in the Identity Policy Object [RFC3182]. 1839 Each class restricts the possible value types associated with a specific 1840 variable. For example, the QoSPolicyRSVPSourcePortVariable class is used 1841 to define the source port of the RSVP signaled flow. The value 1842 associated with this variable is of type PolicyIntegerValue. 1844 6. QoS Related Values 1846 Values are used in the information model as building blocks for the 1847 policy conditions and policy actions, as described in [PCIM] and 1848 [PCIMe]. This section defines a set of auxiliary values that are used 1849 for QoS policies as well as other policy domains. 1851 All value classes extend the PolicyValue class [PCIMe]. The subclasses 1852 specify specific data/value types that are not defined in [PCIMe]. 1854 This document defines the following two subclasses of the PolicyValue 1855 class: 1857 QoSPolicyDNValue - This class is used to represent a single or set of 1858 Distinguished Name [DNDEF] values, including 1859 wildcards. A Distinguished Name is a name that can 1860 be used as a key to retrieve an object from a 1861 directory service. This value can be used in 1862 comparison to reference values carried in RSVP 1863 policy objects, as specified in [RFC3182]. This 1864 class is defined in Section 8.31. 1866 QoSPolicyAttributeValue - A condition term uses the form "Variable 1867 matches Value", and an action term uses 1868 the form "set Variable to Value" ([PCIMe]). 1869 This class is used to represent a single or 1870 set of property values for the "Value" term 1871 in either a condition or an action. 1872 This value can be used in conjunction with 1873 reference values carried in RSVP objects, as 1874 specified in [RFC3182]. This class is 1875 defined in section 8.12. 1877 The property name is used to specify which of the properties in the 1878 QoSPolicyAttributeValue class instance is being used in the condition or 1879 action term. The value of this property or properties will then be 1880 retrieved. In the case of a condition, a match (which is dependent on 1881 the property name) will be used to see if the condition is satisfied or 1882 not. In the case of an action, the semantics are instead "set the 1883 variable to this value". 1885 For example, suppose the "user" objects in the organization include 1886 several properties, among them: 1888 - First Name 1889 - Last Name 1890 - Login Name 1891 - Department 1892 - Title 1894 A simple condition could be constructed to identify flows by their RSVP 1895 user carried policy object. The simple condition: Last Name = "Smith" to 1896 identify a user named Bill would be constructed in the following way: 1898 A SimplePolicyCondition [PCIMe] would aggregate a 1899 QoSPolicyRSVPUserVariable [QPIM] object, via the 1900 PolicyVariableInSimplePolicyCondition [PCIMe] aggregation. 1902 The implicit value associated with this condition is created in the 1903 following way: 1905 A QoSPolicyAttributeValue object would be aggregated to the simple 1906 condition object via a PolicyValueInSimplePolicyCondition [PCIMe]. 1907 The QoSPolicyAttributeValue attribute qpAttributeName would be set 1908 to "last name" and the qpAttributeValueList would be set to "Smith". 1910 Another example is a condition that has to do with the user's 1911 organizational department. It can be constructed in the exact same way, 1912 by changing the QoSPolicyAttributeValue attribute qpAttributeName to 1913 "Department" and the qpAttributeValueList would be set to the particular 1914 value that is to be matched (e.g., "engineering" or "customer support"). 1915 The logical condition would than be evaluated to true if the user belong 1916 to either the engineering department or the customer support. 1918 Notice that many multiple-attribute objects require the use of the 1919 QoSPolicyAttributeValue class to specify exactly which of its attributes 1920 should be used in the condition match operation. 1922 7. Class Definitions: Association Hierarchy 1924 The following sections define associations that are specified by QPIM. 1926 7.1. The Association "QoSPolicyTrfcProfInAdmissionAction" 1928 This association links a QoSPolicyTrfcProf object (defined in section 1929 8.9), modeling a specific traffic profile, to a QoSPolicyAdmissionAction 1930 object (defined in section 8.2). The class definition for this 1931 association is as follows: 1933 NAME QoSPolicyTrfcProfInAdmissionAction 1934 DESCRIPTION A class representing the association between a 1935 QoS admission action and its traffic profile. 1936 DERIVED FROM Dependency (See [PCIM]) 1937 ABSTRACT FALSE 1938 PROPERTIES Antecedent[ref QoSPolicyAdmissionAction [0..n]] 1939 Dependent[ref QoSPolicyTrfcProf [1..1]] 1941 7.1.1. The Reference "Antecedent" 1943 This property is inherited from the Dependency association, defined in 1944 [PCIM]. Its type is overridden to become an object reference to a 1945 QoSPolicyAdmissionAction object. This represents the "independent" part 1946 of the association. The [0..n] cardinality indicates that any number of 1947 QoSPolicyAdmissionAction object(s) may use a given QoSPolicyTrfcProf . 1949 7.1.2. The Reference "Dependent" 1951 This property is inherited from the Dependency association, and is 1952 overridden to become an object reference to a QoSPolicyTrfcProf 1953 object. This represents a specific traffic profile that is used by any 1954 number of QoSPolicyAdmissionAction objects. The [1..1] cardinality means 1955 that exactly one object of the QoSPolicyTrfcProf can be used by a 1956 given QoSPolicyAddmissionAction. 1958 7.2 The Association "PolicyConformAction" 1960 This association links a policing action with an object defining an 1961 action to be applied to conforming traffic relative to the associated 1962 traffic profile. The class definition for this association is as 1963 follows: 1965 NAME PolicyConformAction 1966 DESCRIPTION A class representing the association between a 1967 policing action and the action that should be applied 1968 to traffic conforming to an associated traffic 1969 profile. 1970 DERIVED FROM Dependency (see [PCIM]) 1971 ABSTRACT FALSE 1972 PROPERTIES Antecedent[ref QoSPolicyPoliceAction[0..n]] 1973 Dependent[ref PolicyAction [1..1]] 1975 7.2.1. The Reference "Antecedent" 1977 This property is inherited from the Dependency association. Its type is 1978 overridden to become an object reference to a QoSPolicyPoliceAction 1979 object. This represents the "independent" part of the association. The 1980 [0..n] cardinality indicates that any number of QoSPolicyPoliceAction 1981 objects may be given the same action to be executed as the conforming 1982 action. 1984 7.2.2. The Reference "Dependent" 1986 This property is inherited from the Dependency association, and is 1987 overridden to become an object reference to a PolicyAction object. This 1988 represents a specific policy action that is used by a given 1989 QoSPolicyPoliceAction. The [1..1] cardinality means that exactly one 1990 policy action can be used as the "conform" action for a 1991 QoSPolicyPoliceAction. To execute more than one conforming action, use 1992 the PolicyCompoundAction class to model the conforming action. 1994 7.3. The Association "QoSPolicyExceedAction" 1996 This association links a policing action with an object defining an 1997 action to be applied to traffic exceeding the associated traffic 1998 profile. The class definition for this association is as follows: 2000 NAME QoSPolicyExceedAction 2001 DESCRIPTION A class representing the association between a 2002 policing action and the action that should be applied 2003 to traffic exceeding an associated traffic profile. 2004 DERIVED FROM Dependency (see [PCIM]) 2005 ABSTRACT FALSE 2006 PROPERTIES Antecedent[ref QoSPolicePoliceAction[0..n]] 2007 Dependent[ref PolicyAction [1..1]] 2009 7.3.1. The Reference "Antecedent" 2011 This property is inherited from the Dependency association. Its type is 2012 overridden to become an object reference to a QoSPolicyPoliceAction 2013 object. This represents the "independent" part of the association. The 2014 [0..n] cardinality indicates that any number of QoSPolicyPoliceAction 2015 objects may be given the same action to be executed as the exceeding 2016 action. 2018 7.3.2. The Reference "Dependent" 2020 This property is inherited from the Dependency association, and is 2021 overridden to become an object reference to a PolicyAction object. This 2022 represents a specific policy action that is used by a given 2023 QoSPolicyPoliceAction. The [1..1] cardinality means that a exactly one 2024 policy action can be used as the "exceed" action by a 2025 QoSPolicyPoliceAction. To execute more than one conforming action, use 2026 the PolicyCompoundAction class to model the exceeding action. 2028 7.4. The Association "PolicyViolateAction" 2030 This association links a policing action with an object defining an 2031 action to be applied to traffic violating the associated traffic 2032 profile. The class definition for this association is as follows: 2034 NAME PolicyViolateAction 2035 DESCRIPTION A class representing the association between a 2036 policing action and the action that should be applied 2037 to traffic violating an associated traffic profile. 2038 DERIVED FROM Dependency (see [PCIM]) 2039 ABSTRACT FALSE 2040 PROPERTIES Antecedent[ref QoSPolicePoliceAction[0..n]] 2041 Dependent[ref PolicyAction [1..1]] 2043 7.4.1. The Reference "Antecedent" 2045 This property is inherited from the Dependency association. Its type is 2046 overridden to become an object reference to a QoSPolicyPoliceAction 2047 object. This represents the "independent" part of the association. The 2048 [0..n] cardinality indicates that any number of QoSPolicyPoliceAction 2049 objects may be given the same action to be executed as the violating 2050 action. 2052 7.4.2. The Reference "Dependent" 2054 This property is inherited from the Dependency association, and is 2055 overridden to become an object reference to a PolicyAction object. This 2056 represents a specific policy action that is used by a given 2057 QoSPolicyPoliceAction. The [1..1] cardinality means that exactly one 2058 policy action can be used as the "violate" action by a 2059 QoSPolicyPoliceAction. To execute more than one violating action, use 2060 the PolicyCompoundAction class to model the conforming action. 2062 7.5 The Aggregation "QoSPolicyRSVPVariableInRSVPSimplePolicyAction" 2064 A simple RSVP policy action is represented as a pair {variable, value}. 2065 This aggregation provides the linkage between a 2066 QoSPolicyRSVPSimpleAction instance and a single QoSPolicyRSVPVariable. 2067 The aggregation PolicyValueInSimplePolicyAction links the 2068 QoSPolicyRSVPSimpleAction to a single PolicyValue. 2070 The class definition for this aggregation is as follows: 2072 NAME QoSPolicyRSVPVariableInRSVPSimplePolicyAction 2073 DERIVED FROM PolicyVariableInSimplePolicyAction 2074 ABSTRACT FALSE 2075 PROPERTIES GroupComponent[ref QoSPolicyRSVPSimpleAction 2076 [0..n]] 2077 PartComponent[ref QoSPolicyRSVPVariable [1..1] ] 2079 7.5.1. The Reference "GroupComponent" 2081 The reference property "GroupComponent" is inherited from 2082 PolicyComponent, and overridden to become an object reference to a 2083 QoSPolicyRSVPSimpleAction that contains exactly one 2084 QoSPolicyRSVPVariable. Note that for any single instance of the 2085 aggregation class QoSPolicyRSVPVariableInRSVPSimplePolicyAction, this 2086 property is single-valued. The [0..n] cardinality indicates that there 2087 may be 0, 1, or more QoSPolicyRSVPSimpleAction objects that contain any 2088 given RSVP variable object. 2090 7.5.2. The Reference "PartComponent" 2092 The reference property "PartComponent" is inherited from 2093 PolicyComponent, and overridden to become an object reference to a 2094 QoSPolicyRSVPVariable that is defined within the scope of a 2095 QoSPolicyRSVPSimpleAction. Note that for any single instance of the 2096 association class QoSPolicyRSVPVariableInRSVPSimplePolicyAction, this 2097 property (like all reference properties) is single-valued. The [1..1] 2098 cardinality indicates that a 2099 QoSPolicyRSVPVariableInRSVPSimplePolicyAction must have exactly one RSVP 2100 variable defined within its scope in order to be meaningful. 2102 8. Class Definitions: Inheritance Hierarchy 2104 The following sections define object classes that are specified by QPIM. 2106 8.1. The Class QoSPolicyDiscardAction 2108 This class is used to specify that packets should be discarded. This is 2109 the same as stating that packets should be denied forwarding. The class 2110 definition is as follows: 2112 NAME QoSPolicyDiscardAction 2113 DESCRIPTION This action specifies that packets should be discarded. 2114 DERIVED FROM PolicyAction (defined in [PCIM]) 2115 ABSTRACT FALSEFALSE 2116 PROPERTIES None 2118 8.2. The Class QoSPolicyAdmissionAction 2120 This class is the base class for performing admission decisions based on 2121 a comparison of a meter measuring the temporal behavior of a flow or a 2122 set of flow with a traffic profile. The qpAdmissionScope property 2123 controls whether the comparison is done per flow or per class (of 2124 flows). Only packets that conform to the traffic profile are admitted 2125 for further processing; other packets are discarded. The class 2126 definition is as follows: 2128 NAME QoSPolicyAdmissionAction 2129 DESCRIPTION This action controls admission decisions based on 2130 comparison of a meter to a traffic profile. 2131 DERIVED FROM PolicyAction (defined in [PCIM]) 2132 ABSTRACT FALSEFALSE 2133 PROPERTIES qpAdmissionScope 2135 8.2.1. The Property qpAdmissionScope 2137 This attribute specifies whether the admission decision is done per flow 2138 or per the entire class of flows defined by the rule condition. If the 2139 scope is "flow", the actual or requested rate of each flow is compared 2140 against the traffic profile. If the scope is set to "class", the 2141 aggregate actual or requested rate of all flows matching the rule 2142 condition is measured against the traffic profile. The property is 2143 defined as follows: 2145 NAME qpAdmissionScope 2146 DESCRIPTION This property specifies whether the admission decision is 2147 done per flow or per the entire class of flows 2148 SYNTAX Integer 2149 VALUE This is an enumerated integer. A value of 0 specifies that 2150 admission is done on a per-flow basis, and a value of 1 2151 specifies that admission is done on a per-class basis. 2153 8.3. The Class QoSPolicyPoliceAction 2155 This is used for defining policing actions (i.e., those actions that 2156 restrict traffic based on a comparison with a traffic profile). Using 2157 the three associations QoSPolicyConformAction, QoSPolicyExceedAction and 2158 QoSPolicyViolateAction, it is possible to specify different actions to 2159 take based on whether the traffic is conforming, exceeding, or violating 2160 a traffic profile. The traffic profile is specified in a subclass of the 2161 QoSPolicyTrfcProf class. The class definition is as follows: 2163 NAME QoSPolicyPoliceAction 2164 DESCRIPTION This action controls the operation of policers. The rate of 2165 flows is measured against a traffic profile. The actions 2166 that need to be performed on conforming, exceeding and 2167 violating traffic are indicated using the conform, exceed 2168 and violate action associations. 2169 DERIVED FROM QoSPolicyAdmissionAction (defined in this document) 2170 ABSTRACT FALSEFALSE 2171 PROPERTIES None 2173 8.4. The Class QoSPolicyShapeAction 2175 This class is used for defining shaping actions. Shapers are used to 2176 delay some or all of the packets in a traffic stream in order to bring a 2177 particular traffic stream into compliance with a given traffic profile. 2178 The traffic profile is specified in a subclass of the QoSPolicyTrfcProf 2179 class. The class definition is as follows: 2181 NAME QoSPolicyShapeAction 2182 DESCRIPTION This action indicate that traffic should be shaped to be 2183 conforming with a traffic profile. 2184 DERIVED FROM QoSPolicyAdmissionAction (defined in this document) 2185 ABSTRACT FALSEFALSE 2186 PROPERTIES None 2188 8.5. The Class QoSPolicyRSVPAdmissionAction 2190 This class determines whether to accept or reject a given RSVP request 2191 by comparing the RSVP request's TSPEC or RSPEC parameters against the 2192 associated traffic profile and/or by enforcing the pre-set maximum 2193 sessions limit. The traffic profile is specified in the 2194 QoSPolicyIntServTrfcProf class. This class inherits the 2195 qpAdmissionScope property from its superclass. This property specifies 2196 whether admission should be done on a per-flow or per-class basis. If 2197 the traffic profile is not larger than or equal to the requested 2198 reservation, or to the sum of the admitted reservation merged with the 2199 requested reservation, the result is a deny decision. If no traffic 2200 profile is specified, the assumption is that all traffic can be 2201 admitted. 2203 The class definition is as follows: 2205 NAME QoSPolicyRSVPAdmissionAction 2206 DESCRIPTION This action controls the admission of RSVP requests. 2207 Depending on the scope, either a single RSVP request or the 2208 total admitted RSVP requests matching the conditions are 2209 compared against a traffic profile. 2210 DERIVED FROM QoSPolicyAdmissionAction (defined in this document) 2211 ABSTRACT FALSEFALSE 2212 PROPERTIES qpRSVPWarnOnly, qpRSVPMaxSessions 2214 8.5.1. The Property qpRSVPWarnOnly 2216 This property is applicable when fulfilling ("admitting") an RSVP 2217 request would violate the policer (traffic profile) limits or when the 2218 maximum number session would be exceeded (or both). 2220 When this property is set to TRUE, the RSVP request is admitted in spite 2221 of the violation, but an RSVP error message carrying a warning is sent 2222 to the originator (sender or receiver). When set to FALSE, the request 2223 would be denied and an error message would be sent back to the 2224 originator. So the meaning of the qpWarnOnly flag is: Based on 2225 property's value (TRUE or FALSE), determine whether to admit but warn 2226 the originator that the request is in violation or to deny the request 2227 altogether (and send back an error). 2229 Specifically, a PATHERR (in response to a Path message) or a RESVERR (in 2230 response of a RESV message) will be sent. This follows the COPS for RSVP 2231 send error flag in the Decision Flags object. This property is defined 2232 as follows: 2234 NAME qpRSVPWarnOnly 2235 SYNTAX Boolean 2236 Default FALSE 2237 VALUE The value TRUE means that the request should be admitted AND 2238 an RSVP warning message should be sent to the originator. The 2239 value of FALSE means that the request should be not admitted 2240 and an appropriate error message should be sent back to the 2241 originator of the request. 2243 8.5.2. The Property qpRSVPMaxSessions 2245 This attribute is used to limit the total number of RSVP requests 2246 admitted for the specified class of traffic. For this property to be 2247 meaningful, the qpAdmissionScope property must be set to class. The 2248 definition of this property is as follows: 2250 NAME qpRSVPMaxSessions 2251 SYNTAX Integer 2252 VALUE Must be greater than 0. 2254 8.6. The Class QoSPolicyPHBAction 2256 This class is a base class that is used to define the per-hop behavior 2257 that is to be assigned to behavior aggregates. It defines a common 2258 property, qpMaxPacketSize, for use by its subclasses 2259 (QoSPolicyBandwidthAction and QoSPolicyCongestionControlAction). The 2260 class definition is as follows: 2262 NAME QoSPolicyPHBAction 2263 DESCRIPTION This action controls the Per-Hop-Behavior provided to 2264 behavior aggregates. 2265 DERIVED FROM PolicyAction (defined in [PCIM]) 2266 ABSTRACT TRUE 2267 PROPERTIES qpMaxPacketSize 2269 8.6.1. The Property qpMaxPacketSize 2271 This property specifies the maximum packet size in bytes, of packets in 2272 the designated flow. This attribute is used in translation of QPIM 2273 attributes to QoS mechanisms used within a PEP. For example, queue 2274 length may be measured in bytes, while the minimum number of packets 2275 that should be kept in a PEP is defined within QPIM in number of 2276 packets. This property is defined as follows: 2278 NAME qpMaxPacketSize 2279 SYNTAX Integer 2280 Value Must be greater than 0 2282 8.7. The Class QoSPolicyBandwidthAction 2284 This class is used to control the bandwidth, delay, and forwarding 2285 behavior of a PHB. Its class definition is as follows: 2287 NAME QoSPolicyBandwidthAction 2288 DESCRIPTION This action controls the bandwidth, delay, and 2289 forwarding characteristics of the PHB. 2290 DERIVED FROM QoSPolicyPBHAction (defined in this document) 2291 ABSTRACT FALSE 2292 PROPERTIES qpForwardingPriority, qpBandwidthUnits, qpMinBandwdith, 2293 qpMaxBandwidth, qpMaxDelay, qpMaxJitter, qpFairness 2295 8.7.1. The Property qpForwardingPriority 2297 This property defines the forwarding priority for this set of flows. A 2298 non-zero value indicates that pre-emptive forwarding is required. Higher 2299 values represent higher forwarding priority. This property is defined as 2300 follows: 2302 NAME qpForwardingPriority 2303 SYNTAX Integer 2304 VALUE Must be non-negative. The value 0 means that pre-emptive 2305 forwarding is not required. A positive value indicates the 2306 priority that is to be assigned for this (set of) flow(s). 2307 Larger values represent higher priorities. 2309 8.7.2 The Property qpBandwidthUnits 2311 This property defines the units that the properties qpMinBandwidth and 2312 qpMaxBandwidth have. Bandwidth can either be defined in bits/sec or as a 2313 percentage of the available bandwidth or scheduler resources. This 2314 property is defined as follows: 2316 NAME qpBandwidthUnits 2317 SYNTAX Integer 2318 VALUE Two values are possible. The value of 0 is used to specify 2319 units of bits/sec, while the value of 1 is used to specify 2320 units as a percentage of the available bandwidth. If this 2321 property indicates that the bandwidth units are percentages, 2322 then each of the bandwidth properties expresses a whole- 2323 number percentage, and hence its maximum value is 100. 2325 8.7.3. The Property qpMinBandwidth 2327 This property defines the minimum bandwidth that should be reserved for 2328 this class of traffic. Both relative (i.e., a percentage of the 2329 bandwidth) and absolute (i.e., bits/second) values can be specified 2330 according to the value of the qpBandwidthUnits property. This property 2331 is defined as follows: 2333 NAME qpMinBandwidth 2334 SYNTAX Integer 2335 VALUE The value must be greater than 0. If the property 2336 qpMaxBandwidth is defined, then the value of qpMinBandwidth 2337 must be less than or equal to the value of qpMaxBandwidth. 2339 8.7.4. The Property qpMaxBandwidth 2341 This property defines the maximum bandwidth that should be allocated to 2342 this class of traffic. Both relative (i.e., a percentage of the 2343 bandwidth)and absolute (i.e., bits/second) values can be specified 2344 according to the value of the qpBandwidthUnits property. This property 2345 is defined as follows: 2347 NAME qpMaxBandwidth 2348 SYNTAX Integer 2349 VALUE The value must be greater than 0. If the property 2350 qpMaxBandwidth is defined, then the value of qpMinBandwidth 2351 must be less than or equal to the value of qpMaxBandwidth. 2353 8.7.5. The Property qpMaxDelay 2355 This property defines the maximal per-hop delay that traffic of this 2356 class should experience while being forwarded through this hop. The 2357 maximum delay is measured in microseconds. This property is defined as 2358 follows: 2360 NAME qpMaxDelay 2361 SYNTAX Integer (microseconds) 2362 VALUE The value must be greater than 0. 2364 8.7.6. The Property qpMaxJitter 2366 This property defines the maximal per-hop delay variance that traffic of 2367 this class should experience while being forwarded through this hop.The 2368 maximum jitter is measured in microseconds. This property is defined as 2369 follows: 2371 NAME qpMaxJitter 2372 SYNTAX Integer (microseconds) 2373 VALUE The value must be greater than 0. 2375 8.7.7. The Property qpFairness 2377 This property defines whether fair queuing is required for this class of 2378 traffic. This property is defined as follows: 2380 NAME qpFairness 2381 SYNTAX Boolean 2382 VALUE The value of FALSE means that fair queuing is not required 2383 for this class of traffic, while the value of TRUE means 2384 that fair queuing is required for this class of traffic. 2386 8.8. The Class QoSPolicyCongestionControlAction 2388 This class is used to control the characteristics of the congestion 2389 control algorithm being used. The class definition is as follows: 2391 NAME QoSPolicyCongestionControlAction 2392 DESCRIPTION This action control congestion control characteristics of 2393 the PHB. 2394 DERIVED FROM QoSPolicyPBHAction (defined in this document) 2395 ABSTRACT FALSE 2396 PROPERTIES qpQueueSizeUnits, qpQueueSize, qpDropMethod, 2397 qpDropThresholdUnits, qpDropMinThresholdValue, 2398 qpDropMaxThresholdValue 2400 8.8.1. The property qpQueueSizeUnits 2402 This property specifies the units in which the qpQueueSize attribute is 2403 measured. The queue size is measured either in number of packets or in 2404 units of time. The time interval specifies the time needed to transmit 2405 all packets within the queue if the link speed is dedicated entirely to 2406 transmission of packets within this queue. The property definition is: 2408 NAME qpQueueSizeUnits 2409 SYNTAX Integer 2410 VALUE This property can have two values. If the value is set to 0, 2411 then the unit of measurement is number of packets. If the 2412 value is set to 1, then the unit of measurement is 2413 milliseconds. 2415 8.8.2. The Property qpQueueSize 2417 This property specifies the maximum queue size in packets or in 2418 milliseconds, depending on the value of the qpQueueSizeUnits (0 2419 specifies packets, and 1 specifies milliseconds). This property is 2420 defined as follows: 2422 NAME qpQueueSize 2423 SYNTAX Integer 2424 VALUE This value must be greater than 0. 2426 8.8.3. The Property qpDropMethod 2428 This property specifies the congestion control drop algorithm that 2429 should be used for this type of traffic. This property is defined as 2430 follows: 2432 NAME qpDropMethod 2433 SYNTAX Integer 2434 VALUES Three values are currently defined. The value 0 specifies a 2435 random drop algorithm, the value 1 specifies a tail drop 2436 algorithm, and the value 2 specifies a head drop algorithm. 2438 8.8.4. The Property qpDropThresholdUnits 2440 This property specifies the units in which the two properties 2441 qpDropMinThresholdValue and qpDropMaxThresholdValue are measured. 2442 Thresholds can be measured either in packets or as a percentage of the 2443 available queue sizes. This property is defined as follows: 2445 NAME qpDropThresholdUnits 2446 SYNTAX Integer 2447 VALUES Three values are defined. The value 0 defines the units as 2448 number of packets, the value 1 defines the units as a 2449 percentage of the queue size and the value 2 defines the 2450 units in milliseconds. If this property indicates that the 2451 threshold units are percentages, then each of the threshold 2452 properties expresses a whole-number percentage, and hence 2453 its maximum value is 100. 2455 8.8.5. The Property qpDropMinThresholdValue 2457 This property specifies the minimum number of queuing and buffer 2458 resources that should be reserved for this class of flows. The threshold 2459 can be specified as either relative (i.e., a percentage) or absolute 2460 (i.e., number of packets or millisecond) value according to the value of 2461 the qpDropThresholdUnits property. If this property specifies a value of 2462 5 packets, then enough buffer and queuing resources should be reserved 2463 to hold 5 packets before running the specified congestion control drop 2464 algorithm. This property is defined as follows: 2466 NAME qpDropMinThresholdValue 2467 SYNTAX Integer 2468 VALUE This value must be greater than or equal to 0. If the 2469 property qpDropMaxThresholdValue is defined, then the value 2470 of the qpDropMinThresholdValue property must be less than or 2471 equal to the value of the qpDropMaxThresholdValue property 2473 8.8.6. The Property qpDropMaxThresholdValue 2475 This property specifies the maximum number of queuing and buffer 2476 resources that should be reserved for this class of flows. The threshold 2477 can be specified as either relative (i.e., a percentage) or absolute 2478 (i.e., number of packets or milliseconds) value according to the value 2479 of the qpDropThresholdUnits property. Congestion Control droppers should 2480 not keep more packets than the value specified in this property. Note, 2481 however, that some droppers may calculate queue occupancy averages, and 2482 therefore the actual maximum queue resources should be larger. This 2483 property is defined as follows: 2485 NAME qpDropMaxThresholdValue 2486 SYNTAX Integer 2487 VALUE This value must be greater than or equal to 0. If the 2488 property qpDropMinThresholdValue is defined, then the value 2489 of the qpDropMinThresholdValue property must be less than or 2490 equal to the value of the qpDropMaxThresholdValue property 2492 8.9. Class QoSPolicyTrfcProf 2494 This is an abstract base class that models a traffic profile. Traffic 2495 profiles specify the maximum rate parameters used within admission 2496 decisions. The association QoSPolicyTrfcProfInAdmissionAction binds the 2497 admission decision to the traffic profile. The class definition is as 2498 follows: 2500 NAME QoSPolicyTrfcProf 2501 DERIVED FROM Policy (defined in [PCIM]) 2502 ABSTRACT TRUE 2503 PROPERTIES None 2505 8.10. Class QoSPolicyTokenBucketTrfcProf 2507 This class models a two- or three-level Token Bucket traffic profile. 2508 Additional profiles can be modeled by cascading multiple instances of 2509 this class (e.g., by connecting the output of one instance to the input 2510 of another instance). This traffic profile carries the policer or shaper 2511 rate values to be enforced on a flow or a set of flows. The class 2512 definition is as follows: 2514 NAME QoSPolicyTokenBucketTrfcProf 2515 DERIVED FROM QoSPolicyTrfcProf (defined in this document) 2516 ABSTRACT FALSE 2517 PROPERTIES qpTBRate, qpTBNormalBurst, qpTBExcessBurst 2518 8.10.1. The Property qpTBRate 2520 This is a non-negative integer that defines the token rate in kilobits 2521 per second. A rate of zero means that all packets will be out of 2522 profile. This property is defined as follows: 2524 NAME qpTBRate 2525 SYNTAX Integer 2526 VALUE This value must be greater than to 0 2528 8.10.2. The Property qpTBNormalBurst 2530 This property is an integer that defines the normal size of a burst 2531 measured in bytes. This property is defined as follows: 2533 NAME qpTBNormalBurst 2534 SYNTAX Integer 2535 VALUE This value must be greater than to 0 2537 8.10.3. The Property qpTBExcessBurst 2539 This property is an integer that defines the excess burst size measured 2540 in bytes. This property is defined as follows: 2542 NAME qpTBExcessBurst 2543 SYNTAX Integer 2544 VALUE This value must be greater than or equal to qpTBNormalBurst 2546 8.11. Class QoSPolicyIntServTrfcProf 2548 This class represents an IntServ traffic profile. Values of IntServ 2549 traffic profiles are compared against Traffic specification (TSPEC) and 2550 QoS Reservation (FLOWSPEC) requests carried in RSVP requests. The class 2551 definition is as follows: 2553 NAME QoSPolicyIntServTrfcProf 2554 DERIVED FROM QoSPolicyTrfcProf (defined in this document) 2555 ABSTRACT FALSE 2556 PROPERTIES qpISTokenRate, qpISPeakRate, qpISBucketSize, qpISResvRate, 2557 qpISResvSlack, qpISMinPolicedUnit, qpISMaxPktSize 2559 8.11.1. The Property qpISTokenRate 2561 This property is a non-negative integer that defines the token rate 2562 parameter, measured in kilobits per second. This property is defined as 2563 follows: 2565 NAME qpISTokenRate 2566 SYNTAX Integer 2567 VALUE This value must be greater than or equal to 0 2569 8.11.2. The Property qpISPeakRate 2571 This property is a non-negative integer that defines the peak rate 2572 parameter, measured in kilobits per second. This property is defined as 2573 follows: 2575 NAME qpISPeakRate 2576 SYNTAX Integer 2577 VALUE This value must be greater than or equal to 0 2579 8.11.3. The Property qpISBucketSize 2581 This property is a non-negative integer that defines the token bucket 2582 size parameter, measured in bytes. This property is defined as follows: 2584 NAME qpISBucketSize 2585 SYNTAX Integer 2586 VALUE This value must be greater than or equal to 0 2588 8.11.4. The Property qpISResvRate 2590 This property is a non-negative integer that defines the reservation 2591 rate (R-Spec) in the RSVP guaranteed service reservation. It is measured 2592 in kilobits per second. This property is defined as follows: 2594 NAME qpISResvRate 2595 SYNTAX Integer 2596 VALUE This value must be greater than or equal to 0 2598 8.11.5. The Property qpISResvSlack 2600 This property is a non-negative integer that defines the RSVP slack term 2601 in the RSVP guaranteed service reservation. It is measured in 2602 microseconds. This property is defined as follows: 2604 NAME qpISResvSlack 2605 SYNTAX Integer 2606 VALUE This value must be greater than or equal to 0 2607 8.11.6. The Property qpISMinPolicedUnit 2609 This property is a non-negative integer that defines the minimum RSVP 2610 policed unit, measured in bytes. This property is defined as follows: 2612 NAME qpISMinPolicedUnit 2613 SYNTAX Integer 2614 VALUE This value must be greater than or equal to 0 2616 8.11.7. The Property qpISMaxPktSize 2618 This property is a positive integer that defines the maximum allowed 2619 packet size for RSVP messages, measured in bytes. This property is 2620 defined as follows: 2622 NAME qpISMaxPktSize 2623 SYNTAX Integer 2624 VALUE This value must be a positive integer, denoting the number 2625 of bytes in the largest payload packet of an RSVP signaled 2626 flow or class. 2628 8.12. The Class QoSPolicyAttributeValue 2630 This class can be used for representing an indirection in variable and 2631 value references either in a simple condition (" match ") or a 2632 simple action (" = "). In both cases, and are known as the 2633 variable and the value of either the condition or action. The value of 2634 the properties qpAttributeName and qpAttributeValueList are used to 2635 substitute and in the condition or action respectively. 2637 The substitution is done as follows: The value of the property 2638 qpAttributeName is used to substitute and the value of the property 2639 qpAttributeValueList is used to substitute . 2641 Once the substitution is done, the condition can be evaluated and the 2642 action can be performed. 2644 For example, suppose we want to define a condition over a user name of 2645 the form "user == 'Smith'", using the QoSPolicyRSVPUserVariable class. 2646 The user information in the RSVP message provides a DN. The DN points to 2647 a user objects holding many attributes. If the relevant attribute is 2648 "last name", we would use the QoSPolicyAttributeValue class with 2649 qpAttributeName = "Last Name", qpAttributeValueList = {"Smith"}. 2651 The class definition is as follows: 2653 NAME QoSPolicyAttributeValue 2654 DERIVED FROM PolicyValue (defined in [PCIMe]) 2655 ABSTRACT FALSE 2656 PROPERTIES qpAttributeName, qpAttributeValueList 2657 8.12.1. The Property qpAttributeName 2659 This property carries the name of the attribute that is to be used to 2660 substitute in a simple condition or simple condition of the forms 2661 " match " or " = " respectively. This property is defined as 2662 follows: 2664 NAME qpAttributeName 2665 SYNTAX String 2667 8.12.2. The Property qpAttributeValueList 2669 This property carries a list of values that is to be used to substitute 2670 in a simple condition or simple action of the forms " match " 2671 or " = " respectively. 2673 This property is defined as follows: 2675 NAME qpAttributeValueList 2676 SYNTAX String 2678 8.13. The Class "QoSPolicyRSVPVariable" 2680 This is an abstract class that serves as the base class for all implicit 2681 variables that have to do with RSVP conditioning. The class definition 2682 is as follows: 2684 NAME QoSPolicyRSVPVariable 2685 DESCRIPTION An abstract base class used to build other classes that 2686 specify different attributes of an RSVP request 2687 DERIVED FROM PolicyImplicitVariable (defined in [PCIMe]) 2688 ABSTRACT TRUE 2689 PROPERTIES None 2691 8.14. The Class "QoSPolicyRSVPSourceIPv4Variable" 2693 This is a concrete class that contains the source IPv4 address of the 2694 RSVP signaled flow, as defined in the RSVP PATH SENDER_TEMPLATE and RSVP 2695 RESV FILTER_SPEC [RSVP] objects. The class definition is as follows: 2697 NAME QoSPolicyRSVPSourceIPv4Variable 2698 DESCRIPTION The source IPv4 address of the RSVP signaled flow, as 2699 defined in the RSVP PATH SENDER_TEMPLATE and RSVP RESV 2700 FILTER_SPEC [RSVP] objects. 2702 ALLOWED VALUE TYPES: PolicyIPv4AddrValue 2704 DERIVED FROM QoSPolicyRSVPVariable (defined in this document) 2705 ABSTRACT FALSE 2706 PROPERTIES None 2707 8.15. The Class "QoSPolicyRSVPDestinationIPv4Variable" 2709 This is a concrete class that contains the destination IPv4 address of 2710 the RSVP signaled flow, as defined in the RSVP PATH SENDER_TEMPLATE and 2711 RSVP RESV FILTER_SPEC [RSVP] objects. The class definition is as 2712 follows: 2714 NAME QoSPolicyRSVPDestinationIPv4Variable 2715 DESCRIPTION The destination IPv4 address of the RSVP signaled 2716 flow, as defined in the RSVP PATH and RESV SESSION 2717 [RSVP] objects. 2719 ALLOWED VALUE TYPES: PolicyIPv4AddrValue 2721 DERIVED FROM QoSPolicyRSVPVariable (defined in this document) 2722 ABSTRACT FALSE 2723 PROPERTIES None 2725 8.16. The Class "QoSPolicyRSVPSourceIPv6Variable" 2727 This is a concrete class that contains the source IPv6 address of the 2728 RSVP signaled flow, as defined in the RSVP PATH SENDER_TEMPLATE and RSVP 2729 RESV FILTER_SPEC [RSVP] objects. The class definition is as follows: 2731 NAME QoSPolicyRSVPSourceIPv6Variable 2732 DESCRIPTION The source IPv6 address of the RSVP signaled flow, as 2733 defined in the RSVP PATH SENDER_TEMPLATE and RSVP RESV 2734 FILTER_SPEC [RSVP] objects. 2736 ALLOWED VALUE TYPES: PolicyIPv6AddrValue 2738 DERIVED FROM QoSPolicyRSVPVariable (defined in this document) 2739 ABSTRACT FALSE 2740 PROPERTIES None 2742 8.17. The Class "QoSPolicyRSVPDestinationIPv6Variable" 2744 This is a concrete class that contains the destination IPv6 address of 2745 the RSVP signaled flow, as defined in the RSVP PATH SENDER_TEMPLATE and 2746 RSVP RESV FILTER_SPEC [RSVP] objects. The class definition is as 2747 follows: 2749 NAME QoSPolicyRSVPDestinationIPv6Variable 2750 DESCRIPTION The destination IPv6 address of the RSVP signaled 2751 flow, as defined in the RSVP PATH and RESV SESSION 2752 [RSVP] objects. 2754 ALLOWED VALUE TYPES: PolicyIPv6AddrValue 2756 DERIVED FROM QoSPolicyRSVPVariable (defined in this document) 2757 ABSTRACT FALSE 2758 PROPERTIES None 2760 8.18. The Class "QoSPolicyRSVPSourcePortVariable" 2762 This class contains the source port of the RSVP signaled flow, as 2763 defined in the RSVP PATH SENDER_TEMPLATE and RSVP RESV FILTER_SPEC 2764 [RSVP] objects. The class definition is as follows: 2766 NAME QoSPolicyRSVPSourcePortVariable 2767 DESCRIPTION The source port of the RSVP signaled flow, as defined in 2768 the RSVP PATH SENDER_TEMPLATE and RSVP RESV FILTER_SPEC 2769 [RSVP] objects. 2771 ALLOWED VALUE TYPES: PolicyIntegerValue (0..65535) 2773 DERIVED FROM QoSPolicyRSVPVariable (defined in this document) 2774 ABSTRACT FALSE 2775 PROPERTIES None 2777 8.19. The Class "QoSPolicyRSVPDestinationPortVariable" 2779 This is a concrete class that contains the destination port of the RSVP 2780 signaled flow, as defined in the RSVP PATH SENDER_TEMPLATE and RSVP RESV 2781 FILTER_SPEC [RSVP] objects. The class definition is as follows: 2783 NAME QoSPolicyRSVPDestinationPortVariable 2784 DESCRIPTION The destination port of the RSVP signaled flow, as 2785 defined in the RSVP PATH and RESV SESSION [RSVP] objects. 2787 ALLOWED VALUE TYPES: PolicyIntegerValue (0..65535) 2789 DERIVED FROM QoSPolicyRSVPVariable (defined in this document) 2790 ABSTRACT FALSE 2791 PROPERTIES None 2792 8.20. The Class "QoSPolicyRSVPIPProtocolVariable" 2794 This is a concrete class that contains the IP Protocol number of the 2795 RSVP signaled flow, as defined in the RSVP PATH and RESV SESSION [RSVP] 2796 objects. The class definition is as follows: 2798 NAME QoSPolicyRSVPIPProtocolVariable 2799 DESCRIPTION The IP Protocol number of the RSVP signaled flow, as 2800 defined in the RSVP PATH and RESV SESSION [RSVP] objects. 2802 ALLOWED VALUE TYPES: PolicyIntegerValue 2804 DERIVED FROM QoSPolicyRSVPVariable (defined in this document) 2805 ABSTRACT FALSE 2806 PROPERTIES None 2808 8.21. The Class "QoSPolicyRSVPIPVersionVariable" 2810 This is a concrete class that contains the IP Protocol version number of 2811 the RSVP signaled flow, as defined in the RSVP PATH and RESV SESSION 2812 [RSVP] objects. The well-known version numbers are 4 and 6. This 2813 variable allows a policy definition of the type: 2815 "If IP version = IPv4 then ...". 2817 The class definition is as follows: 2819 NAME QoSPolicyRSVPIPVersionVariable 2820 DESCRIPTION The IP version number of the IP Addresses carried the 2821 RSVP signaled flow, as defined in the RSVP PATH and RESV 2822 SESSION [RSVP] objects. 2824 ALLOWED VALUE TYPES: PolciIntegerValue 2826 DERIVED FROM QoSPolicyRSVPVariable (defined in this document) 2827 ABSTRACT FALSE 2828 PROPERTIES None 2830 8.22. The Class "QoSPolicyRSVPDCLASSVariable" 2832 This is a concrete class that contains the DSCP value as defined in the 2833 RSVP DCLASS [DCLASS] object. The class definition is as follows: 2835 NAME QoSPolicyRSVPDCLASSVariable 2836 DESCRIPTION The DSCP value as defined in the RSVP DCLASS [DCLASS] 2837 object. 2839 ALLOWED VALUE TYPES: PolicyIntegerValue, 2840 PolicyBitStringValue 2842 DERIVED FROM QoSPolicyRSVPVariable (defined in this document) 2843 ABSTRACT FALSE 2844 PROPERTIES None 2846 8.23. The Class "QoSPolicyRSVPStyleVariable" 2848 This is a concrete class that contains the reservation style as defined 2849 in the RSVP STYLE object in the RESV message [RSVP]. The class 2850 definition is as follows: 2852 NAME QoSPolicyRSVPStyleVariable 2853 DESCRIPTION The reservation style as defined in the RSVP STYLE object 2854 in the RESV message [RSVP]. 2856 ALLOWED VALUE TYPES: PolicyBitStringValue, 2857 PolicyIntegerValue (Integer has an 2858 enumeration of { Fixed-Filter=1, 2859 Shared-Explicit=2, 2860 Wildcard-Filter=3} 2862 DERIVED FROM QoSPolicyRSVPVariable (defined in this document) 2863 ABSTRACT FALSE 2864 PROPERTIES None 2866 8.24. The Class "QoSPolicyIntServVariable" 2868 This is a concrete class that contains the Integrated Service requested 2869 in the RSVP Reservation message, as defined in the FLOWSPEC RSVP Object 2870 [RSVP]. The class definition is as follows: 2872 NAME QoSPolicyRSVPIntServVariable 2873 DESCRIPTION The integrated Service requested in the RSVP Reservation 2874 message, as defined in the FLOWSPEC RSVP Object [RSVP]. 2876 ALLOWED VALUE TYPES: PolicyIntegerValue (An enumerated 2877 value of { CL=1 , GS=2, NULL=3} 2879 DERIVED FROM QoSPolicyRSVPVariable (defined in this document) 2880 ABSTRACT FALSE 2881 PROPERTIES None 2882 8.25. The Class "QoSPolicyRSVPMessageTypeVariable" 2884 This is a concrete class that contains the RSVP message type, as defined 2885 in the RSVP message common header [RSVP] object. The class definition is 2886 as follows: 2888 NAME QoSPolicyRSVPMessageTypeVariable 2889 DESCRIPTION The RSVP message type, as defined in the RSVP message 2890 common header [RSVP] object. 2892 ALLOWED VALUE TYPES: Integer (An enumerated value of 2893 {PATH=1 , PATHTEAR=2, RESV=3, 2894 RESVTEAR=4, RESVERR=5, CONF=6, 2895 PATHERR=7} 2897 DERIVED FROM QoSPolicyRSVPVariable (defined in this document) 2898 ABSTRACT FALSE 2899 PROPERTIES None 2901 8.26. The Class "QoSPolicyRSVPPreemptionPriorityVariable" 2903 This is a concrete class that contains the RSVP reservation priority, as 2904 defined in [RFC3181] object. The class definition is as follows: 2906 NAME QoSPolicyRSVPPreemptionPriorityVariable 2907 DESCRIPTION The RSVP reservation priority as defined in [RFC3181]. 2909 ALLOWED VALUE TYPES: PolicyIntegerValue 2911 DERIVED FROM QoSPolicyRSVPVariable (defined in this document) 2912 ABSTRACT FALSE 2913 PROPERTIES None 2915 8.27. The Class "QoSPolicyRSVPPreemptionDefPriorityVariable" 2917 This is a concrete class that contains the RSVP reservation defending 2918 priority, as defined in [RFC3181] object. The class definition is as 2919 follows: 2921 NAME QoSPolicyRSVPPreemptionDefPriorityVariable 2922 DESCRIPTION The RSVP preemption reservation defending priority as 2923 defined in [RFC3181]. 2925 ALLOWED VALUE TYPES: PolicyIntegerValue 2927 DERIVED FROM QoSPolicyRSVPVariable (defined in this document) 2928 ABSTRACT FALSE 2929 PROPERTIES None 2930 8.28. The Class "QoSPolicyRSVPUserVariable" 2932 This is a concrete class that contains the ID of the user that initiated 2933 the flow as defined in the User Locator string in the Identity Policy 2934 Object [RFC3182]. The class definition is as follows: 2936 NAME QoSPolicyRSVPUserVariable 2937 DESCRIPTION The ID of the user that initiated the flow as defined in 2938 the User Locator string in the Identity Policy Object 2939 [RFC3182]. 2941 ALLOWED VALUE TYPES: QoSPolicyDNValue, PolicyStringValue, 2942 QoSPolicyAttributeValue 2944 DERIVED FROM QoSPolicyRSVPVariable (defined in this document) 2945 ABSTRACT FALSE 2946 PROPERTIES None 2948 8.29. The Class "QoSPolicyRSVPApplicationVariable" 2950 This is a concrete class that contains the ID of the application that 2951 generated the flow as defined in the application locator string in the 2952 Application policy object [RFC2872]. The class definition is as follows: 2954 NAME QoSPolicyRSVPApplicationVariable 2955 DESCRIPTION The ID of the application that generated the flow as 2956 defined in the application locator string in the 2957 Application policy object [RFC2872]. 2959 ALLOWED VALUE TYPES: QoSPolicyDNValue, PolicyStringValue, 2960 QoSPolicyAttributeValue 2962 DERIVED FROM QoSPolicyRSVPVariable (defined in this document) 2963 ABSTRACT FALSE 2964 PROPERTIES None 2965 8.30. The Class "QoSPolicyRSVPAuthMethodVariable" 2967 This is a concrete class that contains the type of authentication used 2968 in the Identity Policy Object [RFC3182]. The class definition is as 2969 follows: 2971 NAME QoSPolicyRSVPAuthMethodVariable 2972 DESCRIPTION The RSVP Authentication type used in the Identity Policy 2973 Object [RFC3182]. 2975 ALLOWED VALUE TYPES: PolicyIntegerValue (An enumeration of 2976 { NONE=0, PLAIN-TEXT=1, 2977 DIGITAL-SIG = 2, KERBEROS_TKT=3, 2978 X509_V3_CERT=4, PGP_CERT=5} 2980 DERIVED FROM QoSPolicyRSVPVariable (defined in this document) 2981 ABSTRACT FALSE 2982 PROPERTIES None 2984 8.31. The Class QoSPolicyDNValue 2986 This class is used to represent a single or set of Distinguished Name 2987 [DNDEF] values, including wildcards. A Distinguished Name is a name that 2988 can be used as a key to retrieve an object from a directory service. 2989 This value can be used in comparison to reference values carried in RSVP 2990 policy objects, as specified in [RFC3182]. The class definition is as 2991 follows: 2993 NAME QoSPolicyDNValue 2994 DERIVED FROM PolicyValue 2995 ABSTRACT FALSE 2996 PROPERTIES qpDNList 2998 8.31.1. The Property qpDNList 3000 This attribute provides an unordered list of strings, each representing 3001 a Distinguished Name (DN) with wildcards. The format of a DN is defined 3002 in [DNDEF]. The asterisk character ("*") is used as wildcard for either 3003 a single attribute value or a wildcard for an RDN. The order of RDNs is 3004 significant. For example: A qpDNList attribute carrying the following 3005 value: 3007 "CN=*, OU=Sales, O=Widget Inc., *, C=US" matches: 3009 "CN=J. Smith, OU=Sales, O=Widget Inc, C=US" 3011 and also matches: 3013 "CN=J. Smith, OU=Sales, O=Widget Inc, L=CA, C=US". 3015 The attribute is defined as follows: 3017 NAME qpDNList 3018 SYNTAX List of Distinguished Names implemented as strings, each of 3019 which serves as a reference to another object. 3021 8.32. The Class QoSPolicyRSVPSimpleAction 3023 This action controls the content of RSVP messages and the way RSVP 3024 requests are admitted. Depending on the value of its qpRSVPActionType 3025 property, this action directly translates into either a COPS Replace 3026 Decision or a COPS Stateless Decision, or both as defined in COPS for 3027 RSVP. Only variables that are subclasses of the QoSPolicyRSVPVariable 3028 are allowed to be associated with this action. The property definition 3029 is as follows: 3031 NAME QoSPolicyRSVPSimpleAction 3032 DESCRIPTION This action controls the content of RSVP messages and the 3033 way RSVP requests are admitted. 3034 DERIVED FROM SimplePolicyAction (defined in [PCIMe]) 3035 ABSTRACT FALSE 3036 PROPERTIES qpRSVPActionType 3038 8.32.1. The Property qpRSVPActionType 3040 This is a multi-valued property that may contain one value to denote the 3041 type of RSVP action. The value 'REPLACE' denotes a COPS Replace Decision 3042 action. The value 'STATELESS' denotes a COPS Stateless Decision action. 3043 The value REPLACEANDSTATELESS denotes both decision actions. Refer to 3044 [RFC2749] for details. This property is single-valued enumerated attribute. 3046 NAME qpRSVPActionType 3047 DESCRIPTION This property specifies whether the action type is for 3048 COPS Replace, Stateless, or both types of decisions. 3049 SYNTAX Integer 3050 VALUE This is an enumerated integer. A value of 0 specifies a 3051 COPS Replace decision. A value of 1 specifies a COPS 3052 Stateless Decision. A value of 2 specifies both COPS 3053 Replace and COPS Stateless decisions. 3055 9. Intellectual Property 3057 The IETF takes no position regarding the validity or scope of any 3058 intellectual property or other rights that might be claimed to 3059 pertain to the implementation or use of the technology described in 3060 this document or the extent to which any license under such rights 3061 might or might not be available; neither does it represent that it 3062 has made any effort to identify any such rights. Information on the 3063 IETF's procedures with respect to rights in standards-track and 3064 standards-related documentation can be found in BCP-11. 3066 Copies of claims of rights made available for publication and any 3067 assurances of licenses to be made available, or the result of an 3068 attempt made to obtain a general license or permission for the use of 3069 such proprietary rights by implementers or users of this 3070 specification can be obtained from the IETF Secretariat. 3072 The IETF invites any interested party to bring to its attention any 3073 copyrights, patents or patent applications, or other proprietary 3074 rights which may cover technology that may be required to practice 3075 this standard. Please address the information to the IETF Executive 3076 Director. 3078 10. Acknowledgements 3080 The authors wish to thank the input of the participants of the Policy 3081 Framework working group, and especially the combined group of the PCIMe 3082 coauthors, Lee Rafalow, Andrea Westerinen, Ritu Chadha and Marcus 3083 Brunner. In addition we'd like to acknowledge the valuable contribution 3084 from Ed Ellesson, Joel Halpern and Mircea Pana. Thank you all for your 3085 comments, critique, ideas and general contribution. 3087 11. Security Considerations 3089 The Policy Core Information Model [PCIM] describes the general security 3090 considerations related to the general core policy model. The extensions 3091 defined in this document do not introduce any additional considerations 3092 related to security. 3094 12. Normative References 3096 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 3097 Requirement Levels", BCP 14, RFC 2119, March 1997. 3099 [PCIM] Strassner, J., and E. Ellesson, B. Moore, A. Westerinen, 3100 "Policy Core Information Model -- Version 1 Specification", 3101 RFC 3060, February 2001. 3103 [PCIMe] B. Moore, L. Rafalow, Y. Ramberg, Y. Snir, J. Strassner, 3104 A. Westerinen, R. Chadha, M. Brunner, R. Cohen, 3105 "Policy Core Information Model Extensions", 3106 RFC 3460, January 2003 3108 13. Informative References 3110 [TERMS] A. Westerinen, J. Schnizlein, J. Strassner, M. Scherling, 3111 B. Quinn, J. Perry, S. Herzog, A. Huynh, M. Carlson, 3112 S. Waldbusser, "Terminology for Policy-based Management", 3113 RFC 3198, May 2003 3115 [DIFFSERV] S. Blake, et. Al., "An Architecture for Differentiated 3116 Services", RFC 2475 3118 [INTSERV] R. Braden, D. Clark, S. Shenker, "Integrated Services in 3119 the Internet Architecture: an Overview", RFC 1633. 3121 [RSVP] R. Braden, Ed., L. Zhang, S. Berson, S. Herzog, S. Jamin, 3122 "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional 3123 Specification", RFC2205 3125 [RFC2749] S . Herzog, Ed., J. Boyle, R. Cohen, D. Durham, R. Rajan, 3126 A. Sastry, "COPS usage for RSVP", RFC2749 3128 [RFC3181] S. Herzog, "Signaled Preemption Priority Policy Element", 3129 RFC3181 3131 [DIFF-MIB] F. Baker, K. Chan, A. Smith, "Management Information Base 3132 for the Differentiated Services Architecture", 3133 3135 [AF] J. Heinanen, F. Baker, W. Weiss, J. Wroclawski, "Assured 3136 Forwarding PHB Group", RFC2597 3138 [CL] J. Wroclawski, "Specification of the Controlled-Load Network 3139 Element Service", RFC2211 3141 [RSVP-IS] J. Wroclawski, "The Use of RSVP with IETF Integrated 3142 Services", RFC2210 3144 [GS] S. Shenker, C. Partridge, R. Guerin, "Specification of the 3145 Guaranteed Quality of Service", RFC2212 3147 [DCLASS] Y. Bernet, "Format of the RSVP DCLASS Object", RFC2996 3148 [RFC3182] S. Yadav, R. Yavatkar, R. Pabbati, P. Ford, T. Moore, 3149 S. Herzog, "Identity Representation for RSVP", RFC3182 3151 [RFC2872] Y. Bernet, R. Pabbati, "Application and Sub Application 3152 Identity Policy Element for Use with RSVP", RFC2872 3154 [DNDEF] M. Wahl, S. Kille, and T. Howes, "Lightweight Directory 3155 Access Protocol (v3): UTF-8 String Representation of 3156 Distinguished Names", RFC2253 3158 14. Authors' Addresses 3160 Yoram Ramberg 3161 Cisco Systems 3162 4 Maskit Street 3163 Herzliya Pituach, Israel 46766 3164 Phone: +972-9-970-0081 3165 Fax: +972-9-970-0219 3166 E-mail: yramberg@cisco.com 3168 Yoram Snir 3169 Cisco Systems 3170 300 East Tasman Tasman Drive 3171 San Jose, CA 95134 3172 Phone: +1 408-853-4053 3173 Fax: +1 408 526-7864 3174 E-mail: ysnir@cisco.com 3176 John Strassner 3177 Intelliden Corporation 3178 90 South Cascade Avenue 3179 Colorado Springs, Colorado 80903 3180 Phone: +1-719-785-0648 3181 Fax: +1-719-785-0644 3182 E-mail: john.strassner@intelliden.com 3184 Ron Cohen 3185 Ntear LLC 3186 Phone: +972-8-9402586 3187 Fax: +972-9-9717798 3188 E-mail: ronc@lyciumnetworks.com 3189 Bob Moore 3190 IBM Corporation 3191 P. O. Box 12195, BRQA/501/G206 3192 3039 Cornwallis Rd. 3193 Research Triangle Park, NC 27709-2195 3194 Phone: +1 919-254-4436 3195 Fax: +1 919-254-6243 3196 E-mail: remoore@us.ibm.com 3198 15. Full Copyright Statement 3200 Copyright (C) The Internet Society (2003). All Rights Reserved. 3202 This document and translations of it may be copied and furnished to 3203 others, and derivative works that comment on or otherwise explain it or 3204 assist in its implementation may be prepared, copied, published and 3205 distributed, in whole or in part, without restriction of any kind, 3206 provided that the above copyright notice and this paragraph are included 3207 on all such copies and derivative works. However, this document itself 3208 may not be modified in any way, such as by removing the copyright notice 3209 or references to the Internet Society or other Internet organizations, 3210 except as needed for the purpose of developing Internet standards in 3211 which case the procedures for copyrights defined in the Internet 3212 Standards process must be followed, or as required to translate it into 3213 languages other than English. 3215 The limited permissions granted above are perpetual and will not be 3216 revoked by the Internet Society or its successors or assigns. 3218 This document and the information contained herein is provided on an 3219 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 3220 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 3221 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 3222 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 3223 FITNESS FOR A PARTICULAR PURPOSE.