idnits 2.17.1 draft-ietf-policy-qos-info-model-01.txt: -(1089): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(2867): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. == There are 16 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 4011 lines 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 240 instances of lines with control characters in the document. ** The abstract seems to contain references ([QoSSCHEMA], [PCIM], [QOSDEV]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. == There are 4 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 2967 has weird spacing: '...ues and const...' == Line 3547 has weird spacing: '...ntation be pr...' == Line 3550 has weird spacing: '... itself not b...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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: 'QoSSCHEMA' is mentioned on line 236, but not defined == Missing Reference: 'COPS-RSVP' is mentioned on line 1771, but not defined == Missing Reference: 'NAMES' is mentioned on line 3060, but not defined == Missing Reference: 'IDENT' is mentioned on line 3204, but not defined == Unused Reference: 'DEREF' is defined on line 3431, but no explicit reference was found in the text == Unused Reference: 'DNDEF' is defined on line 3438, but no explicit reference was found in the text == Unused Reference: 'IDNET' is defined on line 3447, but no explicit reference was found in the text == Unused Reference: 'NAME' is defined on line 3460, but no explicit reference was found in the text == Unused Reference: 'PIB' is defined on line 3479, but no explicit reference was found in the text == Unused Reference: 'TERMS' is defined on line 3502, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (ref. 'ABNF') (Obsoleted by RFC 4234) -- Possible downref: Non-RFC (?) normative reference: ref. 'DEREF' ** Downref: Normative reference to an Informational RFC: RFC 2475 (ref. 'DIFF-SERV-ARCH') ** Obsolete normative reference: RFC 2253 (ref. 'DNDEF') (Obsoleted by RFC 4510, RFC 4514) ** Obsolete normative reference: RFC 2752 (ref. 'IDNET') (Obsoleted by RFC 3182) ** Obsolete normative reference: RFC 2373 (ref. 'IPv6') (Obsoleted by RFC 3513) -- Possible downref: Non-RFC (?) normative reference: ref. 'PCIM' -- Possible downref: Non-RFC (?) normative reference: ref. 'PHBLDAP' -- Possible downref: Non-RFC (?) normative reference: ref. 'PHBSET' -- Possible downref: Non-RFC (?) normative reference: ref. 'PFSCHEMA' -- Possible downref: Non-RFC (?) normative reference: ref. 'PIB' -- Possible downref: Non-RFC (?) normative reference: ref. 'QOSDEV' -- Possible downref: Non-RFC (?) normative reference: ref. 'QOSSCHEMA' Summary: 12 errors (**), 0 flaws (~~), 20 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Policy Framework Y. Snir 2 Internet Draft Y. Ramberg 3 Expires April 2000 J. Strassner 4 draft-ietf-policy-qos-info-model-01.txt R. Cohen 5 Cisco Systems 7 Policy Framework QoS Information Model 9 Status of this Memo 11 This document is an Internet Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet Drafts. 18 Internet Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html 29 Distribution of this memo is unlimited. 31 Copyright Notice 33 Copyright (C) The Internet Society (1999). All Rights Reserved. 35 Abstract 37 This document presents an object-oriented information model for 38 representing network QoS policies. This document refines the core 39 policy information model presented in [PCIM]. Specifically, this draft 40 refines the concept of generic policy rules, conditions and actions to 41 cover extensions necessary for representing QoS policies. It also 42 provides refinement of additional concepts that are important for 43 building rule-specific as well as reusable QoS policy rules. This 44 information model covers Differentiated Services QoS enforcement, and 45 Integrated Service QoS enforcement via policy control on RSVP 46 admission. It is important to note that this document defines an 47 information model, which by definition is independent of any particular 48 repository and access protocol. A companion document [QoSSCHEMA] 49 defines the mapping of these classes to a directory that uses LDAPv3 as 50 its access protocol. A second companion document [QOSDEV] supplies low- 51 level definitions of QoS mechanisms that are controlled by this 52 document. 54 Snir, Ramberg, Strassner, Cohen expires October 2000 1 55 Draft-ietf-policy-qos-info-model-01.txt April 2000 57 Table of Contents 59 1. Introduction 5 60 1.1 Goals 5 61 1.2 Approach and Related Documents 5 63 2. Information Model Hierarchy 6 64 2.1 Interaction Between the PCIM and This Document 7 65 2.1.1 Extension of Concepts in the PCIM 7 66 2.1.2 Addition of New Concepts Not in the PCIM 7 67 2.2 High-Level Class Hierarchy 8 69 3. Containment Hierarchy 11 70 3.1. Containment Model 11 71 3.2. QoS Domain Containment Hierarchy 12 72 3.2.1. Domain Grouping and Nesting 13 73 3.2.2. Resource Sharing 15 74 3.2.3. Placement 15 75 3.2.4. Named Policy Containers 16 76 3.2.5. Policy Rules 17 77 3.2.6. Conditions and Actions 18 78 3.2.7. Data Tree Example 19 79 3.3. Reusable-Object Repositories 19 80 3.4. Relationships Between QoS Domains and Repositories 20 82 4. Constructing a QoS Policy Rule 21 83 4.1 Policy Rule Structure 21 84 4.2 QoS Policy Conditions 22 85 4.2.1 Reusable vs. Ad-Hoc Conditions 23 86 4.2.2. Using Simple Conditions 24 87 4.2.3. Composing Complex Conditions 24 88 4.3 Simple Condition Operator 25 89 4.4. QoS Policy Variables 25 90 4.4.1 Variable Binding 26 91 4.4.2. Pre-Defined Variables 26 92 4.5 QoS Policy Values 30 93 4.6. PolicyTimePeriodCondition 30 94 4.7. Actions 30 95 4.7.1 Provisioning Actions 31 96 4.7.1.1 Meters 32 97 4.7.1.2 Markers 32 98 4.7.1.3 Shapers 32 99 4.7.1.4 Droppers 33 100 4.7.1.5 Examples 33 101 4.7.2 Signaling Actions 34 102 4.8 Traffic Profiles 37 103 4.8.1 Provisioning Traffic Profiles 37 104 4.8.1 RSVP Traffic Profiles 38 106 5. Decision strategy 39 107 5.1. First match 39 108 5.2. Match All 39 110 Snir, Ramberg, Strassner, Cohen expires October 2000 2 111 Draft-ietf-policy-qos-info-model-01.txt April 2000 113 5.3. Decision Strategy example 40 114 5.3.1 Default Operation using First Match Everywhere 40 115 5.3.2 Operation Using Other Decision Strategies 41 117 6. Per Hop Behavior 42 118 6.1. PHBs 42 119 6.2. PHB Sets 42 121 7. QoS Policy Class Inheritance 43 123 8. Class Definitions 45 124 8.1. Class qosPolicyDomain 45 125 8.1.1. The Property qpDomainName 45 126 8.1.2. The Property qpPHBSet 45 127 8.1.3. The Property qpPolicyRuleMatchMethod 45 128 8.2. Class qosNamedPolicyContainer 46 129 8.2.1. The Property qpPriority 46 130 8.2.2. The Property qpNamedPolicyRuleMatchMethod 46 131 8.3. Class qosPolicyPRAction 47 132 8.3.1. The Property qpDirection 47 133 8.3.2. The Property qpSetDSCPvalue 47 134 8.3.3. The Property qpMeter 47 135 8.3.4. The Property qpMeterScope 48 136 8.3.5. The Property qpTrfcProf 48 137 8.3.6. The Property qpOutOfProfileAction 48 138 8.3.7. The Property qpOutofProfileRemarkValue 48 139 8.4. Class qosPolicyRSVPAction 48 140 8.4.1. The Property qpRSVPDirection 49 141 8.4.2. The Property qpRSVPMessageType 49 142 8.4.3. The Property qpRSVPStyle 49 143 8.4.4. The Property qpRSVPServiceType 49 144 8.4.5. The Property qpRSVPInstallAction 50 145 8.4.6. The Property qpRSVPCtrlAction 50 146 8.4.7. The Property qpRSVPMeter 50 147 8.4.8. The Property qpRSVPMeterScope 50 148 8.4.9. The Property qpRSVPTrfcProf 51 149 8.5. Class qosPolicyPRTrfcProf 51 150 8.5.1. The Property qpPRRate 51 151 8.5.2. The Property qpPRNormalBurst 51 152 8.5.3. The Property qpPRExcessBurst 51 153 8.6. Class qosPolicyRSVPTrfcProf 52 154 8.6.1. The Property qpRSVPTokenRate 52 155 8.6.2. The Property qpRSVPPeakRate 52 156 8.6.3. The Property qpRSVPBucketSize 52 157 8.6.4. The Property qpRSVPResvRate 53 158 8.6.5. The Property qpRSVPResvSlack 53 159 8.6.6. The Property qpRSVPSessionNum 53 160 8.6.7. The Property qpMinPolicedUnit 53 161 8.6.8. The Property qpMaxPktSize 53 162 8.7. Class qosPolicyRSVPSignalCtrlAction 54 163 8.7.1. The Property qpForwardingMode 54 164 8.7.2. The Property qpSendError 54 166 Snir, Ramberg, Strassner, Cohen expires October 2000 3 167 Draft-ietf-policy-qos-info-model-01.txt April 2000 169 8.7.3. The Property qpReplaceDSCP 55 170 8.7.4. The Property qpReplacePreemptionPriority 55 171 8.7.5. The Property qpReplaceDefendingPriority 55 172 8.8. Class qosPolicyRSVPInstallAction 55 173 8.8.1. The Property qpSetDSCPValue 56 174 8.8.2. The Property qpSetDefendingPriority 56 175 8.8.3. The Property qpSetPreemptionPriority 56 176 8.9. Class qosPolicySimpleCondition 56 177 8.9.1. The Property qpOperator 57 178 8.9.2. The Property qpVariableAtom 57 179 8.9.3. The Property qpValueAtom 57 180 8.10. Class qosPolicyVariable 57 181 8.10.1. The Property qpVariableName 58 182 8.10.2 The Property qpValueTypes 58 183 8.10.3. The Property qpVariableDescription 58 184 8.10.4. The Property qpValueConstraints 59 185 8.11. Class qosPolicyValue 59 186 8.12. Class qosPolicyIPv4AddrValue 59 187 8.12.1. The Property qpIPv4AddrList 59 188 8.13. Class qosPolicyIPv6AddrValue 60 189 8.13.1. The Property qpIPv6AddrList 60 190 8.14. Class qosPolicyMACAddrValue 61 191 8.14.1. The Property qpMACAddrList 61 192 8.15. Class qosPolicyStringValue 62 193 8.15.1. The Property qpStringList 62 194 8.16 Class qosPolicyBitStringValue 62 195 8.16.1. The Property qpBitStringList 62 196 8.17. Class qosPolicyDNValue 63 197 8.17.1. The Property qpDNList 63 198 8.18. Class qosPolicyAttributeValue 63 199 8.18.1. The Property qpAttributeName 64 200 8.18.2. The Property qpAttributeValueList 64 201 8.19. Class qosPolicyIntegerValue 64 202 8.19.1. The Property qpIntegerList 65 203 8.20. Class qosPolicyPHBSet 65 204 8.21. Class qosPolicyPHB 65 205 8.21.1. The Property qpDSCP 66 206 8.22. Class qosPolicyMeter 66 208 9. Extending the QoS Policy Schema 67 209 9.1. Extending qosPolicyValue 67 210 9.2. Extending qosPolicySimpleCondition 67 211 9.3. Extending qosPolicyAction 67 213 10. Security Considerations 68 215 11. Acknowledgments 68 217 12. References 68 219 13. Author's Addresses 69 221 14. Full Copyright Statement 70 223 Snir, Ramberg, Strassner, Cohen expires October 2000 4 224 Draft-ietf-policy-qos-info-model-01.txt April 2000 226 1. Introduction 228 This document presents an object-oriented information model for 229 representing network QoS policies. As such, it is independent of any 230 specific repository type and access protocol. This document refines the 231 core policy information model presented in [PCIM]. Specifically, this 232 draft refines the concept of generic policy rules, conditions and 233 actions to cover extensions necessary for representing QoS policies. 234 This information model covers Differentiated Service QoS enforcement, 235 and Integrated Service QoS enforcement via policy control on RSVP 236 admission. A companion document [QoSSCHEMA] defines the mapping 237 of these classes to a directory that uses LDAPv3 as its access 238 protocol. A second companion document [QOSDEV] supplies low-level 239 definitions of QoS mechanisms that are controlled by this document. 241 1.1 Goals 243 This document presents high level QoS policies that can be used to 244 enforce consistent behavior across a network, regardless of the actual 245 vendor-specific implementation details. The purpose of introducing a 246 standard information model is to allow interoperability between Policy 247 Servers, Policy Management Applications, and Network devices. 249 This document solves two problems. First, different devices have 250 different capabilities, and may respond differently to the same high- 251 level policy rule. This document solves this by defining a set of 252 common abstractions that can be used to build high-level QoS policies. 253 This enables different devices to use the same low-level abstractions 254 of mechanisms to implement QoS services, which are controlled by the 255 QoS policy rules defined in this document. The companion document 256 [QOSDEV] defines an information model for representing low-level QoS 257 mechanisms. 259 Second, different policy servers and applications may provision parts 260 of the network differently if no common high-level policy description 261 exists. This document defines a standard information model that 262 provides common definitions and semantics to be assigned to build, 263 interpret and enforce high-level policy rules. 265 1.2 Approach and Related Documents 267 The information model presented in this document contains information 268 that can be shared by other network policy managers (e.g., Security 269 managers, IP address managers, and others). Examples include sharing of 270 the same definition of well-known application port numbers, IP 271 addresses of servers and other network attributes. It allows checking 272 of consistent behaviors of the interaction between the different 273 managers by comparing, for example, the set of QoS and security actions 274 enforced on the same set of flows. 276 Snir, Ramberg, Strassner, Cohen expires October 2000 5 277 Draft-ietf-policy-qos-info-model-01.txt April 2000 279 Representation of the inherent QoS mechanisms of devices is described 280 in a companion draft [QOSDEV]. It provides a standard information model 281 for representing low-level QoS mechanisms that exist in devices in a 282 vendor-independent way. This document, augmented with the information 283 provided in [QOSDEV], together provide a set of enforceable policies 284 that control the QoS mechanisms on network devices. 286 The concept of PHBs is central to Differentiated Services. An 287 additional information model for representation of PHBs is defined in 288 [PHBSET], and a corresponding LDAP representation is provided in 289 [PHBLDAP]. This document is also intended to work with [PHBSET]. 291 The remainder of this document presents, describes and defines the 292 concepts of the QoS Policy Information Model (QPIM). Relationships to 293 the Core schema and issues related to correct usage of the schema are 294 defined in [QOSSCHEMA]. 296 2. Information Model Hierarchy 298 This section discusses the relationships between the Policy Core 299 Information Model ([PCIM]), the QoS Policy Information Model (QPIM, 300 which is this document) and future extensions of the QPIM. 302 The [PCIM] models high-level policy concepts and introduces structural 303 conventions and nomenclature common to all types of policies. The 304 fundamental purpose of the [PCIM] is to provide a generic 305 representation of the structure of a policy rule, along with a set of 306 classes and relationships that can serve as a common representation of 307 policy groups, rules, conditions, and actions. This enables derived 308 information models and schemata to all use a common set of terminology, 309 classes, and approaches, thus facilitating interoperability. 311 The QPIM refines the concepts of the [PCIM] and introduces a framework 312 of classes and relationships dedicated to model QoS Policies. This set 313 of classes and relationships can be used to configure and manage 314 devices that are IntServ- and DiffServ-compliant. The QPIM provides 315 building blocks to control most of the policy aspects required by 316 IntServ and DiffServ, but it is clear that not all functions are 317 provided. 319 It is also clear that other information models and their derived 320 schemata can use some of the concepts in this document. For example, 321 the concept of representing IP Addresses, as well as variables and 322 constants, are not specific to QoS. However, this is the first 323 information model that is derived from the [PCIM], and it is not clear 324 that other working groups will be satisfied with these representations. 325 These concepts will be socialized to other working groups and, if they 326 agree with the representation in this document (or if a suitable 327 compromise can be developed), then these concepts will be moved into a 328 separate document. 330 Snir, Ramberg, Strassner, Cohen expires October 2000 6 331 Draft-ietf-policy-qos-info-model-01.txt April 2000 333 The PCIM and QPIM are both inherently extensible. Furthermore, they are 334 designed to fit together to produce one virtual information model. As 335 such, both are independent of any particular repository and access 336 protocol. However, mappings can be defined to translate the data from 337 this single "virtual information model" to a form that can be 338 implemented in a specific type of repository that uses one or more 339 specific access protocols. Examples of mapping the concepts of the 340 [PCIM] and this document to a form that can be implemented in a 341 directory that uses LDAP as its access protocol are provided in 342 [PFSCHEMA] and [QOSSCHEMA], respectively. 344 This document specifies an extensible information model. While this 345 document defines facilities for building policy rules, conditions and 346 actions to build QoS policies, it is recognized that not all required 347 functionality can or should be defined in this document. Therefore, any 348 implementation-specific schema that is derived from this information 349 model should further concretize the QoS concepts of the QoS Policy 350 schema to suit its own application-specific needs. 352 2.1 Interaction Between the PCIM and This Document 354 This document both extends concepts that are part of the [PCIM] as well 355 as adds new functions that are not part of the [PCIM]. 357 2.1.1 Extension of Concepts in the PCIM 359 The concept of a policy repository, that is embedded within another 360 repository that contains policy and non-policy information, was 361 originally defined in an earlier version of the QPIM. It has 362 subsequently been moved into the [PCIM], since it is a generic concept 363 that is not limited to QoS, and can be used by other applications. This 364 document defines specific refinements of the "embedded policy 365 repository" to accommodate the application-specific needs of QoS 366 provisioning. 368 Similarly, the concepts of reusable- objects vs. rule-specific objects 369 have been moved from an earlier version of this document to the [PCIM]. 370 Equally similarly, this document defines specific extensions to 371 guide the implementation of reusable- vs. rule-specific QoS objects. 373 This document also extends the concept of a policy rule, along with 374 conditions and actions that are specific to QoS. It further defines 375 different types of actions that target DiffServ and IntServ actions. 377 2.1.2 Addition of New Concepts Not in the PCIM 379 There are several notable new concepts that are not part of the [PCIM]. 380 These include rule nesting, rule decision strategy, pre-defined 381 variables and constants, and PHBs. 383 Snir, Ramberg, Strassner, Cohen expires October 2000 7 384 Draft-ietf-policy-qos-info-model-01.txt April 2000 386 The [PCIM] defines the ability to group policy rules by defining the 387 policyGroup class. This class has the following semantics: it can 388 either be used to contain a set of policyRules, or a set of 389 policyGroups, but not both. However, this simply gathers policy rules 390 together in a common container. It does not nest policy rules. 392 This document adds the concept of nesting one or more policy rules 393 within a policy rule. For example, one could think of a policy rule 394 that controls how a user logs onto the network as consisting of the 395 high-level rule itself. This high-level rule could consist of a set of 396 lower-level rules that are invoked at various stages of processing 397 (e.g., how the user is authenticated, how the IP Address is assigned, 398 etc.). 400 Since there is no concept of nested rules in the [PCIM], there is no 401 need for a decision strategy to be used to define the order of 402 processing of these rules. However, such a decision strategy must be 403 defined in this document because it does define nested rules. This 404 strategy defines an ordering that can be applied to a set of policyRule 405 and policyGroup objects within a larger context (e.g., a policy 406 domain). This in turn controls the execution of different policy 407 actions. 409 This document also defines a set of variable and constant definitions 410 for use with QoS policies. This concept is not present in the [PCIM] 411 because the purpose of the [PCIM] is to provide a general structure for 412 representing policy rules, conditions and actions. Variable and 413 constant definitions represent specific concepts that have pre-defined 414 semantics. 416 Finally, this document adds a general structure for accommodating PHBs. 417 PHBs are a concept that is specific to DiffServ, and thus are not 418 defined in the [PCIM]. 420 2.2 High-Level Class Hierarchy 422 The following diagram shows how the classes in this document relate to 423 the classes defined in the PCIM. 425 Snir, Ramberg, Strassner, Cohen expires October 2000 8 426 Draft-ietf-policy-qos-info-model-01.txt April 2000 428 (continued from previous page) 430 [unrooted] 431 | 432 +--Policy (abstract, defined in PCIM) 433 | | 434 | +---PolicyGroup (PCIM) 435 | | | 436 | | +---qosPolicyDomain (this document) 437 | | | 438 | | +---qosNamedPolicyContainer (this document) 439 | | 440 | +---PolicyRule (PCIM) 441 | | 442 | +---PolicyCondition (PCIM) 443 | | | 444 | | +---PolicyTimePeriodCondition (PCIM) 445 | | | 446 | | +---VendorPolicyCondition (PCIM) 447 | | | 448 | | +---qosPolicySimpleCondition (this document) 449 | | 450 | +---PolicyAction (PCIM) 451 | | | 452 | | +---VendorPolicyAction (PCIM) 453 | | | 454 | | +---qosPolicyPRAction (this document) 455 | | | 456 | | +---qosPolicyRSVPAction (this document) 457 | | | 458 | | +---qosPolicyRSVPSignalCtrlAction (this document) 459 | | | 460 | | +---qosPolicyRSVPInstallAction (this document) 461 | | | 462 | +---qosPolicyPRTrfcProf (this document) 463 | | 464 | +---qosPolicyRSVPTrfcProf (this document) 465 | | 466 | +---qosPolicyVariable (this document) 467 | | 468 | +---qosPolicyValue (this document) 469 | | | 470 | | +---qosPolicyIPv4AddrValue (this document) 471 | | | 472 | | +---qosPolicyIPv6AddrValue (this document) 473 | | | 474 | | +---qosPolicyMACAddrValue (this document) 475 | | | 476 | | +---qosPolicyStringValue (this document) 477 | | | 479 (continued on next page) 481 Snir, Ramberg, Strassner, Cohen expires October 2000 9 482 Draft-ietf-policy-qos-info-model-01.txt April 2000 484 (continued from previous page) 486 [unrooted] 487 | 488 +--Policy (abstract, defined in PCIM, repeated for convenience) 489 | | 490 | +---qosPolicyValue (this document, repeated for convenience) 491 | | | 492 | | +---qosPolicyBitStringValue (this document) 493 | | | 494 | | +---qosPolicyDNValue (this document) 495 | | | 496 | | +---qosPolicyAttributeValue (this document) 497 | | | 498 | | +---qosPolicyIntegerValue (this document) 499 | | 500 | +---qosPolicyMeter 501 | | 502 | +---qosPolicyPHBSet (this document) 503 | | 504 | +---qosPolicyPHB (this document) 505 | | 506 +--CIM_ManagedSystemElement (abstract, defined in PCIM) 507 | 508 +--CIM_LogicalElement (abstract, defined in PCIM) 509 | 510 +--CIM_System (abstract, defined in PCIM) 511 | 512 +---CIM_AdminDomain (abstract, defined in PCIM) 513 | 514 +---PolicyRepository (PCIM) 516 Snir, Ramberg, Strassner, Cohen expires October 2000 10 517 Draft-ietf-policy-qos-info-model-01.txt April 2000 519 3. Containment Hierarchy 521 In this section, we describe the organization and structure of the QPIM 522 hierarchy. 524 The QPIM consists of two hierarchies: A policy 525 definition hierarchy and a reusable objects repository hierarchy. A 526 particular data tree may contain any number of instances of each 527 hierarchy. Section 3.1 explains the containment and reference model 528 used in the construction of QoS Policy data trees. Section 3.2 529 describes the particular containment hierarchy of the policy definition 530 entity, which is modeled by the qosPolicyDomain class. Section 3.3 531 describes the structure of the reusable objects repository. Further 532 down (section 3.4) we explain the relationships between those entities. 534 3.1. Containment Model 536 The QPIM uses and extends the containment model of [PCIM]. The 537 following paragraphs summarize this containment model. For more detail, 538 please refer to [PCIM]. 540 Conceptually, the QPIM takes the form of a tree hierarchy. To describe 541 the hierarchy using actual instances of model data, we use the term 542 'data tree'. A data tree is simply an arrangement of objects in a tree 543 structure. The data tree starts from a root object node. The data tree 544 itself consists of leaf and non-leaf (i.e., container) nodes. The root 545 node has one or more branch nodes that are either leaf or non-leaf 546 nodes. The tree construction involves placing objects as leaves of 547 other objects while maintaining a strict tree structure. 549 The basic mechanism used for expressing containment is placement of the 550 objects in the data tree. To express the relationship of "container - 551 contained" between a container object and the objects it contains, the 552 contained objects are placed below the container object. 554 Certain elements of the QPIM need a mechanism for an entity to 555 reference objects in a different tree in the containment hierarchy than 556 the tree in which the referencing entity exists. For example, the class 557 policyRule (defined in [PCIM]) is a container of conditions and actions 558 (policyCondition and policyAction classes, defined in [PCIM], or their 559 subclasses, such as those defined in this document). However, the 560 information model should allow the formation of (complex) conditions 561 (and actions), where some of the condition's (and/or action�s) 562 components are referenced remotely. An example of such a remote 563 reference is a reusable condition or a reusable action. Such reusable 564 objects must be referenced remotely because they always reside in a 565 specialized portion of the tree (in this case, in the policyRepository 566 container) that is different from the one where the referencing rule 567 resides. 569 Snir, Ramberg, Strassner, Cohen expires October 2000 11 570 Draft-ietf-policy-qos-info-model-01.txt April 2000 572 To support a unified mechanism for containment of "local" and "remote" 573 objects, [PCIM] introduces the notion of association and aggregation 574 classes. These classes denote some type of dependency relationship that 575 exists between the classes that they are connecting. One type of 576 dependency that can be represented is, of course, containment. 578 [PCIM] recommends that associations and aggregations are also 579 implemented as classes. With respect to containment, an association 580 class represents the act of containment itself. For example, the 581 PolicyConditionInPolicyRule aggregation (defined in [PCIM]) defines 582 that zero or more policy conditions are contained in a given policy 583 rule. 585 In general, containment may be direct or indirect. Direct containment 586 means that when the association or aggregation is instantiated in a 587 repository, the child object will be directly scoped by the container 588 object. Indirect containment means that when the association or 589 aggregation is instantiated in a repository, the child object will 590 instead be referenced by the container object. As an example, if the 591 target repository is a directory, then direct containment is 592 implemented by instantiating the child object as a child node of a 593 container. Similarly, indirect containment would be implemented using 594 an attribute that is a DN (i.e., the DN points to another object). 596 The association classes can (and do) carry the added semantics needed 597 by the information model. For example, internal order of contained 598 objects is information that can be carried on the association objects 599 themselves. This makes the containment model more flexible, since the 600 same object may be used by two containers in different parts of the 601 containment tree. 603 Containment is implemented differently in different data stores. 604 Therefore, the containment tree that is being described is not 605 expressed directly in the information model. Rather, the information 606 model specifies classes and relationships that are used to model 607 entities and relationships between entities that are represented in the 608 containment data model. A mapping of the data specified in an 609 information model to a form that is repository-dependent must also be 610 specified. This is what [PFSCHEMA] and [QOSSCHEMA] do for the [PCIM] 611 and this document, respectively. Please refer to [PCIM] for more 612 information on the details of the association and aggregation class 613 mechanisms. 615 3.2. QoS Domain Containment Hierarchy 617 The entity that represents a single policy hierarchy is called QOS 618 Domain and is modeled by the qosDomain class, which is a derivative of 619 the PolicyGroup class in [PCIM]. 621 Snir, Ramberg, Strassner, Cohen expires October 2000 12 622 Draft-ietf-policy-qos-info-model-01.txt April 2000 624 Figure 1 shows a summary view of the QoS domain containment hierarchy. 625 The text in parenthesis denotes object containment style: either 626 through placement in the data tree (i.e., using a class to form a 627 container in a specific place in the data tree) or indirectly through 628 association or aggregation classes. 630 +---------------+ 631 |qosPolicyDomain| (root) 632 +---------------+ 633 | 634 | +-----------------------+ 635 -->|qosNamedPolicyContainer| (placement) 636 +-----------------------+ 637 | 638 | +----------+ 639 -->|policyRule| (placement) 640 +----------+ 641 | 642 | +------------------------+ 643 |-->|qosPolicySimpleCondition| (via association) 644 | +------------------------+ 645 | 646 | +---------------+ 647 -->|qosPolicyAction| (via association) 648 +---------------+ 650 Figure 1: Qos Domain containment hierarchy 652 3.2.1. Domain Grouping and Nesting 654 QoS policy domains may be grouped together to model multi-domain 655 systems. Here, a domain is a contiguous set of nodes that operate under 656 a common system of administration and provide a common set of services. 657 Grouping may be desired to enhance various administrative tasks, or it 658 may be required by a particular policy application. The grouping 659 strategy (as well as all location-oriented strategies) is left for 660 users/vendors to model based on their unique situations and 661 requirements. This document presents guidelines and recommendations for 662 grouping QoS domains, but specific implementations may use other 663 techniques without violating the integrity and consistency of the QPIM. 665 One way to group QoS policy domains is by creating a common root for 666 several QoS policy domain data tree instances. This can be done by 667 using the PolicyGroup (defined in [PCIM]) class as a root for the 668 multi-domain tree. In this case, all that is needed is to place the 669 appropriate number of qosPolicyDomain (defined in this document) 670 instances under the appropriate policyGroup instance. 672 Snir, Ramberg, Strassner, Cohen expires October 2000 13 673 Draft-ietf-policy-qos-info-model-01.txt April 2000 675 Figure 2 is an example that depicts the ability to provide different 676 classes of service to different organizations within a single 677 enterprise. In this example, the enterprise is represented by an 678 instance of the policyGroup class. The different organizations are each 679 represented by a separate QoS policy domain (which is an instance of 680 the qosPolicyDomain class). Each qosPolicyDomain class is used as a 681 container to hold all of the policies for a given portion of the 682 organization. In Figure 2, this level is represented by the nesting of 683 qosPolicyDomain classes. 685 Each qosPolicyDomain instance serves as a container that contains an 686 ordered list of related QoS policy rules that apply to a different part 687 or function of the domain (e.g., Eastern Sales vs. Western Sales). This 688 grouping is done using instances of the qosNamedPolicyContainer clas. 689 The qosNamedPolicyContainer class would in turn contain either a set of 690 policyRule instances, a set of policyGroup instances (to provide 691 further grouping of policy rules that are scoped by a given 692 qosNamedPolicyContainer), or both. 694 +-------------+ 695 |policyGroup | <------------------- QoS policies for an enterprise 696 +-------------+ 697 | 698 | +---------------+ 699 -->|qosPolicyDomain| <----------- QoS policies for the Sales group 700 +---------------+ 701 | 702 | +---------------+ 703 |-->|qosPolicyDomain| <-------- QoS policies for Western Sales 704 | +---------------+ 705 | | 706 | | +-----------------------+ 707 | |-->|qosNamedPolicyContainer| <--Qos Policies for group 708 | | +-----------------------+ A within Western Region 709 | | 710 | | +-----------------------+ 711 | -->|qosNamedPolicyContainer| <--Qos Policies for group 712 | +-----------------------+ B within Western Region 713 | 714 | +---------------+ 715 -->|qosPolicyDomain| <--------QoS policies for Eastern Sales 716 +---------------+ 717 | 718 | +-----------------------+ 719 |-->|qosNamedPolicyContainer| <--Qos Policies for group 720 | +-----------------------+ C within Eastern Region 721 | 722 | +-----------------------+ 723 -->|qosNamedPolicyContainer| <--Qos Policies for group 724 +-----------------------+ D within Eastern Region 726 Figure 2: Top-level policy data tree example 728 Snir, Ramberg, Strassner, Cohen expires October 2000 14 729 Draft-ietf-policy-qos-info-model-01.txt April 2000 731 The modeling approach used in the previous example is but one possible 732 strategy among many. The information model allows for arbitrary nesting 733 of groups, thus providing the means for modeling both wide and deep 734 hierarchies. 736 3.2.2. Resource Sharing 738 Object instances residing in different parts of the containment tree 739 are independent to each other. That is, there is no cross-referencing 740 among objects located in different QoS policy domains. However, 741 multiple QoS policy domains may still share data by means of 742 referencing reusable objects. These are objects that are placed in a 743 special portion of the repository dedicated to this purpose. In fact, 744 there may be multiple such repositories, each used for collecting a set 745 of related reusable objects. In this document, we will call such 746 repositories reusable-objects repositories. 748 The sharing of global or common objects enhances the interoperability 749 of various policy agents, thus serving the primary goal of this 750 information model. Such commonly used building blocks as important 751 conditions (policyCondition and its subclasses ) and actions 752 (policyAction and its subclasses) can be placed in the reusable-object 753 repository and used by multiple policy rules from multiple domains. 754 Both the [PCIM] and the QPIM do not restrict the number of reusable- 755 object repositories that can be referenced from a single domain. Even a 756 single instance of a policy rule may contain references to objects 757 residing in more than one repository. It is important to note that the 758 QPIM does not dictate a QoS domain-wide scope for reusable objects, so 759 as to keep this concept as general as possible. 761 3.2.3. Placement 763 The purpose of the QPIM is to define a flexible structure of 764 information that does not pre-impose harsh restrictions on building the 765 data tree. Therefore, the QPIM must not contain any hidden assumptions 766 about the placement of particular QoS policy domain hierarchies 767 (including, for that matter, placement of reusable-object repositories 768 as explained in section 3.3 below). Consequently, the QPIM does not 769 require any pre-defined locations for the portion of the data tree that 770 is dedicated to policy. An instance of the global data tree (a 771 corporate directory, for example) may in fact contain several QoS 772 policy domains that exist within the global date tree in various 773 places. Zero or more reusable object-repositories may also be present 774 in the global data tree. 776 In addition, the QPIM does not dictate any standard organization of 777 objects to be controlled via policy, either for QoS policy classes and 778 relationships or for reusable-object repositories that are used by QoS 779 applications. 781 Snir, Ramberg, Strassner, Cohen expires October 2000 15 782 Draft-ietf-policy-qos-info-model-01.txt April 2000 784 The only location/organizational rule that must be followed is: 786 Each QoS policy domain must contain complete policy information, 787 either by containment of objects or by containment of association 788 and/or aggregation objects, that is necessary to describe that 789 policy domain. Reusable objects SHOULD be placed in one or more 790 reusable-object repositories and referenced by one or more objects 791 that exist in the QoS policy domain, as appropriate. 793 3.2.4. Named Policy Containers 795 A QoS policy domain is a container of (named) QoS Policy Containers, as 796 explained above. The information model class representing named QoS 797 policy containers is the qosNamedPolicyContainer class. This class 798 extends the policyGroup class, which is defined in [PCIM]. 800 A (non-empty) qosNamedPolicyContainer holds an unordered list of 801 policyRules. There are two levels of priority that the QPIM specifies 802 that can be used to determine the order of execution of QoS policy 803 rules. At the highest level, we can define an unordered set of policy 804 containers, each of which has a priority attribute (called qpPriority). 805 This property is used to order the top level of the containment 806 hierarchy. Within a given containment level, we can then use the 807 Priority attribute of the policyRule class to establish an order of 808 which policy rule in a given container executes next. Figure 3 shows a 809 simple example of the ordering process. Section 4 describes policy 810 rules in more detail. 812 +---------------+ 813 |qosPolicyDomain| 814 +---------------+ 815 | 816 | +--------------+ 817 |-->|policyRule A | 818 | | Priority=19 | 819 | +--------------+ 820 | 821 | +-----------------------+ +-------------+ 822 |-->|qosNamedPolicyContainer|--->|policyRule C | 823 | | qpPriority=5 | | | Priority=7 | 824 | +-----------------------+ | +-------------+ 825 | | 826 | +-------------+ | +-------------+ 827 -->|policyRule B | ->|policyRule D | 828 | Priority=3 | | Priority=2 | 829 +-------------+ +-------------+ 831 Figure 3. Example Ordering for a QoS Policy Decision 833 Here, the ordering is A, then C, then D, then B. This is because the 834 qpPriority of the qosNamedPolicyContainer is higher than B, so each of 835 its contained rules are executed (in order) before B. 837 Snir, Ramberg, Strassner, Cohen expires October 2000 16 838 Draft-ietf-policy-qos-info-model-01.txt April 2000 840 As implied by the class name, each instance of the 841 qosPolicyNamedContainer class MUST be assigned a name that is unique 842 within its given QoS policy domain. A given policy container must 843 belong to (i.e.: contained in) a single QoS policy domain. Sharing of 844 policy containers among QoS policy domains is not possible because of 845 the dependency of the decision strategy on the relative priority within 846 each QoS policy domain. 848 The ability to "divide" a given QoS policy domain's policy rules among 849 a set of policy containers provides a flexible framework to realize a 850 fine-grained administrative (or functional) structure. As the example 851 in figure 2 illustrates, it makes sense to divide policies for the 852 sales organization into two regional containers: Western and Eastern. 853 This enables a change in policies for one region to not affect the 854 policies currently in place for the other region. 856 While this strategy should meet most needs, taking a slightly different 857 approach can provide additional flexibility. This approach is 858 illustrated by looking at how PHBs are modeled (see section 6). In this 859 approach, a different set of PHBs can be assigned to different policy 860 containers. This has the effect of modifying the interpretation of the 861 same PHBs by each policy container. 863 Each policy container is assigned a "match strategy". This is defined 864 in the qpNamedPolicyRuleMatchMethod attribute of the 865 qosPolicyNamedContainer class. This attribute defines how to interpret 866 the order of the QoS policy rules that it contains. For example, a 867 FirstMatch strategy means that the rules will be "matched" according to 868 ascending order of their Priority attribute. Decision strategies are 869 explained in section 5. 871 Policy container can be nested. A policy container may contain policy 872 rules (PolicyRule [PCIM]) or named policy containers. A particular 873 data tree, then, can be constructed as a deep hierarchy, if the 874 designers of the policy system deem it desirable. 876 3.2.5. Policy Rules 878 Each qosNamedPolicyContainer holds a set of policy rules (or possibly 879 additional policy containers, which could be policyGroups or 880 qosNamedPolicyContainers, that contain policy rules). QoS policy rules 881 are modeled by the [PCIM] class policyRule. 883 The semantics of a policy rule is, in essence, a conditional imperative 884 statement in the form 'if then '. Applying a rule 885 means evaluating its condition and, depending on the truth value of 886 the condition, to execute the action or do nothing. Evaluating a 887 condition is known as 'matching the rule', an expression we'll be using 888 in later sections of this document. 890 Snir, Ramberg, Strassner, Cohen expires October 2000 17 891 Draft-ietf-policy-qos-info-model-01.txt April 2000 893 A given policy rule MUST belong to one (and only one) 894 qosNamedPolicyContainer. This restriction is necessary because the 895 units of reusability are, in reality, the policy condition and action 896 terms that comprise a policy rule (as opposed to the policy rule 897 itself). This is because a policy rule is a composite object, made up 898 of several objects, but SHOULD be viewed as a coherent statement. It is 899 believed that allowing a policy rule to belong to more than one policy 900 container would decrease or even destroy its coherence. For example, 901 the rule itself is "aware" of its position inside its policy container, 902 so if we wanted to share a rule among many containers we'd have to 903 remove this knowledge from the rule. The notion of ordering of rules is 904 so essential to the concept of policy that removing it from the rule 905 also renders the rule less expressive, making policy modeling a more 906 difficult job. Furthermore, there are other important attributes that 907 are unique to the rule's specific placement inside a policy group 908 and/or a policy domain. For example, the DSCP values (section 6) that 909 define how a flow is colored (which in turn define the set of QoS 910 policy actions that should be invoked by the rule) may be interpreted 911 differently in different QoS policy domains (or policy containers). 912 These examples show that the modeling of shared rules is inappropriate 913 for the QPIM. 915 The order of the policy rules inside a container is based on the 916 relative values of the Priority attribute of each of the policyRules 917 (please see [PCIM] for more information). The enforcement of policy 918 rules also depends on particular settings belonging to the group. The 919 match strategy to be applied to the policy rules contained in a given 920 container is defined in the policyRuleMatchMethod attribute of the 921 qosNamedPolicyContainer object. Note that actions taken on packets may 922 use a different mechanism. For example, a DSCP value can be set 923 directly using the qpSetDSCPValue attribute of the qosPolicyPRAction 924 class. However, this class could also define a set of token bucket 925 parameters using the qpTrfcProf attribute. This references a traffic 926 profile (represented by the qosPolicyPRTrfcProf class) that carries the 927 policer or shaper rate values to be enforced on a flow or a set of 928 flows. 930 3.2.6. Conditions and Actions 932 A policy rule is a composite object, as mentioned above. The most 933 important components of a rule are the conditions and actions it 934 contains. A condition is a Boolean expression that is evaluated to see 935 if the rule should be applied. An action is a specification of one or 936 more QoS operations enforced on the designated set of flows that MUST 937 be done if the given policy rule is to be applied. Actions are applied 938 if the condition is TRUE (see [PCIM] for more details). 940 Snir, Ramberg, Strassner, Cohen expires October 2000 18 941 Draft-ietf-policy-qos-info-model-01.txt April 2000 943 3.2.7. Data Tree Example 945 The following example illustrates the hierarchical nature of the QoS 946 Policy data tree. Each organizational entity is related to a specific 947 type of class, which is shown in parentheses. 949 There are two QoS policy domains in this example, grouped together 950 under the same root (domain grouping). The QoS policy domains are: 952 1. EastCoast (qosPolicyDomain) 953 2. WestCost (qosPolicyDomain) 955 Each of these two QoS policy domains has its own PHB set. The EastCoast 956 domain has 2 named policy containers. The first deals only with ERP 957 traffic and the second handles all other traffic: 959 1. EastCoast (qosPolicyDomain) 960 1.1. ERP (qosNamedPolicyContainer) 961 1.2. General (qosNamedPolicyContainer) 963 The WestCoast domain has 3 named policy container. The first deals only 964 With ERP flows, the second deals with VoIP, and the third with all 965 other traffic: 967 2. WestCoast 968 2.1. ERP (qosNamedPolicyContainer) 969 2.2. VoIP (qosNamedPolicyContainer) 970 2.3. General (qosNamedPolicyContainer). 972 Each one of the qosNamedPolicyContainer entries can contain a 973 prioritized rule set. For example, the WestCoast ERP group contains the 974 rules relevant to ERP applications administrated by the west coast 975 domain administrator. 977 We see from the above structure that this structure provides the 978 administrator with a great deal of flexibility. For example, similarly 979 named containers, represented by the ERP and General 980 qosNamedPolicyContainers, can reuse common policy conditions and 981 actions. However, they are implemented as physically different 982 containers to enable the administrator to administrate them 983 according to their own domain-specific needs. 985 3.3. Reusable-Object Repositories 987 Reusable objects are objects that can be referred by (hence "used by") 988 other objects. For example, the reference could be accomplished by 989 allocating an attribute on the referencing object that contains the 990 location of the referenced object. 992 Snir, Ramberg, Strassner, Cohen expires October 2000 19 993 Draft-ietf-policy-qos-info-model-01.txt April 2000 995 The concept of reusable-object repositories is introduced by [PCIM] for 996 the purpose of allowing data tree constructors to share data among many 997 users. This document enhances this concept to model the needs of QoS 998 policy rules. 1000 A reusable-object repository hierarchy is rooted in an instance of the 1001 policyRepository class (defined in [PCIM]). Individual reusable-object 1002 repositories are named containers for reusable objects. Note that 1003 [PCIM] allows arbitrary nesting of reusable-object repositories. This 1004 can be conceptually thought of as a repository of repositories. 1006 Each named reusable-object repository is a container of "reusable 1007 objects" that can be used for a common purpose, and/or are administered 1008 in a common way. A reusable object MUST have a unique name within the 1009 the container that it resides in. 1011 The complete containment model for the reusable-object repositories, 1012 as well as detailed description of the various mechanisms for 1013 constructing and maintaining such repositories, is described in detail 1014 in [PCIM]. 1016 Anywhere in the QoS Policy information model, where a reference to an 1017 object can be made (a 'reference' type attribute), this reference 1018 SHOULD point to a reusable object in a reusable-object repository. 1020 Common candidates for reusability are named instances of these classes 1021 and their derivatives: 1023 - qosPolicyVariable 1024 - qosPolicyValue 1025 - qosPolicySimpleCondition 1026 - policyAction 1027 - qosPolicyMeter, QoSPolicyPRTrfcProf and QoSPolicyRSVPTrfcProf 1028 - QoSPolicyPHBSet 1030 Throughout this document, we point out the possible use of repository 1031 and repository objects, wherever this is appropriate. 1033 3.4. Relationships Between QoS Domains and Repositories 1035 As explained above, a QoS policy domain contains within it groups of 1036 policy rules. A policy rule can contain ordered lists of conditions and 1037 actions. The conditions and actions may be reusable object that reside 1038 in reusable objects repositories. 1040 Many references to reusable objects may be made from the rules of a 1041 given QoS policy domain. Those references need not be all pointing to 1042 the same reusable-object repository; even e single rule may contain 1043 references to reusable objects that reside in different repositories. 1045 Snir, Ramberg, Strassner, Cohen expires October 2000 20 1046 Draft-ietf-policy-qos-info-model-01.txt April 2000 1048 The maintenance of the policy system is made somewhat more complicated 1049 due to the flexibility of the reference model. For example, it is more 1050 difficult to prevent "dangling" references to repositories that are no 1051 longer present. Schema designers are encouraged to pay extra attention 1052 to this problem and exercise any technique available from their 1053 implementation platform to maintain integrity of their data trees. 1054 [PCIM] discusses this issue as well. 1056 4. Constructing a QoS Policy Rule 1058 A policy rule modeled in [PCIM] represents the "If Condition then 1059 Action" semantics associated with a policy. The QPIM extends these 1060 semantics by refining the type of policy conditions and actions that 1061 can be represented, extending the use of containers, and providing 1062 additional features (nesting of rules, defining extensible rule 1063 decision strategies, linking to PHBs, and providing pre-defined 1064 variables and constants that can be used to express the required 1065 semantics of QoS policy rules in more detail. 1067 The following sections describe these characteristics in more detail. 1069 4.1 Policy Rule Structure 1071 A policy rule has the following attributes (defined in [PCIM]) that can 1072 be used to provide important semantics for QoS policy applications; 1073 these are in addition to the attributes which serve as a key and 1074 provide its name: 1076 1. An Enable flag that indicates whether a policy rule is 1077 administratively enabled, administratively disabled, or enabled 1078 for debug mode. 1079 2. A set of conditions (defined in either the 1080 PolicyConditionInPolicyRule or PolicyConditionInPolicyRepository 1081 aggregation) 1082 3. A flag indicating whether this condition is in disjunctive or 1083 conjunctive normal form 1084 4. An (optionally ordered) list of actions (defined in either the 1085 PolicyActionInPolicyRule or PolicyActionInPolicyRepository 1086 Aggregation) 1087 5. A priority value, defining the priority of this rule relative to 1088 other rules in the same container 1089 6. The attribute named �mandatory�, which is used to define whether 1090 the evaluation of conditions (and the subsequent execution of 1091 actions if the conditions evaluate to TRUE) is mandatory or not 1092 7. A SequencedActions attribute that defines how to execute the 1093 actions if the condition is TRUE 1094 8. An array of PolicyRoles attributes, that define the roles or 1095 role-combinations that are used in this rule 1096 9. A RuleUsage attribute, that contains a description of how this 1097 rule should be used 1099 Snir, Ramberg, Strassner, Cohen expires October 2000 21 1100 Draft-ietf-policy-qos-info-model-01.txt April 2000 1102 The Boolean condition is used to evaluate if the set of actions should 1103 be performed on a network flow by matching the network flow attributes 1104 against the condition. QoS-specific conditions SHOULD be formed from 1105 using either the qosPolicySimpleCondition class defined in this 1106 document and/or the policyTimePeriodCondition class defined in [PCIM] 1107 (or their subclasses, of course). Note that QoS-specific conditions MAY 1108 be mixed with more generic conditions that are not derived from either 1109 of these classes. However, these non-QoS-specific conditions SHOULD be 1110 derived from the policyCondition class (defined in [PCIM]). The 1111 combination of individual conditions in a policy rule is defined in 1112 [PCIM] using the ConditionInPolicyRule class. 1114 Each action in the list is modeled by an action derived from the 1115 PolicyAction class. The ActionInPolicyRule class defines the order in 1116 which policy actions are performed. 1118 The interpretation of a policy rule in regard to a given network flow 1119 may be expressed as follows: 1121 If the rule is enabled and the Boolean expression is evaluated to 1122 TRUE, then use the Action list to extract the prescribed treatment 1123 for this flow. 1125 The rest of this section describes the components of the policyRule 1126 class and their relationships to the other classes defined in this 1127 schema. 1129 4.2 QoS Policy Conditions 1131 A policy rule modeled in [PCIM] represents the "If Condition then 1132 Action" semantics associated with a policy. A condition is represented 1133 as either an ORed set of ANDed conditions or an ANDed set of ORed 1134 conditions. Individual conditions may either be negated (NOT C) or 1135 not negated (C). The actions specified by a policy rule are to be 1136 performed if and only if the policy rule condition evaluates to TRUE. 1138 Many conditions in policy rules, from a networking perspective, can be 1139 modeled as Filters. Filters are not modeled directly in either the QPIM 1140 or the PCIM (i.e., no Filter class is defined). However, the filter 1141 concept is central in the QoS Policy data model, and is modeled in the 1142 Network Model of DEN and used in the companion QoS Device information 1143 model draft [QOSDEV]. 1145 The semantics of an individual condition is not specified in [PCIM]. 1146 This document provides semantics for common QoS policy conditions. For 1147 example, conditions such as: "If the source IP address of the flow 1148 belongs to 10.1.x.x subnet" as well as "If the IP protocol number of 1149 the flow equals the TCP protocol number" are modeled in this document. 1151 Snir, Ramberg, Strassner, Cohen expires October 2000 22 1152 Draft-ietf-policy-qos-info-model-01.txt April 2000 1154 The qosPolicySimpleCondition class models individual conditions. This 1155 class refines the basic structure of the policyCondition class defined 1156 in [PCIM] by using the triplet , and to 1157 form a condition. 1159 The variable specifies the attribute of a flow that should be matched 1160 when evaluating the condition. A set of predefined variables that cover 1161 the basic network attribute are introduced to foster interoperability. 1162 The list cover layer 3 IP attribute such as IP network addresses, 1163 protocols and ports, as well as a set of layer 2 attributes and higher 1164 level attributes such as application and user identity. 1166 The variable is matched against a value to produce the Boolean result. 1167 In the first example above, a source IP address variable is matched 1168 against a 10.1.x.x subnet value. The operator specifies the type of 1169 relation between the variable and the value evaluated in the condition. 1170 Operators should model the 'belong to' and 'equal' relations in the 1171 examples above. In many cases, a generic 'match' operator can be used, 1172 and the interpretation of the relation between the variable and value 1173 is implied by the value itself. For example, the variable source IP 1174 address can be matched to an IP address, where the 'equal' relation is 1175 implied, to a hostname in which the 'resolve to' relation is implied, 1176 or to a subnet address in which 'belongs to' relation is implied. 1178 4.2.1 Reusable vs. Ad-Hoc Conditions 1180 This schema enables the reuse of simple conditions by placing them in a 1181 common portion of the policy information tree (called the reusable- 1182 object repository). In order for a simple condition to be a member of 1183 this repository, it must carry a unique name. 1185 A qosPolicySimpleCondition can either directly contain a value and a 1186 variable, or can reference either one or both of them if they are kept 1187 in a reusable-object repository. 1189 Simple condition composition must enforce the following type 1190 conformance rule: The qpValueTypes property of the variable must be 1191 compatible with the value class name. 1193 The QPIM defines four different ways to compose a simple condition 1194 through the combination of representations of variables and values. The 1195 following combinations of representing a simple condition by references 1196 and containment are possible: 1198 Variable representation 1200 1. The class qosPolicyVariable may be contained in the 1201 qosPolicySimpleCondition instance. 1203 2. The class qosPolicyVariable may be referenced from the 1204 qosPolicySimpleCondition instance (Reusable variable) 1206 Snir, Ramberg, Strassner, Cohen expires October 2000 23 1207 Draft-ietf-policy-qos-info-model-01.txt April 2000 1209 Value representation 1211 1. The qosPolicyValue class may be contained in the 1212 qosPolicySimpleCondition class. 1214 2. The qosPolicyValue class may be referenced from the 1215 qosPolicySimpleCondition instance. This allows reusing the 1216 qosPolicyValue object, which could be named and considered a named 1217 constant. 1219 4.2.2. Using Simple Conditions 1221 In most cases, the use of the qosPolicySimpleCondition class is 1222 sufficient for the definition of a condition for a policyRule. A simple 1223 condition can be added to a policyRule in two ways: 1225 1. A direct attachment of an instance of the condition to the 1226 ConditionInPolicyRule instance. In this case, we call this an 1227 "ad-hoc" simple condition. This method allows the creation of a 1228 "private" simple condition, meaning that this instance of the 1229 condition can't be referenced by any other policy rule, and 1230 therefore is not reusable. However, since it embeds the condition 1231 directly in the ConditionInPolicyRule instance, it eliminates the 1232 extra access(es) required to fetch each of the condition elements 1233 that are refernced by pointers. 1235 2. An indirect reference to an instance of a condition that resides in 1236 a reusable-object repository. This is called a reusable condition. 1237 This method allows the sharing of conditions by multiple policy 1238 rules. 1240 4.2.3. Composing Complex Conditions 1242 A complex condition consists of groups of simple conditions (i.e., 1243 instances of either the policyCondition and/or the 1244 qosPolicySimpleCondition classes) that are combined in either 1245 conjunctive or disjunctive normal form (as defined in [PCIM]). 1247 A complex condition is modeled by the mechanisms supplied in the 1248 following PCIM attributes: 1250 1. The ConditionListType attribute of the policyRule, which 1251 is a boolean expression type that defines whether the simple 1252 condition is in conjunctive or disjunctive normal form. 1253 2. The PolicyConditionInPolicyRule aggregation class that does three 1254 things: associates conditions to a particular policy rule, defines 1255 whether the condition is negated or not, and partitions the 1256 referenced conditions into one or more groups. For more details, 1257 please see [PCIM], section 6.3. 1259 Snir, Ramberg, Strassner, Cohen expires October 2000 24 1260 Draft-ietf-policy-qos-info-model-01.txt April 2000 1262 4.3 Simple Condition Operator 1264 The QoS policy simple condition includes the qpOperator property, 1265 Which specifies the type of relation between the variable and the value 1266 evaluated in the condition. In many cases, a generic 'match' operator 1267 can be used, and the interpretation of the relation between the 1268 variable and value is implied by the value itself. For example, the 1269 variable source IP address can be matched to an IP address, where the 1270 'equal' relation is implied, to a hostname in which the 'resolve to' 1271 relation is implied, or to a subnet address in which 'belongs to' 1272 relation is implied. 1274 The QPIM defines a single operator, "match", that models the most 1275 generic relation: that of being equal or belonging to. 1277 4.4 QoS Policy Variables 1279 QoS Policy Variables are used for building individual conditions, as 1280 defined in section 4.2. The variable specifies the attribute of a flow 1281 that should be matched when evaluating the condition. 1283 Not every combination of a variable and a value creates a meaningful 1284 condition. For example, a source IP address variable can not be matched 1285 against a value that specifies a port number. The QPIM defines a set of 1286 variables that can be used to model common QoS policy conditions, and 1287 assigns appropriate semantics for each. Each type of variable 1288 inherently selects the set of value types that it can be matched 1289 against (i.e. a value that could be compared and evaluated to a Boolean 1290 expression). 1292 A variable may also limit, or constrain, the set of values within a 1293 particular value type that can be matched against it in a condition. 1294 This may be viewed as a second level of integrity checking. For 1295 example, a variable representing the source-port must limit the set of 1296 values that it can assume to the valid range of integers that 1297 correspond to legal source-port values (which is 0-65535). Integers 1298 outside this range can not be matched to this variable. Thus, it is not 1299 enough to say that the data type of the source-port variable is an 1300 integer � we also need to ensure that the value to be tested is within 1301 a valid range of integers. 1303 The QPIM defines three important attributes that characterize each of 1304 the variables that it defines: 1306 1. The property qpVariableName of the QosPolicyVariable class defines 1307 the well-known name used for logical binding of all variables that 1308 are defined in this document. 1309 2. The qpValueTypes is the list of value classes that could be 1310 matched to this variable. 1311 3. The qpValueConstraints defines a list of constraint on the 1312 variable (i.e., values that the Variable must match). 1314 Snir, Ramberg, Strassner, Cohen expires October 2000 25 1315 Draft-ietf-policy-qos-info-model-01.txt April 2000 1317 The combination of these three attributes provide a consistent and 1318 extensible set of meta-data that define the semantics of variables that 1319 are used to form QoS conditions. For example: 1321 - The qpVariableName can be used to identify common processing rules 1322 for a variable having a specific name. 1323 - The qpValueTypes attribute can be used to ensure that only proper 1324 classes are used as operators. For example, the source-port 1325 variable will not include the QosPolicyIPv4AddrValue class, since 1326 source ports have different semantics than IP addresses. However, 1327 it will include the QosPolicyIntegerValue class name. 1328 � The qpValueConstraints attribute ensures that variable-specific 1329 semantics are enforced (e.g., the source-port variable may include 1330 a constraint reference to a value object defining the integer range 1331 0..63535). 1333 4.4.1. Variable Binding 1335 For the QoS Policy schema to be interoperable, different policy 1336 management systems and policy servers must instantiate the same 1337 variables with identical values (in the same evaluation operation). 1338 While different policy servers may use a different binding mechanism, 1339 the binding logic must result in an identical instantiation. 1341 Each variable defined in the QoS policy repository must be bound to a 1342 logical entity such as a specific field in the IP header, application 1343 unique identifier or an application-specific parameter. 1345 When a policy server attempts to evaluate an expression containing 1346 variables, it must instantiate the variables. To instantiate a 1347 variable, that variable must be bound to a specific value (or values, 1348 depending on its type category) and associated with a logical entity. 1349 For example, in the expression 'source-port == 80', the variable 1350 'source-port' must be instantiated to a value and logically associated 1351 with the packet header field containing the source port number, for the 1352 expression to be evaluated. 1354 If, in this example, the variable source-port is bound to a value of 1355 '80', then the expression is evaluated to TRUE for each packet that the 1356 source port number in the IP header field equals 80. Otherwise it is 1357 evaluated to FALSE. 1359 4.4.2. Pre-Defined Variables 1361 The purpose of this section is to explain the need and define the 1362 relationship of standard, frequently used variables with their logical 1363 entities. Pre-defined variables are necessary for ensuring 1364 interoperability among policy servers and policy management tools from 1365 different vendors. 1367 Snir, Ramberg, Strassner, Cohen expires October 2000 26 1368 Draft-ietf-policy-qos-info-model-01.txt April 2000 1370 For example, different policy servers may have to evaluate the same 1371 policy rule. If each policy server uses a common set of variables, this 1372 helps to abstract the condition term such that its evaluation can be 1373 performed in the same way. 1375 The QoS Policy information model specifies a set of pre-defined 1376 variables to support a set of fundamental QoS terms that are commonly 1377 used to form conditions. Examples of these include IP header field 1378 values, user information, applications, and others. A pre-defined 1379 variable MUST always have the same name and binding semantics. For 1380 example, a given pre-defined variable should be bound to the same 1381 logical entity by all client systems (typically policy devices). 1382 Similarly, the pre-defined variable should be stored in the reusable- 1383 object repository to enable reuse and sharing of the pre-defined 1384 variable. 1386 All standard variable names are case insensitive and do not include 1387 spaces or other non-standard characters to promote ease of use. 1389 The implementers of client systems that map the QPIM to a specific 1390 repository-based implementation MUST provide binding methods to bind 1391 pre-defined variables according to the semantics specified in this 1392 section. 1394 Following is a table that defines the predefined variable names and 1395 their binding. The table indicates which fields are checked in actual 1396 filters used in provisioning policies as well as in RSVP signaling 1397 messages. 1399 +-----------------+---------------------------------------------------+ 1400 |Variable name | Logical binding | 1401 +-----------------+---------------------------------------------------+ 1402 | SourceIP | The source IP address of the flow. Compared to the| 1403 | | source IP header field, or the sender address in | 1404 | | the RSVP Filter spec object [RSVP]. | 1405 +-----------------+---------------------------------------------------+ 1406 | SourcePort | The source Port of a UDP/TCP flow. Compared to the| 1407 | | source port field in the TCP/UDP header, or the | 1408 | | sender port in the RSVP Filter spec object [RSVP].| 1409 +-----------------+---------------------------------------------------+ 1410 | DestinationIP | The destination IP address of the flow. Compared | 1411 | | to the destination IP header field, or the session| 1412 | | address in the RSVP SESSION object [RSVP]. | 1413 +-----------------+---------------------------------------------------+ 1414 | DestinationPort | The destination Port of a UDP/TCP flow. Compared | 1415 | | to the destination port field in the TCP/UDP | 1416 | | header, or the session port in the RSVP SESSION | 1417 | | object [RSVP]. | 1418 +-----------------+---------------------------------------------------+ 1420 (Table continued in next page) 1422 Snir, Ramberg, Strassner, Cohen expires October 2000 27 1423 Draft-ietf-policy-qos-info-model-01.txt April 2000 1425 (Table continued from the previous page) 1427 +-----------------+---------------------------------------------------+ 1428 |Variable name | Logical binding | 1429 +-----------------+---------------------------------------------------+ 1430 | IPProtocol | The IP protocol number. Compared to the protocol | 1431 | | number in the IP header field or to the IP | 1432 | | protocol in the RSVP SESSION object [RSVP]. | 1433 +-----------------+---------------------------------------------------+ 1434 | ToS | The ToS variable is bound to the IP header ToS | 1435 | | byte. | 1436 +-----------------+---------------------------------------------------+ 1437 | DSCP | The DSCP variable is bound to the IP header DSCP | 1438 | | byte or to DCLASS RSVP object. | 1439 +-----------------+---------------------------------------------------+ 1440 | DestinationMAC | The destination MAC address variable is bound the | 1441 | | frame destination MAC address. | 1442 +-----------------+---------------------------------------------------+ 1443 | SourceMAC | The source MAC address variable is bound the frame| 1444 | | source MAC address. | 1445 +-----------------+---------------------------------------------------+ 1446 | 8021QID | The VLAN ID as represented in the 802.1Q field of | 1447 | | the header. | 1448 +-----------------+---------------------------------------------------+ 1449 | Snap | The snap protocol variable is bound to protocol | 1450 | | type carried over SNAP encapsulation. | 1451 +-----------------+---------------------------------------------------+ 1452 | Ethertype | The ethertype variable is bound to the frame | 1453 | | header ethertype value. | 1454 +-----------------+---------------------------------------------------+ 1455 | Ssap | The source sap variable is bound the frame header | 1456 | | field containing the source SAP. | 1457 +-----------------+---------------------------------------------------+ 1458 | Dsap | The destination sap variable is bound the frame | 1459 | | header field containing the destination SAP. | 1460 +-----------------+---------------------------------------------------+ 1461 | Application | The ID of the application that generated the flow.| 1462 +-----------------+---------------------------------------------------+ 1463 | User | The ID of the user that initiated the flow, or is | 1464 | | designated as the flow owner. | 1465 +-----------------+---------------------------------------------------+ 1467 Table 2. Pre-defined Variable Names and Their Bindings 1469 The definition of each predefined variable includes a standard name and 1470 the allowed value types, i.e. the variable's qpValueTypes property. 1472 Following is a table of variable names and their allowed class types. 1474 Snir, Ramberg, Strassner, Cohen expires October 2000 28 1475 Draft-ietf-policy-qos-info-model-01.txt April 2000 1477 +-----------------+---------------------------------------------------+ 1478 |Variable name | Allowed class types | 1479 +-----------------+---------------------------------------------------+ 1480 | SourceIP | qosPolicyIPv4AddrValue, qosPolicyIPv6AddrValue | 1481 +-----------------+---------------------------------------------------+ 1482 | SourcePort | qosPolicyIntegerValue | 1483 +-----------------+---------------------------------------------------+ 1484 | DestinationIP | qosPolicyIPv4AddrValue, qosPolicyIPv6AddrValue | 1485 +-----------------+---------------------------------------------------+ 1486 | DestinationPort | qosPolicyIntegerValue | 1487 +-----------------+---------------------------------------------------+ 1488 | IPProtocol | qosPolicyIntegerValue | 1489 +-----------------+---------------------------------------------------+ 1490 | ToS | qosPolicyIntegerValue, qosPolicyBitStringValue | 1491 +-----------------+---------------------------------------------------+ 1492 | DSCP | qosPolicyIntegerValue, qosPolicyBitStringValue | 1493 +-----------------+---------------------------------------------------+ 1494 | DestinationMAC | qosPolicyMACAddrValue | 1495 +-----------------+---------------------------------------------------+ 1496 | SourceMAC | qosPolicyMACAddrValue | 1497 +-----------------+---------------------------------------------------+ 1498 | 8021QID | qosPolicyIntegerValue, qosPolicyBitStringValue | 1499 +-----------------+---------------------------------------------------+ 1500 | Snap | qosPolicyIntegerValue | 1501 +-----------------+---------------------------------------------------+ 1502 | Ethertype | qosPolicyIntegerValue | 1503 +-----------------+---------------------------------------------------+ 1504 | Ssap | qosPolicyIntegerValue | 1505 +-----------------+---------------------------------------------------+ 1506 | Dsap | qosPolicyIntegerValue | 1507 +-----------------+---------------------------------------------------+ 1508 | Application | qosPolicyDNValue, qosPolicyStringValue, | 1509 | | qosPolicyAttributeValue | 1510 +-----------------+---------------------------------------------------+ 1511 | User | qosPolicyDNValue, qosPolicyStringValue, | 1512 | | qosPolicyAttributeValue | 1513 +-----------------+---------------------------------------------------+ 1515 Table 3. Allowed Variable Names and Their Default Class Types 1517 Note: For Value type definition, check the QoS Policy Value section. 1519 Snir, Ramberg, Strassner, Cohen expires October 2000 29 1520 Draft-ietf-policy-qos-info-model-01.txt April 2000 1522 4.5 QoS Policy Value 1524 This abstract class qosPolicyValue is used for defining values and 1525 constants used in policy conditions. Different value types are derived 1526 from this class and represent the various attributes required. 1527 Extensions of the qosPolicValue class, defined in this document 1528 provide a list of values for representing the basic network attribute. 1529 Values can be used to represent constants as named values. Named values 1530 could be kept in a repository to be reused by multiple conditions. 1531 Examples of constants include well-known ports, well-known protocol, 1532 server addresses, and other similar concepts. 1534 The QoS Policy value classes define 3 types of basic values: scalars, 1535 ranges and sets. For example, a well-known port number could be defined 1536 using the qosPolicyIntegerValue, defining a single value (80 for HTTP) 1537 a range (80-88) or a set (80, 82, 8080). For details, please see the 1538 class definition for each value type. 1540 The QoS policy information model provide the following classes, all of 1541 them extending the QoSPolicyvalue: 1543 General: 1544 qosPolicyStringValue 1545 qosPolicyIntegerValue, 1546 qosPolicyBitStringValue, 1547 qosPolicyDNValue, 1548 qosPolicyAttributeValue. 1550 Layer 3 Network values: 1551 qosPolicyIPv4AddrValue, 1552 qosPolicyIPv6AddrValue. 1554 Layer 2 Network values: 1555 qosPolicyMACAddrValue. 1557 For details, please see the class definition section of each value. 1559 4.6. PolicyTimePeriodCondition 1561 The QoS Policy Information model uses the policyTimePeriodCondition 1562 class (defined in [PCIM]) to define time based QoS policy rules. For 1563 details, please see [PCIM], section 6.5. 1565 4.7. Actions 1567 The QoS Policy schema defines actions to control QoS enforcement in 1568 both the Integrated-Service model as well as the Differential service 1569 model. Two types of actions are provided: Signaling and Provisioning 1570 actions. 1572 Snir, Ramberg, Strassner, Cohen expires October 2000 30 1573 Draft-ietf-policy-qos-info-model-01.txt April 2000 1575 Signaling actions are used to provide policy control on RSVP 1576 requests. Provisioning actions are used to directly control the data 1577 traffic, regardless of any out-of-band signaling. 1579 A policy rule may aggregate zero or more policy actions. A QoS policy 1580 rule extends this definition to include 0..n provisioning actions and 1581 0..m signaling actions, each defined by an object or objects describing 1582 the action(s) to perform. Actions are ordered (as opposed to rules, 1583 which are prioritized). The order of actions is specified in [PCIM]. 1585 The property SequencedActions in the aggregating instance of defines 1586 whether a specified action order is required, recommended, or of no 1587 significance. 1589 Ordering semantics depend on how actions are represented. If actions 1590 are represented as separate objects, the PolicyActionInPolicyRule 1591 aggregation can be used to express an order. In this case, three 1592 attributes are used: 1594 - ContainingRule, which contains a reference to a policyRule that 1595 contains one or more policyActions 1596 - ContainedAction, which contains an object reference to a 1597 policyAction contained by one or more policyRules 1598 - ActionOrder, which is an unsigned integer 'n' that indicates the 1599 relative position of an action in the sequence of actions that are 1600 associated with a given policy rule. When 'n' is a positive 1601 integer, it indicates a place in the sequence of actions to be 1602 performed, with smaller integers indicating earlier positions in 1603 the sequence. The special value '0' indicates "don't care". If 1604 two or more actions have the same non-zero sequence number, they 1605 may be performed in any order, but they must all be performed at 1606 the appropriate place in the overall action sequence. 1608 For actions defined explicitly in a subclass of policyRule, the 1609 ordering mechanism must be specified in the subclass definition. Note 1610 that QPIM does not define any policyRule subclasses. Instead, the QPIM 1611 defines subclasses of policyCondition and policyAction to extend the 1612 semantics of these classes. 1614 Provisioning and signaling actions can be intermixed in a QoS policy 1615 rule. Policy consumers (such as PDPs) MAY separate the actions into 1616 separate lists, but MUST respect the internal order of the specified 1617 actions. 1619 4.7.1 Provisioning Actions 1621 QoS Policy provisioning actions model traffic conditioner elements, as 1622 specified in [DIFF-SERV-ARCH]. Actions model meters, markers, shapers 1623 and droppers. 1625 Snir, Ramberg, Strassner, Cohen expires October 2000 31 1626 Draft-ietf-policy-qos-info-model-01.txt April 2000 1628 4.7.1.1 Meters 1630 Meters measure the temporal properties of the stream of packets 1631 selected by a classifier against a traffic profile. Meters are modeled 1632 by the QosPolicyMeter class. A meter can be shared between different 1633 policy rules. If this is desired, then the meter SHOULD reside in a 1634 reusable-object repository. This enables it to be referenced by all 1635 policy rules that want to share it. 1637 The property qpMeter is used to hold a reference to a (reusable) meter 1638 that is kept in a reusable-object repository. The qpMeterScope property 1639 specifies whether the meter should measure flows matching the rule 1640 condition per interface, per device or per flow. A per flow meter 1641 conceptually creates a new meter for each flow, measuring each flow 1642 against the profile. A per interface meter measures the aggregate set 1643 of flows matching the rule condition forwarded via a single interface. 1645 Meters are measured against traffic profile modeled by the 1646 qosPolicyPRTrfcProf object. The property qpTrfcProf holds a reference 1647 to a traffic profile that resides in a reusable-object repository. 1649 4.7.1.2 Markers 1651 Markers are used to set the DS field of a packet to a particular DS 1652 codepoint (DSCP), adding the marked packet to a particular DS behavior 1653 aggregate. The marker may be configured to mark all packets steered to 1654 it to a single DSCP, or may be configured to mark a packet to one of a 1655 set of DSCPs used to select a PHB in a PHB group, according to the 1656 state of a meter. When the marker changes the DSCP in a packet, it is 1657 said to have "re-marked" the packet. 1659 Marking is modeled by the property qpSetDSCPValue, which specifies the 1660 DSCP to set. Remarking out-of-profile packets is modeled by the 1661 qpOutofProfileRemarkValue property. The property qpOutOfProfileAction 1662 should be set to 'remark' when the remark DSCP value is used. 1664 4.7.1.3 Shapers 1666 Shapers are used to delay some or all of the packets in a traffic 1667 stream in order to bring the stream into compliance with a traffic 1668 profile. A shaper usually has a finite-sized buffer, and packets may 1669 be discarded if there is not sufficient buffer space to hold the 1670 delayed packets. 1672 If the value of the property qpOutOfProfileAction is set to 'shape', 1673 then this specifies that packets measured by a meter should be shaped 1674 according to the traffic profile specified by a qosPolicyPRTrfcProf 1675 object. 1677 Snir, Ramberg, Strassner, Cohen expires October 2000 32 1678 Draft-ietf-policy-qos-info-model-01.txt April 2000 1680 4.7.1.4. Droppers 1682 Droppers are used to discard some or all of the packets in a traffic 1683 stream in order to bring the stream into compliance with a traffic 1684 profile. This process is also known as "policing" the stream. 1686 If the value of the property qpOutOfProfileAction is set to 'drop', 1687 then it specifies that packets measured by a meter should be policed 1688 according to the traffic-profile specified by a qosPolicyPRTrfcProf 1689 object. 1691 4.7.1.5 Examples 1693 The following examples will help to show how these classes can be used 1694 to perform general provisioning actions. 1696 Example 1: Set up a rule enforcing QoS provisioning actions: 1698 Let�s define a policy rule, P, as follows: 1700 If () THEN, on outgoing traffic, 1701 mark with AND 1702 activate a per-flow policer AND 1703 activate a per policy rule policer 1705 Rule P is represented using 3 qosPolicyPRAction objects: 1707 Object 1: 1708 qpDirection: OUT 1709 qpSetDSCPValue: 1711 Object 2: 1712 qpDirection: OUT 1713 qpMeterScope: flow 1714 qpTrfcProf: (this is a repository-specific reference to a 1715 per-flow policer object) 1716 qpOutOfProfileAction: discard 1718 Object 3: 1719 qpDirection: OUT 1720 qpMeterScope: Interface 1721 qpTrfcProf: (this is a repository-specific reference to a 1722 per-policyRule policer object) 1723 qpOutOfProfileAction: discard 1724 qpMeter: 1726 Snir, Ramberg, Strassner, Cohen expires October 2000 33 1727 Draft-ietf-policy-qos-info-model-01.txt April 2000 1729 Example 2: Conditioning traffic 1731 Some PHBs require the successive application of a set of traffic 1732 conditioners to properly process the traffic. An example of a policy 1733 with two levels of traffic conditioning is the following: 1735 Mark packets to DSCP=24 if the rate is within profile x=<64Kb/s>, 1736 else mark packets with DSCP=25 if rate is within profile y=<128kb/s>, 1737 else drop out-of-profile packets. 1739 This policy rule can be modeled by using two actions. The first action 1740 measures the traffic against the first profile. If the traffic is 1741 within this profile, then the traffic is (re)marked with a DSCP of 24. 1742 If the traffic is out of profile, then the subsequent action measures 1743 the traffic against the second higher profile. If the traffic is within 1744 this profile, then the traffic is (re)marked with a DSCP of 25. 1745 Otherwise, the traffic is out of profile, and it will be dropped. 1747 In this way, an arbitrary cascading of traffic conditioners can be 1748 constructed, where each action measures traffic against a higher 1749 traffic profile and change only the out-of-profile action as required. 1751 4.7.2 Signaling Action 1753 RSVP is the standard protocol used for requesting QoS resources from 1754 the network. The QoS policy signaling actions defined in this document 1755 can be used to control whether to admit or reject an RSVP request based 1756 on the request's attributes and the specified policy. The QoS policy 1757 signaling actions allow modifying the content and forwarding behavior 1758 of RSVP requests. 1760 The signaling policies control the admission priority of resources and 1761 provide preemption support. Mapping of integrated services signaled by 1762 RSVP to differential services in a core network is controlled by 1763 signaling policies as well, by assigning appropriate DSCPs to flows on 1764 the boundary of the differential service core. 1766 The set of policies specified allow a policy server (policy decision 1767 point) to instruct an RSVP node (policy enforcement point) to enforce 1768 all set of controls defined in the COPS protocol specification. The 1769 actions defined here follow the different decision types of the COPS 1770 protocol [COPS] and the guidelines for its use in an RSVP environment 1771 [COPS-RSVP]. The basic decision to accept or deny a reservation is 1772 modeled by the qosPolicyRSVPAction class. Additional control is 1773 provided through the use of two classes. The content and forwarding 1774 behavior of RSVP flows is defined by the qosPolicyRSVPSignalCtrlAction 1775 class. The qosPolicyRSVPInstallAction class controls the processing of 1776 RSVP requests and accompanying flows within the RSVP node itself. 1778 Snir, Ramberg, Strassner, Cohen expires October 2000 34 1779 Draft-ietf-policy-qos-info-model-01.txt April 2000 1781 QoS signaling policies does not require a policy server for decision 1782 making. A local policy module can use signaling policies for making 1783 local decisions, as well as if other outsourcing policy protocol beside 1784 COPS is used. 1786 The qosPolicyRSVPAction action includes a specification of the subset 1787 of RSVP flows on which the action should be taken. The following 1788 parameters can be specified: 1790 1. Direction - in/out 1791 2. Message type - Path/Resv/PathErr/ResvErr 1792 3. Service type - Guaranteed Service / Controlled Load / Null 1793 4. Service style - SE, WF, FF 1795 The direction refers to the direction of the flow, hence the direction 1796 of the RSVP Path messages. Therefore, out-direction policies control 1797 outgoing Path messages as well as incoming Resv messages. 1799 The basic decision modeled by this class is whether to admit or reject 1800 the RSVP request. The decision can be based on comparison of the 1801 request TSPEC or FLOWSPEC to a traffic profile and a meter. A meter can 1802 be used to track the temporal resources allocation of RSVP requests 1803 matching a network condition. Such meters allow enforcement of policies 1804 of the form: "Allow allocation of resource via RSVP for flows coming 1805 from subnet x up to a total aggregated rate of 256kb/sec". Use of 1806 meters and meter scope is identical to their use in provisioning 1807 policies. The following properties are used: 1809 1. Traffic Profile - referencing a traffic profile. 1810 2. Meter - referencing a meter. 1812 Both traffic profile and meter specifications can be directly included 1813 within the action as well. 1815 Note that if a traffic profile is not provided, it is implicitly 1816 assumed that the RSVP request should be accepted. Rejecting all RSVP 1817 requests matching the condition is specified by a zero valued traffic 1818 profile. 1820 The qosPolicyRSVPInstallAction adds the following actions: 1822 1. Set the DSCP value 1823 2. Set the preemption priority of the RSVP request. 1825 Setting the DSCP of the flow on the edge of a differential service core 1826 allow provisioning of QoS, end-to-end, over mixed integrated and 1827 differential service clouds. 1829 Snir, Ramberg, Strassner, Cohen expires October 2000 35 1830 Draft-ietf-policy-qos-info-model-01.txt April 2000 1832 An RSVP node is responsible for deciding whether to admit flows or not, 1833 based on its available resources. Setting the preemption priority 1834 [RSVP_PREEMP] allows the RSVP node to decide which of its reservations 1835 should be admitted, and when to make room for a newer reservation by 1836 preempting an already installed one. 1838 This class should be extended to cover other COPS install decisions if 1839 required. 1841 The qosPolicyRSVPSignalCtrlAction adds the following controls: 1843 1. Replace/add DCLASS object in RSVP message. 1844 2. Replace/add Preemption priority object in RSVP message. 1845 3. Trigger an error/warning RSVP message. 1846 4. Instruct the RSVP node to proxy RSVP message as if sent by 1847 the RSVP end nodes. 1849 Modifying the content of messages can be enforced using a COPS 1850 replacement decision. This class should be extended to cover other 1851 object replacements and, in particular, replacement of policy objects. 1853 Triggering errors and warnings is important in scenarios when there is 1854 a need to notify the end nodes that their reservation is about to 1855 expire and various other information. 1857 There are scenarios in which it makes sense not to carry RSVP requests 1858 end-to-end. An RSVP node on the boundary of a differential service core 1859 may map the RSVP request to specific PHB by setting the DSCP on the 1860 flow packets, without forwarding the Path message downstream. Still, 1861 this RSVP node may send back an RSVP Resv message as if the receiver 1862 has sent it, to complete the RSVP cycle. 1864 The following is an example for a rule enforcing QoS signaling actions: 1866 Rule S: 1867 If THEN, for all WF and SE style Resv messages, 1868 accept RSVP request requesting less than <64kb/sec> AND 1869 make sure that the total number of admitted active reservations 1870 is restricted to <5>. 1872 The actions for Rule S are represented using two qosPolicyRSVPAction 1873 objects, as follows: 1875 Object 1: 1876 qpRSVPDirection: OUT 1877 qpRSVPMessageType: Resv 1878 qpRSVPStyle: SE, WF 1879 qpRSVPTrfcProf : DN {8Kb} (repository reference) 1880 qpRSVPMeterScope: flow 1882 Snir, Ramberg, Strassner, Cohen expires October 2000 36 1883 Draft-ietf-policy-qos-info-model-01.txt April 2000 1885 Object 2: 1886 qpRSVPDirection: OUT 1887 qpRSVPMessageType: Resv 1888 qpRSVPStyle: SE, WF 1889 qpRSVPTrfcProf : {6 session Max} (repository reference) 1890 qpRSVPMeter: Meter (repository reference) 1891 qpRSVPMeterScope: interface 1893 The various attributes of RSVP traffic profiles are described in the 1894 next section. 1896 4.8. Traffic Profiles 1898 The QoS Policy schema defines two categories of traffic profiles. 1899 Provisioning traffic profiles carry rate and burst parameters to be 1900 compared with flow meters. RSVP traffic profiles are compared with RSVP 1901 TSPEC and FLOWSPEC parameters, and with meters aggregating the temporal 1902 state of admitted RSVP reservations and states. 1904 Traffic profiles can be kept in a repository for reusability. Traffic 1905 profiles can also be directly attached to actions. 1907 4.8.1. Provisioning traffic profiles 1909 Shaping, policing and remarking provisioning actions compare a 1910 provisioning traffic profile against a meter. The provisioning traffic 1911 profile is a template containing rate and burst values, modeled by the 1912 qosPolicyPRTrfcProf class. 1914 The qosPolicyPRTrfcProf class includes the following properties: 1916 1. Rate measured in bits/sec. 1917 2. Normal burst measured in bytes. 1918 3. Excess burst measured in bytes. 1920 Rate determines the long-term average transmission rate. Traffic that 1921 falls under this rate will always conform. The normal burst size 1922 determines how large traffic bursts can be before some traffic exceeds 1923 the traffic profile. The Excess Burst size determines how large traffic 1924 bursts can be before all traffic exceeds the rate limit. Traffic that 1925 falls between the normal burst size and the Excess Burst size exceeds 1926 the traffic profile with a probability that increases as the burst size 1927 increases. This provides a Random Discard mechanism for policers, 1928 markers and shapers. 1930 Excess burst size SHOULD be greater than or equal to the normal burst 1931 size. If the excess burst size is not specified, it is assumed that 1932 excess burst size is equal to the normal burst size. In this case, 1933 burst larger than the normal burst size will always be counted as out- 1934 of-profile packets. 1936 Snir, Ramberg, Strassner, Cohen expires October 2000 37 1937 Draft-ietf-policy-qos-info-model-01.txt April 2000 1939 4.8.2. RSVP traffic profiles 1941 RSVP signaling QoS policy can condition the decision whether to accept 1942 or deny an RSVP request based on the traffic specification of the flow 1943 (TSPEC) or the amount of QoS resources requested (FLOWSPEC). The TSPEC 1944 and FLOWSPEC objects are either compared directly with a traffic 1945 profile, or aggregated to a meter that measures the temporal admitted 1946 RSVP states and than compared to the traffic specification. The 1947 qosPolicyRSVPTrfcProf class models such a traffic profile. The 1948 qosPolicyRSVPTrfcProf class has the following properties: 1950 1. Token Rate (r) measured in bits/sec. 1951 2. Peak Rate (p) measured in bits/sec. 1952 3. Bucket Size (b) measured in bytes. 1953 4. Min Policed unit (m) measured in bytes. 1954 5. Max packet size (M) measured in bytes. 1955 6. Resv Rate (R) measured in bits/sec. 1956 7. Slack term (s) measured in microseconds. 1957 8. Number of sessions. 1959 The first 5 parameters are the traffic specification parameters used in 1960 the integrated service architecture. These parameters are used to 1961 define a sender TSPEC as well as FLOWSPEC for the Controlled Load 1962 service [CL]. For a definition and full explanation of their meaning, 1963 please refer to [RSVP-IS]. Parameters 6 and 7 are the additional 1964 parameters used for specification of the Guaranteed Service FLOWSPEC 1965 [GS]. The last parameter is used to specify the maximum number of 1966 allowed RSVP sessions. This provides an easy way to limit the number of 1967 admitted RSVP requests without requiring pre-knowledge of the 1968 aggregated rates requested. 1970 A partial order is defined between TSPECs (and FLOWSPECs). A TSPEC A is 1971 larger than TSPEC B if and only if rA>rB, pA>pB, bA>bB, mAMB. A TSPEC measured against a traffic profile uses the same 1973 ordering rule. An RSVP message is accepted only if its TSPEC (FLOWSPEC) 1974 is either smaller or equal to the traffic profile. Only parameters 1975 specified in the traffic profile are compared. 1977 The GS FLOWSPEC is also compared against the rate R and the slack term 1978 S. R should not be larger than the traffic profile R parameter, while 1979 the FLOWSPEC slack term should not be smaller than that specified in 1980 the slack term. 1982 TSPECs as well as FLOWSPECs can be added. The sum of two TSPECs is 1983 computed by summing the rate r, the peak rate p, the bucket size b, and 1984 by taking the minimum of min policed unit m and the maximum of the max 1985 packet size M. GS FLOWSPECs are summed by adding the Resv rate and 1986 minimizing the slack term s. These rules are used to compute a meter 1987 that measures the temporal state of admitted RSVP states. The meter is 1988 than compared with the traffic profile specified in the signaling 1989 policy using the same rules for comparison of TSPECs (FLOWSPECs) to a 1990 traffic profile. 1992 Snir, Ramberg, Strassner, Cohen expires October 2000 38 1993 Draft-ietf-policy-qos-info-model-01.txt April 2000 1995 5. Decision strategy 1997 The decision strategy to be used by policy servers and other policy 1998 decision points in the network on a set of policies is defined by 1999 grouping policies into various qosNamedPolicyContainer groups, and 2000 using these groups to partition behavior in different QoS policy 2001 domains. In order to get a consistent behavior of different policy 2002 servers using the same group of policy rules, the priority of the 2003 policy rules must be pre-defined and the decision strategy implemented 2004 by each different policy server must be defined explicitly. 2006 The decision strategy is defined per domain and can be overridden per 2007 qosNamedPolicyContainer. When a policy decision point evaluates a set 2008 of rules, it implements the decision strategy defined in each container 2009 of rules. Nested containers can override the decision strategy of their 2010 containers. 2012 The order of decision making of nested rules is defined by the 2013 combination of their internal priority, the priority of the policy rule 2014 containing the nested rule and the priority of their containers. 2015 Nested rules have a higher priority than their containing rule. 2016 Priority is compared between rules and qosNamedPolicyContainers, as 2017 Defined in [PCIM]. The rule priority of PCIM is extended by introducing 2018 the qpPriority (group priority) property of qosNamedPolicyContainer. 2020 Two decision strategies are defined: 2022 1. "FIRST MATCH" 2023 2. "MATCH ALL" 2025 5.1. First match 2027 The first match decision strategy is defined as a process that 2028 evaluates the policy rules in the defined order, evaluating the 2029 conditions of each rule, until a condition is evaluated to TRUE. The 2030 rule's actions are then applied and the process of decision-making is 2031 terminated. 2033 5.2. Match All 2035 The match all decision strategy is defined as first scanning the 2036 complete set of rules according to their defined order of priority and 2037 then applying the actions of each rule that the flow meets with the 2038 rule's conditions. This matching strategy may in many cases mean that a 2039 number of rules may meet the flow's parameters and all of their actions 2040 will be applied. 2042 A Match All strategy may result in applying conflicting rules. Handling 2043 conflicts is outside the scope of this draft. The implementers of QoS 2044 systems must provide proprietary conflict detection and avoidance or 2045 resolution mechanisms. 2047 Snir, Ramberg, Strassner, Cohen expires October 2000 39 2048 Draft-ietf-policy-qos-info-model-01.txt April 2000 2050 5.3. Decision Strategy example 2052 This section demonstrates both decision strategies and rule 2053 prioritization. The rules to be evaluated are shown in Figure 4 below. 2055 Domain 2056 | 2057 +--Rule1 (priority 19) 2058 | 2059 +--NamedContainer1 (priority 5) 2060 | | 2061 | +--Rule 1.1 (priority 3) 2062 | | 2063 | +--Rule 1.2 (priority 33) 2064 | 2065 +--Rule3 (priority 4) 2066 | 2067 +--Rule4 (priority 2) 2069 Figure 4: Decision Strategy example 2071 NOTE: rule nesting is not defined in PCIM, but rather is defined in 2072 this document 2074 5.3.1 Default Operation using First Match Everywhere 2076 For simplicity we assume that a Policy Decision Point needs to enforce 2077 all rules described above. Therefore, the rules will be evaluated in 2078 the following order: 2080 1. Rule1 (higher priority between Rule1, namedContainer1 and Rule3 2081 2. Rule1.2 (higher priority between Rule1.1 and Rule1.2) 2082 3. Rule1.1 (because its container has a higher priority than Rule3 2083 4. Rule4 (because it is nested in Rule 3) 2084 5. Rule3 2086 If the decision strategy of the domain is first match and it is not 2087 overridden by NamedContainer1, the decision process will stop once a 2088 rule's condition is matched. 2090 Note: this equates priority with order. This is very different than how 2091 this same example would work using priority as defined in [PCIM] (in 2092 fact, this could not even be represented in [PCIM]). This is because of 2093 the following two reasons: 2095 - PCIM does not provide the ability to assign an order to a named 2096 container. It therefore has no concept of ordering containers among 2097 its policy rules 2098 - PCIM has no concept of nested rules 2100 Snir, Ramberg, Strassner, Cohen expires October 2000 40 2101 Draft-ietf-policy-qos-info-model-01.txt April 2000 2103 5.3.2 Operation Using Other Decision Strategies 2105 However, if the decision strategy of the domain is match all and it is 2106 not overridden by NamedContainer1, the match all decision process will 2107 run over all rules according to the order above. 2109 If the decision strategy of the domain is first match and the decision 2110 process of NamedContainer1 is match all, Rule1 will be evaluated 2111 first. If its condition matches, the decision process stops. Else, 2112 both Rules 1.1 and 1.2 will be evaluated and executed if their 2113 conditions match. If one of NamedContainer1 rule match, the decision 2114 process stops. Else Rules 3 and 4 will be evaluated using first match 2115 decision strategy. 2117 If the decision strategy of the domain is match all and the decision 2118 process of NamedContainer1 is first match, the decision process will 2119 evaluate Rule1 and continue to evaluate NamedContainer1 rules. Rules 2120 1.1 and 1.2 will be evaluated using first match strategy. The decision 2121 process continues to evaluate rules 3 and 4 according to match-all 2122 decision strategy. 2124 Snir, Ramberg, Strassner, Cohen expires October 2000 41 2125 Draft-ietf-policy-qos-info-model-01.txt April 2000 2127 6. Per Hop Behavior 2129 A per-hop behavior (PHB) is a description of the externally observable 2130 forwarding behavior of a DS node applied to a particular DS behavior 2131 aggregate. A PHB is selected at a node by the DSCP in a received 2132 packet. A set of PHBs is enforced on a QoS domain. The set of PHBs 2133 share buffer and scheduler resources among them. The QPIM provides 2134 abstract placeholders for PHBs and for a set of PHBs enforced together 2135 on a QoS domain. Further specification of PHBs and PHB sets are outside 2136 the scope of this document; please refer to [PHBSET] for more 2137 information. 2139 6.1. PHBs 2141 The qosPolicyPHB abstract class models a single PHB. The qosPolicyPHB 2142 class includes a single property, the DSCP value, which is an integer 2143 with allowed values in the range of 0 to 63, inclusive. The 2144 qosPolicyPHB name will be defined using the cn property belonging 2145 to the Policy class [PCIM]. 2147 6.1. PHB Sets 2149 The qosPolicyPHBSet abstract class serves as a named container for 2150 instances of qosPolicyPHB classes. It models the set of PHBs enforced 2151 together on a QoS domain. Different PHB sets can be kept in a 2152 repository. A PHB set enforced on the domain is specified by either a 2153 reference from the qosPolicyDomain class to one of the PHB sets that 2154 are located in the reusable-object repository, or by directly including 2155 the PHB set in the domain (the method for doing this is repository- 2156 specific; for example, attachment could be used if the repository is a 2157 directory). 2159 To fine tune PHB parameters and to further restrict the namespace in 2160 which a particular PHB is used, PHB sets can be referenced or augment 2161 the semantics of qosNamedPolicyContainers. However, in order to 2162 maintain an end-to-end consistent behavior, overriding the domain's PHB 2163 set should be done only to fine tune the parameters of each PHBs, and 2164 not to use a different set of PHBs altogether. 2166 Markers coloring packets of flows on domain ingress edges should pick a 2167 DSCP selecting one of the PHBs enforced on the QoS domain. 2169 Snir, Ramberg, Strassner, Cohen expires October 2000 42 2170 Draft-ietf-policy-qos-info-model-01.txt April 2000 2172 7. QoS Policy Class Inheritance 2174 The following diagram illustrates the class hierarchy for the QPIM. 2175 Relevant classes from the PCIM are also included for completeness: 2177 top 2178 | 2179 +--policy (abstract, [PCIM]) 2180 | | 2181 | +--policyGroup ([PCIM]) 2182 | | | 2183 | | +--qosPolicyDomain 2184 | | | 2185 | | +--qosNamedPolicyContainer 2186 | | 2187 | +--policyRule ([PCIM]) 2188 | | 2189 | +--policyCondition ([PCIM]) 2190 | | | 2191 | | +--policyTimePeriodCondition ([PCIM]) 2192 | | | 2193 | | +--vendorPolicyCondition ([PCIM]) 2194 | | | 2195 | | +--qosPolicySimpleCondition 2196 | | 2197 | +--policyAction 2198 | | | 2199 | | +--vendorPolicyAction ([PCIM]) 2200 | | | 2201 | | +-- qosPolicyPRAction 2202 | | | 2203 | | +-- qosPolicyRSVPAction 2204 | | | 2205 | | +-- qosPolicyRSVPSignalCtrlAction 2206 | | | 2207 | | +-- qosPolicyRSVPInstallAction 2208 | | 2209 | +--qosPolicyVariable 2210 | | 2211 | +--qosPolicyValue(abstract) 2212 | | | 2213 | | +--qosPolicyIPv4AddrValue 2214 | | | 2215 | | +--qosPolicyIPv6AddrValue 2216 | | | 2217 | | +--qosPolicyMACAddrValue 2218 | | | 2219 | | +--qosPolicyStringValue 2220 | | | 2221 | | +--qosPolicyBitStringValue 2222 | | | 2224 (Diagram continued in next page) 2226 Snir, Ramberg, Strassner, Cohen expires October 2000 43 2227 Draft-ietf-policy-qos-info-model-01.txt April 2000 2229 (Diagram continued from previous page) 2231 top 2232 | 2233 +--policy (abstract, [PCIM]) 2234 | | 2235 | +--qosPolicyValue(abstract, continued from previous page) 2236 | | | 2237 | | +--qosPolicyDNValue 2238 | | | 2239 | | +--qosPolicyAttributeValue 2240 | | | 2241 | | +--qosPolicyIntegerValue 2242 | | 2243 | +-- qosPolicyMeter 2244 | | 2245 | +-- qosPolicyPRTrfcProf 2246 | | 2247 | +-- qosPolicyRSVPTrfcProf 2248 | | 2249 | +-- qosPolicyPHBSet (abstract) 2250 | | 2251 | +-- qosPHB (abstract) 2252 | 2253 +--CIM_ManagedSystemElement (abstract) 2254 | 2255 +--CIM_LogicalElement (abstract) 2256 | 2257 +--CIM_System (abstract) 2258 | 2259 +---CIM_AdminDomain (abstract) 2260 | 2261 +---PolicyRepository 2263 Figure 5. Class Inheritance Hierarchy for the QPIM 2265 The reader is encouraged to read section 7 of [PCIM] in its entirety, 2266 which defines the concepts of associations and aggregations. Ten 2267 associations and aggregations are defined in the [PCIM]; note that the 2268 QPIM does not define any new associations or aggregations: 2270 the Aggregation PolicyGroupInPolicyGroup 2271 the Aggregation PolicyRuleInPolicyGroup 2272 the Aggregation PolicyConditionInPolicyRule 2273 the Aggregation PolicyRuleValidityPeriod 2274 the Aggregation PolicyActionInPolicyRule 2275 the Association PolicyConditionInPolicyRepository 2276 the Association PolicyActionInPolicyRepository 2277 the Weak Aggregation PolicyGroupInSystem 2278 the Weak Aggregation PolicyRuleInSystem 2279 the Aggregation PolicyRepositoryInPolicyRepository 2281 Snir, Ramberg, Strassner, Cohen expires October 2000 44 2282 Draft-ietf-policy-qos-info-model-01.txt April 2000 2284 8. Class Definitions 2286 8.1. Class qosPolicyDomain 2288 This class defines the root of a single administrative QoS policy 2289 domain, and contains the domain's policy rules and definitions. This 2290 enables the administrator to partition the set of QoS information into 2291 different domains, where each domain has a potentially different set of 2292 PHBs and policies, access rules, decision strategy or other application 2293 of the policy information organized in some fashion. The class 2294 definition is as follows: 2296 NAME qosPolicyDomain 2297 DERIVED FROM policyGroup (defined in [PCIM]) 2298 ABSTRACT False 2299 PROPERTIES qpDomainName, qpPHBSet, qpPolicyRuleMatchMethod 2301 8.1.1. The Property qpDomainName 2303 This property provides a user-friendly name for the QoS policy domain. 2304 Its definition is as follows: 2306 NAME qpDomainName 2307 SYNTAX String 2309 8.1.2. The Property qpPHBSet 2311 This property contains a reference to the PHB set defined for this 2312 domain. Its definition is as follows: 2314 NAME qpPHBSet 2315 SYNTAX Reference to a PHBSet object 2317 8.1.3. The Property qpPolicyRuleMatchMethod 2319 This property defines the decision strategy to be applied on this set 2320 of QoS policy rules by policy servers. It is an enumerated integer that 2321 defines two values, first match and match all. Please see section 5 of 2322 this document for more information on these decision strategies. Its 2323 definition is as follows: 2325 NAME qpPolicyRuleMatchMethod 2326 SYNTAX Integer (ENUM) - {"FIRST MATCH " = 0; "MATCH ALL " = 1 } 2328 Snir, Ramberg, Strassner, Cohen expires October 2000 45 2329 Draft-ietf-policy-qos-info-model-01.txt April 2000 2331 8.2. Class qosNamedPolicyContainer 2333 This class represents an administratively-defined policy rule 2334 container. All policies that are commonly administered are defined in a 2335 particular qosNamedPolicyContainer. For example, an administrator could 2336 define a set of policies that serve a certain goal, or service a 2337 certain type of application, or that handle a certain type of flow or 2338 device. Placing these policies in a qosNamedPolicyContainer that 2339 resides in a particular qosPolicyDomain enables the administrator to 2340 group different sets of policy rules that perform different types of 2341 operations. It also enables an organization to partition policies 2342 according to the administrator (or other entity) that manages the 2343 policies. The class definition is as follows: 2345 NAME qosNamedPolicyContainer 2346 DERIVED FROM policyGroup (defined in [PCIM]) 2347 ABSTRACT False 2348 PROPERTIES qpPriority, qpNamedPolicyRuleMatchMethod 2350 8.2.1. The Property qpPriority 2352 This property is a non-negative integer that defines the priority of a 2353 named group of rules. Conceptually, it is the priority of the 2354 qosNamedPolicyContainer, and is used to determine when the policy rules 2355 that the qosNamedPolicyContainer contains are evaluated with respect to 2356 other policyRules, policyGroups, and other qosNamedPolicyContainters. 2358 If two or more qosPolicyNamedContainer objects have the same priority, 2359 this means that the order between these objects is of no importance, 2360 but that they each be evaluated before other objects that have a 2361 numerically lower priority. The attribute is defined as follows: 2363 NAME qpPriority 2364 SYNTAX Integer (must be non-negative) 2366 8.2.2. The Property qpNamedPolicyRuleMatchMethod 2368 This property is an enumerated integer that defines the decision 2369 strategy to be applied on this set of QoS policy rules by policy 2370 servers. Please see section 5 of this document for more information on 2371 these decision strategies. The attribute is defined as follows: 2373 NAME qpNamedPolicyRuleMatchMethod 2374 SYNTAX Integer (ENUM) - {"FIRST MATCH " = 0; "MATCH ALL " = 1 } 2376 Snir, Ramberg, Strassner, Cohen expires October 2000 46 2377 Draft-ietf-policy-qos-info-model-01.txt April 2000 2379 8.3. Class qosPolicyPRAction 2381 This class defines DiffServ actions to be applied on a flow or group of 2382 flows, including the marking of a DSCP value, dropping, policing and 2383 shaping. The class definition is as follows: 2385 NAME qosPolicyPRAction 2386 DERIVED FROM policyAction (defined in [PCIM]) 2387 ABSTRACT False 2388 PROPERTIES qpDirection, qpSetDSCPvalue, qpMeter, qpMeterScope, 2389 qpTrfcProf, qpOutOfProfileAction, 2390 qpOutOfProfileRemarkValue 2392 8.3.1. The Property qpDirection 2394 This property is an enumerated integer that defines whether the action 2395 should be applied to incoming or/and outgoing interfaces. Note that 2396 certain repositories MAY implement this enumeration in a different 2397 form, as long as its semantics are preserved. For example, a directory 2398 MAY implement this property as a multi-valued attribute, with the 2399 attribute having the values IN and OUT. The attribute is defined as 2400 follows: 2402 NAME qpDirection 2403 SYNTAX Integer (ENUM) - {IN=0, OUT=1, BOTH=2} 2405 8.3.2. The Property qpSetDSCPvalue 2407 This property is an integer (constrained to the range 0-63, inclusive) 2408 that defines the DSCP value of the (re)mark action. The attribute is 2409 defined as follows: 2411 NAME qpSetDSCPvalue 2412 SYNTAX Integer (must be in the range 0-63, inclusive) 2414 8.3.3. The Property qpMeter 2416 This property defines a reference to a qosPolicyMeter object used in 2417 this provisioning action. The attribute is defined as follows: 2419 NAME qpMeter 2420 SYNTAX Reference to a qosPolicyMeter object 2422 Snir, Ramberg, Strassner, Cohen expires October 2000 47 2423 Draft-ietf-policy-qos-info-model-01.txt April 2000 2425 8.3.4. The Property qpMeterScope 2427 This property is an enumerated integer that defines whether this 2428 metering action should be applied on a per-flow, per-interface, or per- 2429 device basis. The attribute is defined as follows: 2431 NAME qpMeterScope 2432 SYNTAX Integer (ENUM) � {flow=0,interface=1 device=2} 2434 8.3.5. The Property qpTrfcProf 2436 This property contains a reference to an object that defines the 2437 DiffServ provisioning policing instruction value, defined as a 2438 reference to a qosPolicyPRTrfcProf instance. The attribute is defined 2439 as follows: 2441 NAME qpTrfcProf 2442 SYNTAX Reference to a qosPolicyPRTrfcProf object 2444 8.3.6. The Property qpOutOfProfileAction 2446 This property is an enumerated integer that defines the action to be 2447 applied to out of profile packets, as defined in the DiffServTrfcProf 2448 entry. That entry contains values for each of the three types of 2449 actions that are present in this attribute: shaping, discarding, or 2450 remarking. The attribute is defined as follows: 2452 NAME qpOutOfProfileAction 2453 SYNTAX Integer (ENUM) - {SHAPE=0,DISCARD=1,REMARK=2} 2455 8.3.7. The Property qpOutofProfileRemarkValue 2457 This property is an integer that defines the DSCP value to be applied 2458 to out of profile packets if the qpOutofProfile action is defined as 2459 REMARK. The attribute is defined as follows: 2461 NAME qpOutofProfileRemarkValue 2462 SYNTAX Integer (constrained to the range 0-63, inclusive) 2464 8.4. Class qosPolicyRSVPAction 2466 This class defines a policy action to be applied on an RSVP signaling 2467 message that matches the rule condition. The class definition is as 2468 follows: 2470 Snir, Ramberg, Strassner, Cohen expires October 2000 48 2471 Draft-ietf-policy-qos-info-model-01.txt April 2000 2473 NAME qosPolicyRSVPAction 2474 DERIVED FROM policyAction (defined in [PCIM]) 2475 ABSTRACT False 2476 PROPERTIES qpRSVPDirection, qpRSVPMessageType, qpRSVPService, 2477 qpRSVPStyle, qpRSVPInstallAction, qpRSVPCtrlAction, 2478 qpRSVPMeter, qpRSVPMeterScope, qpRSVPTrfcProf 2480 8.4.1. The Property qpRSVPDirection 2482 This property is an enumerated integer, and defines whether the action 2483 is to be applied to incoming or/and outgoing interfaces. Note that 2484 certain repositories MAY implement this enumeration in a different 2485 form, as long as its semantics are preserved. For example, a directory 2486 MAY implement this property as a multi-valued attribute, with the 2487 attribute having the values IN and OUT. The attribute is defined as 2488 follows: 2490 NAME qpRSVPDirection 2491 SYNTAX Integer (ENUM) - {IN=0,OUT=1,BOTH=2} 2493 8.4.2. The Property qpRSVPMessageType 2495 This property is an enumerated integer, and defines different values 2496 that limit the scope of the action to be enforced to specific types of 2497 RSVP messages. The attribute is defined as follows: 2499 NAME qpRSVPMessageType 2500 SYNTAX Integer (ENUM) - {Path=0 Resv=1 ResvErr=2 PathErr=3} 2502 8.4.3. The Property qpRSVPStyle 2504 This property is an enumerated integer, and defines different values 2505 that limit the scope of the action to be enforced to RSVP Requests with 2506 the specified reservation style. The attribute is defined as follows: 2508 NAME qpRSVPStyle 2509 SYNTAX Integer (ENUM) - {SE=0 FF=1 WF=2} 2511 8.4.4. The Property qpRSVPServiceType 2513 This property is an enumerated integer, and defines different values 2514 that limit the scope of the action to be enforced to RSVP Requests 2515 asking for specified integrated service type. The attribute is defined 2516 as follows: 2518 NAME qpRSVPServiceType 2519 SYNTAX Integer (ENUM) - 2520 {ControlledLoad=0, GuaranteedService=1, NULL=2} 2522 Snir, Ramberg, Strassner, Cohen expires October 2000 49 2523 Draft-ietf-policy-qos-info-model-01.txt April 2000 2525 8.4.5. The Property qpRSVPInstallAction 2527 This property is a reference to a qosPolicyRSVPInstallAction object. 2528 This object is used in conjunction with the RSVP reservation, and 2529 defines detailed control for COPS install decisions (defined in 2530 [COPS]). The attribute is defined as follows: 2532 NAME qpRSVPInstallAction 2533 SYNTAX Reference to a qosPolicyRSVPInstallAction object 2535 8.4.6. The Property qpRSVPCtrlAction 2537 This property is a reference to a qosPolicyRSVPSignalCtrlAction object. 2538 This object is used in conjunction with the RSVP reservation, and 2539 defines detailed control on the signaling protocol behavior itself. 2540 The information carried in RSVP messages can be modified using this 2541 action, as well as the RSVP forwarding behavior. The attribute is 2542 defined as follows: 2544 NAME qpRSVPCtrlAction 2545 SYNTAX Reference to a qosPolicyRSVPSignalCtrlAction object 2547 8.4.7. The Property qpRSVPMeter 2549 This property is a reference to a qosPolicyMeter object. This object is 2550 used in conjunction with the RSVP reservation, and defines the detailed 2551 definition of the meter characteristics. The attribute is defined as 2552 follows: 2554 NAME qpRSVPMeter 2555 SYNTAX Reference to a qosPolicyMeter object 2557 8.4.8. The Property qpRSVPMeterScope 2559 This property is an enumerated integer that defines the scope of the 2560 metering action to be on a per-flow, per-interface, or per-device 2561 basis. The attribute is defined as follows: 2563 NAME qpRSVPMeterScope 2564 SYNTAX Integer (ENUM) � {flow=0,interface=1 device=2} 2566 Snir, Ramberg, Strassner, Cohen expires October 2000 50 2567 Draft-ietf-policy-qos-info-model-01.txt April 2000 2569 8.4.9. The Property qpRSVPTrfcProf 2571 This property is a reference to a qosPolicyRSVPTrfcProf object, which 2572 defines an IntServ RSVP Traffic profile. Values of RSVP traffic 2573 profiles are compared against Traffic specification (TSPEC) and QoS 2574 Reservation requests (FLOWSPEC) carried in RSVP requests. The attribute 2575 is defined as follows: 2577 NAME qpRSVPTrfcProf 2578 SYNTAX Reference to a qosPolicyRSVPTrfcProf object 2580 8.5. Class qosPolicyPRTrfcProf 2582 A provisioning Traffic profile is a class that carries the policer or 2583 shaper rate values to be enforced on a flow or a set of flows. The 2584 class definition is as follows: 2586 NAME qosPolicyPRTrfcProf 2587 DERIVED FROM policy (defined in [PCIM]) 2588 ABSTRACT False 2589 PROPERTIES qpPRRate, qpPRNormalBurst, qpPRExcessBurst 2591 8.5.1. The Property qpPRRate 2593 This is a non-negative integer that defines the token rate in bits per 2594 second. A rate of zero means that all packets will be out of profile. 2595 The attribute is defined as follows: 2597 NAME qpPRRate 2598 SYNTAX Integer (must be non-negative) 2600 8.5.2. The Property qpPRNormalBurst 2602 This attribute is an integer that defines the normal size of a burst 2603 measured in bytes. The attribute is defined as follows: 2605 NAME qpPRNormalBurst 2606 SYNTAX Integer (must be non-negative) 2608 8.5.3. The Property qpPRExcessBurst 2610 This attribute is an integer that defines the excess size of a burst 2611 measured in bytes. The attribute is defined as follows: 2612 NAME qpPRExcessBurst 2613 SYNTAX Integer (must be non-negative) 2615 Snir, Ramberg, Strassner, Cohen expires October 2000 51 2616 Draft-ietf-policy-qos-info-model-01.txt April 2000 2618 8.6. Class qosPolicyRSVPTrfcProf 2620 This class represents an IntServ RSVP Traffic profile. Values of RSVP 2621 traffic profiles are compared against Traffic specification (TSPEC) and 2622 QoS Reservation requests (FLOWSPEC) carried in RSVP requests. Traffic 2623 profiles can be reusable objects or ad-hoc. The class definition is as 2624 follows: 2626 NAME qosPolicyRSVPTrfcProf 2627 DERIVED FROM policy (defined in [PCIM]) 2628 ABSTRACT False 2629 PROPERTIES qpRSVPTokenRate, qpRSVPPeakRate, 2630 qpRSVPBucketSize, qpRSVPResvRate, qpRSVPResvSlack, 2631 qpRSVPSessionNum, qpMinPolicedUnit, qpMaxPktSize 2633 8.6.1. The Property qpRSVPTokenRate 2635 This property is a non-negative integer that defines the token rate 2636 parameter, measured in bits per second. The attribute is defined as 2637 follows: 2639 NAME qpRSVPTokenRate 2640 SYNTAX Integer (must be non-negative) 2642 8.6.2. The Property qpRSVPPeakRate 2644 This property is a non-negative integer that defines the peak rate 2645 parameter, measured in bits per second. The attribute is defined as 2646 follows: 2648 NAME qpRSVPPeakRate 2649 SYNTAX Integer (must be non-negative) 2651 8.6.3. The Property qpRSVPBucketSize 2653 This property is a non-negative integer that defines the token bucket 2654 size parameter, measured in bits per second. The attribute is defined 2655 as follows: 2657 NAME qpRSVPBucketSize 2658 SYNTAX Integer (must be non-negative) 2660 Snir, Ramberg, Strassner, Cohen expires October 2000 52 2661 Draft-ietf-policy-qos-info-model-01.txt April 2000 2663 8.6.4. The Property qpRSVPResvRate 2665 This property is a non-negative integer that defines the RSVP rate (R- 2666 Spec) in the RSVP Guaranteed service reservation. It is measured in 2667 bits per second. The attribute is defined as follows: 2669 NAME qpRSVPResvRate 2670 SYNTAX Integer (must be non-negative) 2672 8.6.5. The Property qpRSVPResvSlack 2674 This property is a non-negative integer that defines the RSVP slack 2675 term in the RSVP Guaranteed service reservation. It is measured in 2676 microseconds. The attribute is defined as follows: 2678 NAME qpRSVPResvSlack 2679 SYNTAX Integer (must be non-negative) 2681 8.6.6. The Property qpRSVPSessionNum 2683 This property is a non-negative integer that defines the total number 2684 of allowed RSVP sessions that can be active at any given time. The 2685 attribute is defined as follows: 2687 NAME qpRSVPSessionNum 2688 SYNTAX Integer (must be non-negative) 2690 8.6.7. The Property qpMinPolicedUnit 2692 This property is a non-negative integer that defines the minimum RSVP 2693 policed unit, measure in bytes. The attribute is defined as follows: 2695 NAME qpMinPolicedUnit 2696 SYNTAX Integer (must be non-negative) 2698 8.6.8. The Property qpMaxPktSize 2700 This property is a non-negative integer that defines the maximum 2701 allowed packet size for RSVP messages, measure in bytes. The attribute 2702 is defined as follows: 2704 NAME qpMaxPktSize 2705 SYNTAX Integer (must be non-negative) 2707 Snir, Ramberg, Strassner, Cohen expires October 2000 53 2708 Draft-ietf-policy-qos-info-model-01.txt April 2000 2710 8.7. Class qosPolicyRSVPSignalCtrlAction 2712 This class extends the functionality of the qosPolicyRSVPAction class 2713 by adding detailed control on the signaling protocol behavior itself. 2714 The information carried in RSVP messages can be modified using this 2715 action, as well as the RSVP forwarding behavior. 2717 Since the purpose of this is to augment the behavior specified by the 2718 qosPolicyRSVPAction class, this class SHOULD be used with a 2719 qosPolicyRSVPAction object, and SHOULD NOT be used by itself. 2721 This class can be extended to support replacement of additional object 2722 in RSVP messages, beyond replacement of DCLASS and PREEMPTION object 2723 replacement defined below. 2725 The class definition is as follows: 2727 NAME qosPolicyRSVPSignalCtrlAction 2728 DERIVED FROM policyAction (defined in [PCIM]) 2729 ABSTRACT False 2730 PROPERTIES qpForwardingMode, qpSendError, qpReplaceDSCP, 2731 qpReplacePreemptionPriority, qpReplaceDefendingPriority 2733 8.7.1. The Property qpForwardingMode 2735 This property is an enumerated integer that controls the forwarding of 2736 RSVP messages. If the mode is set to proxy, RSVP Path messages are not 2737 forwarded and a Resv message is returned as if the Resv was returned by 2738 the receiver. Otherwise, RSVP Path messages are forwarded. The 2739 attribute is defined as follows: 2741 NAME qpForwardingMode 2742 SYNTAX Integer (ENUM) - {Forward=0 , Proxy=1} 2744 8.7.2. The Property qpSendError 2746 This property is an enumerated integer and controls the generation of 2747 Resv-Err and Path-Err messages as defined in [COPSRSVP]. The attribute 2748 is defined as follows: 2750 NAME qpSendError 2751 SYNTAX Integer {No=0, Yes=1} 2753 Snir, Ramberg, Strassner, Cohen expires October 2000 54 2754 Draft-ietf-policy-qos-info-model-01.txt April 2000 2756 8.7.3. The Property qpReplaceDSCP 2758 This property is a non-negative integer that allows the replacement of 2759 a DCLASS object carrying a DSCP value in an RSVP message. The attribute 2760 specifies the DSCP value to be replaces, and is defined as follows: 2762 NAME qpReplaceDSCP 2763 SYNTAX Integer (constrained to the range 0-63, inclusive) 2765 8.7.4. The Property qpReplacePreemptionPriority 2767 This property is a non-negative integer that is used to replace or add 2768 a preemption priority object (defined in [RSVP_PREEMP]) to RSVP 2769 messages. The attribute is defined as follows: 2771 NAME qpReplacePreemptionPriority 2772 SYNTAX Integer (must be non-negative) 2774 8.7.5. The Property qpReplaceDefendingPriority 2776 This property is a non-negative integer that is used to replace or add 2777 a preemption priority object (defined in [RSVP_PREEMP]) to RSVP 2778 messages. It specifies the defending priority within the preemption 2779 object. The attribute is defined as follows: 2781 NAME qpReplaceDefendingPriority 2782 SYNTAX Integer (must be non-negative) 2784 8.8. Class qosPolicyRSVPInstallAction 2786 This class extends the functionality of the qosPolicyRSVPAction class 2787 by adding detailed control for COPS Install decisions (defined in 2788 [COPS]). This action allows assigning a preemption priority with an 2789 RSVP request, to provide a device with information which RSVP requests 2790 to accept in case of admission failures. This action specifies a DSCP 2791 value (which provides an associated level of QoS) to set on the flow 2792 that RSVP is requesting. 2794 Since the purpose of this is to augment the behavior specified by the 2795 qosPolicyRSVPAction class, this class SHOULD be used with a 2796 qosPolicyRSVPAction object, and SHOULD NOT be used by itself. 2798 This class can be extended to support additional install decisions that 2799 need to be controlled. 2801 The class definition is as follows: 2803 Snir, Ramberg, Strassner, Cohen expires October 2000 55 2804 Draft-ietf-policy-qos-info-model-01.txt April 2000 2806 NAME qosPolicyRSVPInstallAction 2807 DERIVED FROM policyAction (defined in [PCIM]) 2808 ABSTRACT False 2809 PROPERTIES qpSetDSCPValue, qpSetPreemptionPriority, 2810 qpSetDefendingPriority 2812 8.8.1. The Property qpSetDSCPValue 2814 This property is a non-negative integer that defines the setting of a 2815 DSCP value in the device. In other words, this attribute controls the 2816 remarking (by the device) of the flow signaled by the RSVP request. The 2817 attribute is defined as follows: 2819 NAME qpSetDSCPValue 2820 SYNTAX Integer (constrained to the range 0-63, inclusive) 2822 8.8.2. The Property qpSetDefendingPriority 2824 This property is a non-negative integer, and is used to set the 2825 defending priority within the preemption object (defined in 2826 [RSVP_PREEMP]) of RSVP flows. The attribute is defined as follows: 2828 NAME qpSetDefendingPriority 2829 SYNTAX Integer (must be non-negative) 2831 8.8.3. The Property qpSetPreemptionPriority 2833 This property is a non-negative integer, and is used to set the 2834 preemption priority [RSVP_PREEMP] of RSVP flows. The attribute is 2835 defined as follows: 2837 NAME qpSetPreemptionPriority 2838 SYNTAX Integer (must be non-negative) 2840 8.9. Class qosPolicySimpleCondition (Aux) 2842 A simple condition is composed of an ordered triplet: 2843 2844 The operator used in all condition definitions in this draft is 2845 the 'match' operator. Such simple conditions are evaluated by answering 2846 the question: Does match ? The operator property can 2847 be extended to support other relations between variable and values. 2849 Simple conditions are building blocks for more complex Boolean 2850 conditions. The qosPolicySimpleCondition class is derived from the 2851 policyCondition class in [PCIM]. Simple conditions can be kept in 2852 repositories for reuse. 2854 Snir, Ramberg, Strassner, Cohen expires October 2000 56 2855 Draft-ietf-policy-qos-info-model-01.txt April 2000 2857 The class definition is as follows: 2859 NAME qosPolicySimpleCondition 2860 DERIVED FROM policyCondition (defined in [PCIM]) 2861 ABSTRACT False 2862 PROPERTIES qpOperator, qpVariableAtom, qpValueAtom 2864 8.9.1. The Property qpOperator 2866 This property is a string that defines the relation between a variable 2867 and a value. The default value is �match�, which has the semantics of 2868 'belong to' or 'equal'. The attribute is defined as follows: 2870 NAME qpOperator 2871 SYNTAX String 2872 DEFAULT VALUE 'match' 2874 8.9.2. The Property qpVariableAtom 2876 This property is a reference to an object that defines the variable to 2877 be used in a QoS policy condition. The referenced object SHOULD be a 2878 subclass of the qosPolicyVariable class. The attribute is defined as 2879 follows: 2881 NAME qpVariableAtom 2882 SYNTAX Reference to an object that is a subclass of the 2883 qosPolicyVariable class 2885 8.9.3. The Property qpValueAtom 2887 This property is a reference to an object that defines the value to be 2888 used in a QoS policy condition. The referenced object SHOULD be a 2889 subclass of the qosPolicyValue class. The attribute is defined as 2890 follows: 2892 NAME qpValueAtom 2893 SYNTAX Reference to an object that is a subclass of the 2894 qosPolicyValue class 2896 8.10. Class qosPolicyVariable 2898 Variables are used for building individual conditions. The variable 2899 specifies the property of a flow that should be matched when evaluating 2900 the condition. However, not every combination of a variable and a value 2901 creates a meaningful condition. A source IP address variable can not be 2902 matched against a value that specifies a port number. A given variable 2903 selects the set of matchable value types. 2905 Snir, Ramberg, Strassner, Cohen expires October 2000 57 2906 Draft-ietf-policy-qos-info-model-01.txt April 2000 2908 A variable also limits the set of values within a particular value type 2909 that can be matched against it in a condition. For example, a source- 2910 port variable limits the set of values to represent integers to the 2911 range of 0-65535. Integers outside this range can not be matched to the 2912 16 bits port entity. 2914 The class definition is as follows: 2916 NAME qosPolicyVariable 2917 DERIVED FROM policy (defined in [PCIM]) 2918 ABSTRACT False 2919 PROPERTIES qpVariableName, qpValueTypes, qpVariableDescription, 2920 QpValueConstraints 2922 8.10.1. The Property qpVariableName 2924 This property is a string that is a unique name for the variable. This 2925 is very important, because the QPIM defines a correlation between its 2926 pre-defined variable names and their logical bindings. This correlation 2927 was defined earlier in Table 2. The attribute is defined as follows: 2929 NAME qpVariableName 2930 SYNTAX String, defined in the following table: 2932 8.10.2 The Property qpValueTypes 2934 This property is a string that specifies an unordered list of possible 2935 value types that can be used in a simple condition together with this 2936 variable. The value types are specified by their class names. The list 2937 of class names allows efficient retrieval of the possible set of 2938 relevant values from a repository, and was defined earlier in Table 3. 2939 The attribute is defined as follows: 2941 NAME qpValueTypes 2942 SYNTAX String 2944 8.10.3. The Property qpVariableDescription 2946 This property is a string that provides a textual description of the 2947 variable. The attribute is defined as follows: 2949 NAME qpVariableDescription 2950 SYNTAX String 2952 Snir, Ramberg, Strassner, Cohen expires October 2000 58 2953 Draft-ietf-policy-qos-info-model-01.txt April 2000 2955 8.10.4. The Property qpValueConstraints 2957 This property is a set of references to objects serving as constraints 2958 for this variable. This attribute is defined as follows: 2960 NAME qpValueConstraints 2961 SYNTAX Set of references to objects that constrain this variable 2963 8.11. Class qosPolicyValue 2965 This is an abstract class that serves as the base class for all 2966 subclasses that are used to define value objects in the QPIM. It is 2967 used for defining values and constants used in policy conditions. The 2968 class definition is as follows: 2970 NAME qosPolicyValue 2971 DERIVED FROM policy (defined in [PCIM]) 2972 ABSTRACT True 2973 PROPERTIES 2975 8.12. Class qosPolicyIPv4AddrValue 2977 This class is used to provide a list of IPv4Addresses, hostnames and 2978 address range values. The class definition is as follows: 2980 NAME qosPolicyIPv4AddrValue 2981 DERIVED FROM qosPolicyValue 2982 ABSTRACT False 2983 PROPERTIES qpIPv4AddrList 2985 8.12.1. The Property qpIPv4AddrList 2987 This Property provides an unordered list of strings, each specifying a 2988 single IPv4 address, a hostname, or a range of IPv4 addresses. The ABNF 2989 definition [ABNF] of an IPv4 address is: 2991 IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT 2992 IPv4prefix = IPv4address "/" 1*2DIGIT 2993 IPv4range = IPv4address"-"IPv4address 2994 IPv4maskedaddress = IPv4address","IPv4address 2995 Hostname (as defined in [NAMES]) 2997 Each string entry is either: 2998 1. A single Ipv4address in dot notation as defined above. 2999 Example: 121.1.1.2 3000 2. A single Hostname. Hostname format follows the guidelines and 3001 restrictions specified in [NAMES]. 3002 Example: www.bigcompany.com 3004 Snir, Ramberg, Strassner, Cohen expires October 2000 59 3005 Draft-ietf-policy-qos-info-model-01.txt April 2000 3007 3. An IPv4range address range defined above, specified by a start 3008 address in dot notation and an end address in dot notation, 3009 separated by "-". The range includes all addresses between the 3010 range's start and end addresses, including the start and end 3011 addresses. 3012 Example: 1.1.22.1-1.1.22.5 3013 4. An IPv4maskedaddress address range defined above, specified by an 3014 address and mask. The address and mask are represented in dot 3015 notation separated by a comma ",". 3016 Example: 2.3.128.0,255.255.248.0. 3017 5. An IPv4prefix address range defined above specified by an address 3018 and a prefix length separated by "/". 3019 Example: 2.3.128.0/15 3021 NAME qpIPv4AddrList 3022 SYNTAX String 3023 FORMAT IPv4address | hostname | IPv4addressrange | 3024 IPv4maskedaddress | IPv4prefix 3026 8.13. Class qosPolicyIPv6AddrValue 3028 This class is used to define a list of IPv6 addresses, hostnames, and 3029 address range values. The class definition is as follows: 3031 NAME qosPolicyIPv6AddrValue 3032 DERIVED FROM qosPolicyValue 3033 ABSTRACT False 3034 PROPERTIES qpIPv6AddrList 3036 8.13.1. The Property qpIPv6AddrList 3038 This property provides an unordered list of strings, each specifying an 3039 IPv6 address, a hostname, or a range of IPv6 addresses. IPv6 address 3040 format definition uses the standard address format defined in [IPv6]. 3041 The ABNF definition [ABNF] as specified in [IPv6] is: 3043 IPv6address = hexpart [ ":" IPv4address ] 3044 IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT 3045 IPv6prefix = hexpart "/" 1*2DIGIT 3046 hexpart = hexseq | hexseq "::" [ hexseq ] | "::" [ hexseq ] 3047 hexseq = hex4 *( ":" hex4) 3048 hex4 = 1*4HEXDIG 3049 IPv6range = IPv6address"-"IPv6address 3050 IPv6maskedaddress = IPv6address","IPv6address 3051 Hostname (as defines in [NAMES]) 3053 Snir, Ramberg, Strassner, Cohen expires October 2000 60 3054 Draft-ietf-policy-qos-info-model-01.txt April 2000 3056 Each string entry is either: 3058 1. A single IPv6address as defined above. 3059 2. A single Hostname. Hostname format follows guidelines and 3060 restrictions specified in [NAMES]. 3061 3. An IPv6range address range, specified by a start address in dot 3062 notation and an end address in dot notation, separated by "-". 3063 The range includes all addresses between the range's start and end 3064 addresses, including the start and end addresses. 3065 4. An IPv4maskedaddress address range defined above specified by an 3066 address and mask. The address and mask are represented in dot 3067 notation separated by a comma ",". 3068 5. A single IPv6prefix as defined above. 3070 NAME qpIPv6AddrList 3071 SYNTAX String 3072 FORMAT IPv6address | hostname | IPv6addressrange | 3073 IPv6maskedaddress | IPv6prefix 3075 8.14. Class qosPolicyMACAddrValue 3077 This class is used to define a list of MAC addresses and MAC address 3078 range values. The class definition is as follows: 3080 NAME qosPolicyMACAddrValue 3081 DERIVED FROM qosPolicyValue 3082 ABSTRACT False 3083 PROPERTIES qpMACAddrList 3085 8.14.1. The Property qpMACAddrList 3087 This property provides an unordered list of strings, each specifying a 3088 MAC address or a range of MAC addresses. The 802 MAC address canonical 3089 format is used. The ABNF definition [ABNF] is: 3091 MACaddress = 1*4HEXDIG ":" 1*4HEXDIG ":" 1*4HEXDIG 3092 MACmaskedaddress = MACaddress","MACaddress 3094 Each string entry is either: 3096 1. A single MAC address. Example: 0000:00A5:0000 3097 2. A MACmaskedaddress address range defined specified by an address 3098 and mask. The mask specifies the relevant bits in the address. 3099 Example: 0000:00A5:0000, FFFF:FFFF:0000 defines a range of MAC 3100 addresses in which the first 4 8-bit bytes are equal to 0000:00A5. 3102 NAME qpMACAddrList 3103 SYNTAX String 3104 FORMAT MACaddress | MACmaskedaddress 3106 Snir, Ramberg, Strassner, Cohen expires October 2000 61 3107 Draft-ietf-policy-qos-info-model-01.txt April 2000 3109 8.15. Class qosPolicyStringValue 3111 This class is used to represent a single or set of string values. Each 3112 can have wildcards. The class definition is as follows: 3114 NAME qosPolicyStringValue 3115 DERIVED FROM qosPolicyValue 3116 ABSTRACT False 3117 PROPERTIES qpStringList 3119 8.15.1. The Property qpStringList 3121 This property provides an unordered list of strings, each representing 3122 a single string with wildcards. The asterisk character "*" is used as a 3123 wildcard, and represents an arbitrary sub-string replacement. For 3124 example, the value "abc*def" match "abcxyzdef", and the value 3125 "abc*def*" match "abcxxxdefyyyzzz". The syntax definition is identical 3126 to the substring assertion syntax defined in [LDAP_ATTR]. If the 3127 asterisk character is required as part of the string value itself, it 3128 MUST be quoted as described in section 4.3 of [LDAP_ATTR]. 3130 The attribute definition is as follows: 3132 NAME qpStringList 3133 SYNTAX String 3135 8.16 Class qosPolicyBitStringValue 3137 This class is used to represent a single or set of bit string values. 3138 The class definition is as follows: 3140 NAME qosPolicyBitStringValue 3141 DERIVED FROM qosPolicyValue 3142 ABSTRACT False 3143 PROPERTIES qpBitStringList 3145 8.16.1. The Property qpBitStringList 3147 This property provides an unordered list of strings, each representing 3148 a single bit string or a set of bit strings. The number of bits 3149 specified SHOULD equal the number of bits of the expected variable. For 3150 example, for an 8-bit byte variable, 8 bits should be specified. If the 3151 variable does not have a fixed length, the bit string should be matched 3152 against the variable most significant bit string. The formal 3153 definitions are: 3155 binary-digit = "0" / "1" 3156 bitstring = 1*binary-digit 3157 maskedBitString = bitstring","bitstring 3159 Snir, Ramberg, Strassner, Cohen expires October 2000 62 3160 Draft-ietf-policy-qos-info-model-01.txt April 2000 3162 Each string entry is either: 3164 1. A single bit string. Example: 00111010 3165 2. A range of bit strings specifies using a bit string and a bit 3166 mask. The bit string and mask properties have the same number of 3167 bits specified. The mask bit string specifies the significant bits 3168 in the bit string value. For example, 110110, 100110 and 110111 3169 would match the maskedBitString 100110,101110 but 100100 would 3170 not. 3172 NAME qpBitStringList 3173 SYNTAX String 3174 FORMAT bitString | maskedBitString 3176 8.17. Class qosPolicyDNValue 3178 This class is used to represent a single or set of Distinguished Name 3179 values, including wildcards. A Distinguished Name is a name that can be 3180 used as a key to retrieve an object. This value can be used in 3181 comparison to reference values carried in RSVP policy objects, as 3182 specified in [IDENT]. 3184 The class definition is as follows: 3186 NAME qosPolicyDNValue 3187 DERIVED FROM qosPolicyValue 3188 ABSTRACT False 3189 PROPERTIES qpDNList 3191 8.17.1. The Property qpDNList 3193 This property provides an unordered list of Distinguished Name 3194 references to objects. The attribute is defined as follows: 3196 NAME qpDNList 3197 SYNTAX List of Distinguished Names, each of which serves as a 3198 reference to another object. 3200 8.18. Class qosPolicyAttributeValue 3202 This class is used to represent a single or set of property values in 3203 an object. This value can be used in conjunction with reference values 3204 carried in RSVP objects, as specified in [IDENT]. The property name is 3205 used to specify which of the properties in the object is being used as 3206 the condition. The value of this property will then be retrieved, and a 3207 match (which is dependent on the property name) will be used to see if 3208 the condition is satisfied or not. 3210 Snir, Ramberg, Strassner, Cohen expires October 2000 63 3211 Draft-ietf-policy-qos-info-model-01.txt April 2000 3213 For example, suppose a User class has a multi-valued Property called 3214 'member-of' that lists the names of groups that this user belongs to. 3215 Suppose this property uses caseIgnoreMatch matching. A simple condition 3216 can be constructed to match the reference carried in an RSVP Identity 3217 policy object to a qosPolicyAttributeValue with the following 3218 characteristics: 3219 qpAttributeName="member-of", 3220 qpAttributeValueList = "group-A". 3222 An Identity policy object carrying the following reference: 3223 "OU=Sales, CN=J. Smith, O=Widget Inc." 3224 will match this simple condition only if J. Smith belongs to group-a. 3226 The class definition is as follows: 3228 NAME qosPolicyAttributeValue 3229 DERIVED FROM qosPolicyValue 3230 ABSTRACT False 3231 PROPERTIES qpAttributeName, qpAttributeValueList 3233 8.18.1. The Property qpAttributeName 3235 This attribute defines the name of the property that the list of values 3236 should be compared against. The attribute is defined as follows: 3238 NAME qpAttributeName 3239 SYNTAX String 3241 8.18.2. The Property qpAttributeValueList 3243 This attribute contains a list of property values. Each value is 3244 compared to a value of the property specified by qpAttributeName. The 3245 attribute is defined as follows: 3247 NAME qpAttributeValueList 3248 SYNTAX String 3250 8.19. Class qosPolicyIntegerValue 3252 This class provides a list of integer and integer range values. 3253 Integers of arbitrary sizes can be represented. For a given variable, 3254 the set of possible ranges of integer values allowed is specified via 3255 the variable's qpValueConstraints Property. The class definition is as 3256 follows: 3258 NAME qosPolicyIntegerValue 3259 DERIVED FROM qosPolicyValue 3260 ABSTRACT False 3261 PROPERTIES qpIntegerList 3263 Snir, Ramberg, Strassner, Cohen expires October 2000 64 3264 Draft-ietf-policy-qos-info-model-01.txt April 2000 3266 8.19.1. The Property qpIntegerList 3268 This property provides an unordered list of integers and integer range 3269 values. The format of this property can take on of the following forms: 3271 1. An integer value. 3272 2. A range of integers. The range is specifies by a start integer and 3273 an end integer separated by "-". The range includes all integers 3274 between start and end integers, including the start and end 3275 integers. 3277 To represent a range of integers that is not bounded, the reserved word 3278 INFINITY can be used as the end range integer. 3280 The ABNF definition [ABNF] is: 3282 integer = 1*DIGIT | "INFINITY" 3283 integerrange = integer"-"integer 3285 Using ranges the operators greater-than, greater-than-or-equal-to, 3286 less-than and less-than-or-equal-to can be expressed. 3288 NAME qpIntegerList 3289 SYNTAX String 3290 FORMAT integer | integerrange 3292 8.20. Class qosPolicyPHBSet 3294 The qosPolicyPHBSet is a class that serves as a named container for 3295 qosPolicyPHB objects. A single PHB set is associated with a QoS domain 3296 using the domain property defined in the qosPolicyDomain object. 3297 Instances of the qosNamedPolicyContainer class can override the 3298 domain's PHB set by referencing another PHB set via the qosPolicyPHBSet 3299 Property or by aggregation of a qosPolicyPHBSet object. 3301 The class is defined as follows: 3303 NAME qosPolicyPHBSet 3304 DERIVED FROM policy (defined in [PCIM]) 3305 ABSTRACT False 3306 PROPERTIES 3308 8.21. Class qosPolicyPHB 3310 The qosPolicyPHB Class is an abstract class that extends the policy 3311 class (defined in the [PCIM]) with the information required to model 3312 a PHB service class. The PHB service class is an abstraction over 3313 device-specific parameters. 3315 Snir, Ramberg, Strassner, Cohen expires October 2000 65 3316 Draft-ietf-policy-qos-info-model-01.txt April 2000 3318 The class is defined as follows: 3320 NAME qosPolicyPHB 3321 DERIVED FROM policy (defined in [PCIM]) 3322 ABSTRACT True 3323 PROPERTIES qpDSCP 3325 8.21.1. The Property qpDSCP 3327 This property is an integer, constrained to have a value in the range 3328 0..63 inclusive, for representing the service classes in the QoS policy 3329 domain that are used for traffic classification. The attribute is 3330 defined as follows: 3332 NAME qpDSCP 3333 SYNTAX Integer (must be in the range 0..63, inclusive) 3335 8.22 Class qosPolicyMeter 3337 This class models a meter, as defined in (for example) 3338 [DIFF-SERV-ARCH]. Meters measure the temporal properties of the stream 3339 of packets selected by a classifier against a traffic profile. 3341 A meter can be shared between different policy rules. A meter shared by 3342 more than one policy rule resides in a repository and is referenced by 3343 all sharing rules. 3345 The class is defined as follows: 3347 NAME qosPolicyMeter 3348 DERIVED FROM policy (defined in [PCIM]) 3349 ABSTRACT True 3350 PROPERTIES 3352 Snir, Ramberg, Strassner, Cohen expires October 2000 66 3353 Draft-ietf-policy-qos-info-model-01.txt April 2000 3355 9. Extending the QoS Policy Schema 3357 The following subsections provide general guidance on how to create a 3358 domain-specific information model derived from the QPIM by extending 3359 the QoS policy classes. 3361 9.1. Extending qosPolicyValue 3363 The qosPolicyValue class and its subclasses describe the common 3364 value types used in the QPIM. When other specific types are required, 3365 such as a floating-point numbers, the required class SHOULD be derived 3366 from the qosPolicyValue class and properties that contain the 3367 corresponding values SHOULD be added. 3369 Notice that in many cases, using the qosPolicyAttributeValue class 3370 allows the definition of non-standard policy atoms without extending 3371 the qosPolicyValue class. 3373 9.2. Extending qosPolicySimpleCondition 3375 The qosPolicySimpleCondition class is used to describe a single atomic 3376 Boolean condition. For Boolean conditions that are not structured as 3377 the ordered triple , a new type of 3378 condition class SHOULD be defined. An example would be a unary 3379 condition. 3381 Subclassing could be done using either the policyCondition or 3382 qosPolicySimpleCondition classes as the superclass. 3384 9.3. Extending qosPolicyAction 3386 The Qos Policy actions classes defined in the QoS Policy Schema 3387 Includes the following types of actions: 3389 Provisioning actions: 3390 * Marking 3391 * Policing, shaping and remarking according to a traffic profile 3393 Signaling RSVP action: 3394 * RSVP policy admission 3395 * RSVP signal control extensions 3396 * RSVP flow control extensions 3398 Additional actions could be associated with QoS policy rules by 3399 extending the policyAction class with the appropriate properties. 3401 Snir, Ramberg, Strassner, Cohen expires October 2000 67 3402 Draft-ietf-policy-qos-info-model-01.txt April 2000 3404 10. Security Considerations 3406 The security considerations for this document are the same as those of 3407 the [PCIM]. 3409 11. Acknowledgments 3411 The authors wish to thank the input of the participants of the Policy 3412 Framework working group, and especially Bob Moore and Alex Wang for 3413 their helpful contributions. 3415 12. References 3417 [ABNF] Crocker, D., and P. Overell, "Augmented BNF for 3418 Syntax Specifications: ABNF", RFC 2234, November 3419 1997. 3421 [CL] J. Wroclawski, "Specification of the Controlled-Load 3422 Network Element Service", RFC2211, September 1997 3424 [COPS] D. Durham, J. Boyle, R . Cohen, S. Herzog, R. Rajan, A. 3425 Sastry, "The COPS (Common Open Policy Service) Protocol", 3426 RFC2748 3428 [COPSRSVP] S. Herzog, J. Boyle, R . Cohen, D. Durham, R. Rajan, A. 3429 Sastry, "COPS Usage for RSVP", RFC2749 3431 [DEREF] R. Moats, J. Maziarski, J. Strassner, "Extensible Match 3432 Rules to Dereference Pointer", Internet Draft 3433 3435 [DIFF-SERV-ARCH] S. Blake D. Blake, "An Architecture for 3436 Differentiated Services", RFC2475 3438 [DNDEF] Wahl, M., Kille, S., and T. Howes, "Lightweight 3439 Directory Access Protocol (v3): UTF-8 String 3440 Representation of Distinguished Names", RFC 2253, 3441 December 1997. 3443 [GS] S. Shenker, C. Partridge, R. Guerin, "Specification 3444 of the Guaranteed Quality of Service", RFC2212, 3445 September 1997 3447 [IDNET] S. Yadav, R. Yavatkar, R. Pabbati, P. Ford, T. 3448 Moore, S. Herzog, "Identity Representation for 3449 RSVP", RFC 2752, January 2000 3451 [IPv6] R. Hinden, S. Deering, "IP Version 6 Addressing 3452 Architecture", RFC2373, July 1998 3454 Snir, Ramberg, Strassner, Cohen expires October 2000 68 3455 Draft-ietf-policy-qos-info-model-01.txt April 2000 3457 [LDAP_ATTR] M. Wahl, A. Coulbeck, " Lightweight Directory Access 3458 Protocol (v3): Attribute Syntax Definitions", RFC 2252 3460 [NAME] P. Mockapetris, " Domain names - implementation and 3461 specification", RFC1035 3463 [PCIM] J. Strassner, E. Ellesson, B. Moore, "Policy Framework Core 3464 Information Model", Internet Draft 3465 3467 [PHBLDAP] R. Cohen, Y. Snir, J. Strassner, �LDAP schema for Domain 3468 Per Hop Behavior Set�, Internet Draft 3469 3471 [PHBSET] R. Cohen, A. Zavalkovsky, N. Elfassy, �Domain Per Hop 3472 Behavior Set Specification�, Internet Draft 3473 3475 [PFSCHEMA] J. Strassner, E. Ellesson, B. Moore, "Policy Framework LDAP 3476 Core Schema", Internet Draft 3477 3479 [PIB] M. Fine, K. McCloghrie, J. Seligson, K. Chan, S. Hahn, A. 3480 Smith, "Quality of Service Policy Information Base", 3481 Internet Draft 3483 [QOSDEV] J. Strassner, W. Weiss, D. Durham, A. Westerinen, 3484 �Information Model for Describing Network Device QoS 3485 Mechanisms�, Internet Draft 3486 3488 [QOSSCHEMA] Y. Snir, Y Ramberg, J. Strassner, R. Cohen, �QoS 3489 Policy Schema�, Internet Draft 3490 3492 [RSVP] Braden, R. ed., "Resource ReSerVation Protocol (RSVP) - 3493 Functional Specification.", IETF RFC 2205, 3494 Proposed Standard, Sep. 1997. 3496 [RSVP-IS] J. Wroclawski, "The Use of RSVP with IETF Integrated 3497 Services", RFC2210, September 1997 3499 [RSVP_PREEMP] Shai Herzog, "Signaled Preemption Priority Policy 3500 Element", RFC2751 3502 [TERMS] S. Bradner, "Key words for use in RFCs to Indicate 3503 Requirement Levels", Internet RFC 2119, March 1997. 3505 Snir, Ramberg, Strassner, Cohen expires October 2000 69 3506 Draft-ietf-policy-qos-info-model-01.txt April 2000 3508 13. Author's Addresses 3510 Yoram Snir 3511 Cisco Systems 3512 4 Maskit Street 3513 Herzliya Pituach, Israel 46766 3514 Phone: +972-9-970-0085 3515 Fax: +972-9-970-0219 3516 E-mail: ysnir@cisco.com 3518 Yoram Ramberg 3519 Cisco Systems 3520 4 Maskit Street 3521 Herzliya Pituach, Israel 46766 3522 Phone: +972-9-970-0081 3523 Fax: +972-9-970-0219 3524 E-mail: yramberg@cisco.com 3526 John Strassner 3527 Cisco Systems 3528 Bldg 15 3529 170 West Tasman Drive 3530 San Jose, CA 95134 3531 Phone: +1-408-527-1069 3532 Fax: +1-408-527-2477 3533 E-mail: johns@cisco.com 3535 Ron Cohen 3536 Cisco Systems 3537 4 Maskit Street 3538 Herzliya Pituach, Israel 46766 3539 Phone: +972-9-970-0064 3540 Fax: +972-9-970-0219 3541 E-mail: ronc@cisco.com 3543 14. Full Copyright Statement 3545 This document and translations of it be copied and furnished to others, 3546 and derivative works that comment on or otherwise explain it or assist 3547 in its implementation be prepared, copied, published and distributed, 3548 in whole or in part, without restriction of any kind, provided that the 3549 above copyright notice and this paragraph are included on all such 3550 copies and derivative works. However, this document itself not be 3551 modified in any way, such as by removing the copyright notice or 3552 references to the Internet Society or other Internet organizations, 3553 except as needed for the purpose of developing Internet standards in 3554 which case the procedures for copyrights defined in the Internet 3555 Standards process PROPERTIES be followed, or as required to translate 3556 it into languages other than English. 3558 Snir, Ramberg, Strassner, Cohen expires October 2000 70 3559 Draft-ietf-policy-qos-info-model-01.txt April 2000 3561 The limited permissions granted above are perpetual and will not be 3562 revoked by the Internet Society or its successors or assigns. 3564 This document and the information contained herein is provided on an 3565 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 3566 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 3567 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 3568 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 3569 FITNESS FOR A PARTICULAR PURPOSE 3571 Snir, Ramberg, Strassner, Cohen expires October 2000 71