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