idnits 2.17.1 draft-weiss-policy-device-qos-model-00.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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 39 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 40 pages 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 7 instances of too long lines in the document, the longest one being 1 character in excess of 72. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 1999) is 9076 days in the past. Is this intentional? 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: 'CIM' is mentioned on line 969, but not defined == Unused Reference: 'DIFFARCH' is defined on line 1543, but no explicit reference was found in the text == Unused Reference: 'RAPFRAME' is defined on line 1553, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2475 (ref. 'DIFFARCH') ** Obsolete normative reference: RFC 2598 (ref. 'EF') (Obsoleted by RFC 3246) -- Possible downref: Non-RFC (?) normative reference: ref. 'RAPFRAME' ** Obsolete normative reference: RFC 1825 (ref. 'IPSEC') (Obsoleted by RFC 2401) -- Possible downref: Non-RFC (?) normative reference: ref. 'RED' Summary: 9 errors (**), 0 flaws (~~), 9 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 ION/IPng Working Groups W. Weiss (Lucent) 2 INTERNET-DRAFT J. Strassner (Cisco) 3 A. Westerinen (Microsoft) 4 June 1999 6 Terminology for describing network policy and services 8 Specification 10 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet- Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Abstract 35 The purpose of this draft is to define an information model that 36 describes the attributes common to the forwarding characteristics of 37 Differentiated Services QoS and RSVP. Once this information model is 38 defined, then a separate draft can be written to refine the core 39 information model defined in the Policy Framework working group to 40 model policies that control the configuration of DS-capable network 41 devices. This approach enables the definition of policies that can be 42 used to define Services for DiffServ-capable devices and networks. 44 The approach taken enables a common set of attributes to be defined 45 that can be used to model Differentiated Services QoS classes at the 46 behavioral level. Vendors can then map these attributes, either 47 directly or using a proxy agent like a PIB, to their own device- 48 specific implementations. 50 This draft also concentrates on separating the concepts of state and 51 configuration. Configuration attributes are used to describe the 52 desired state of the device, whereas state attributes reflect the 53 actual state of the device. Both state as well as configuration 54 attributes are necessary in order to model and manage QoS at the 55 device level. 57 In addition, this draft derives the QoS schema from the core Networks 58 schema defined in the DMTF rather than the core Policy schema. In 59 order to support broader policies that can encompass not only QoS, 60 but also security, address management, network topology management, 61 and routing policies to name a few, it makes more sense to derive the 62 attributes from a schema that is already modeling these devices and 63 services rather than reinventing them under the umbrella of the 64 policy schema. 66 Finally, this draft considers various aggregation methods for 67 describing groups of devices and groups of interfaces that require a 68 common configuration. 70 A future iteration of this draft will expand the information model to 71 include modeling and managing the signaling characteristics of RSVP. 72 A separate draft will map the information model presented in this 73 draft to a form suitable for implementation in a directory that uses 74 LDAP as its access protocol. 76 Table of Contents 78 Status of this memo 1 79 Copyright Notice 1 80 Abstract 1 81 Definition of Key Word Usage 2 82 Table of Contents 2 84 1. Introduction 86 2. Approach 87 2.1 Common Needs Of DiffServ and RSVP 88 2.2 Specific Needs of DiffServ 89 2.3 Specific Needs of RSVP 91 3. Methodology 92 3.1 Level of Abstraction for Expressing QoS Policies 93 3.2 Level of Abstraction for Defining QoS Attributes and Classes 94 3.3 Characterization of QoS Attributes 95 3.4 Identifying Common Shared Policies 96 3.5 QoS Schema Derivation 97 3.6 Attribute Representation 99 4. The Class Hierarchy 100 4.1 Structure of the Class Hierarchy 101 4.2 Class and Attribute Definitions 102 4.2.1 ManagedSystemElement 103 4.2.2 LogicalElement 104 4.2.3 Service 105 4.2.4 NetworkService 106 4.2.5 ForwardingService 107 4.2.6 DiffServService 108 4.2.6.1 The Attribute ConsumedBandwidth 109 4.2.6.1 The Attribute ConsumedPackets 110 4.2.6.1 The Attribute CurrentBandwidth 111 4.2.6.1 The Attribute CurrentDelay 112 4.2.6.1 The Attribute LostPackets 113 4.2.7 AFService 114 4.2.7.1 The Attribute AssignedBandwidth 115 4.2.7.2 The Attribute MaxDelay 116 4.2.7.3 The Attribute SmoothingInterval 117 4.2.7.4 The Relationship AFDropPrecedenceServices 118 4.2.8 AFEdgeService 119 4.2.9 EFService 120 4.2.9.1 The Attribute DSCP 121 4.2.9.2 The Attribute MaxAssignedBandwidth 122 4.2.9.3 The Attribute MaxDelay 123 4.2.9.4 The Relationship EFDropPrecedenceServices 124 4.2.10 EFEdgeService 125 4.2.11 PrecedenceService 126 4.2.11.1 The Attribute ToS 127 4.2.12 IntServService 128 4.2.13 DropPrecedenceService 129 4.2.13.1 The Attribute DSCP 130 4.2.13.2 The Attribute InitialLossLevelStart 131 4.2.13.3 The Attribute InitialLossLevelStop 132 4.2.13.4 The Attribute FullLossLevelStart 133 4.2.13.5 The Attribute FullLossLevelStop 134 4.2.14 Configuration 135 4.2.15 BehaviorConfiguration 136 4.2.16 AFConfiguration 137 4.2.16.1 The Attribute AssignedBandwidth 138 4.2.16.2 The Attribute MaxDelay 139 4.2.16.3 The Attribute SmoothingInterval 140 4.2.16.4 The Relationship AFConfigDropPrecedenceServices 141 4.2.17 AFEdgeConfiguration 142 4.2.18 AFRoleConfiguration 143 4.2.19 AFVendorConfiguration 144 4.2.19.1 The Multi-valued Attribute Constraint 145 4.2.19.2 The Attribute ConstraintEncoding 146 4.2.20 EFConfiguration 147 4.2.20.1 The Attribute DSCP 148 4.2.20.2 The Attribute MaxAssignedBandwidth 149 4.2.20.3 The Attribute MaxDelay 150 4.2.20.4 The Relationship EFConfigDropPrecedenceServices 151 4.2.21 EFEdgeConfiguration 152 4.2.22 EFRoleConfiguration 153 4.2.23 EFVendorConfiguration 154 4.2.23.1 The Multi-valued Attribute Constraint 155 4.2.23.2 The Attribute ConstraintEncoding 156 4.2.24 IntServConfiguration 157 4.2.25 DropPrecedenceConfiguration 158 4.2.26 PrecedenceConfiguration 159 4.2.26.1 The Attribute ToS 161 5. Mapping to Example Policies 163 6. Security Considerations 165 7. Acknowledgments 166 8. References 167 9. Author's Addresses 168 10. Full Copyright Statement 169 1. Introduction 171 Policy conditions and actions have two principle components: operands 172 and operators. Operands can be constants or variables. You can't 173 construct a policy without specifying what operands you want to exam- 174 ine and what operands you want to change. Operands can be high level 175 like Joe (a user) or Gold (a service). Operands can also be low 176 level like IP Address or a queue's bandwidth allocation. Irrespec- 177 tive of what level the operands are specified at, they still need to 178 be specified and standardized. 180 The second component of policy conditions and actions is a set of 181 operators. Operators can express relationships (greater then, in the 182 set, boolean OR, etc.) or assignements. Together, operators and 183 operands can express a variety of conditions and actions: 185 If Bob is an Engineer... 186 If the Src IP address is in the Marketing Subnet... 187 Set Joe's ip address to 2.3.4.5 188 Limit the bandwidth of application x to 10 Mb 190 We recognize that the definition of operator semantics are critical 191 to the definition of policies. However, the definition of these 192 operators is beyond the scope of this document. Rather, this draft 193 takes the first steps in identifying and standardizing a set of 194 operands for use in policies. 196 2. Approach 198 QoS activities in the IETF have mainly focused in two areas: 199 Integrated Services and Differentiated Services. This draft initially 200 focuses on the specification of QoS attributes and classes for the 201 policy management of Differentiated Services capabilities. 203 2.1. Common Needs Of DiffServ and RSVP 205 First we consider the common needs for RSVP and DiffServ. RSVP has 206 two principle components. One component is embedded in the forwarding 207 engine of the networking device. Its functions include the 208 classification and policing of individual flows and scheduling 209 admitted packets for the outbound link. The other component of RSVP 210 is the management of the signaling protocol (e.g., PATH and RESV 211 messages). This component processes reservation requests, manages 212 bandwidth, outsources decision making to policy servers, and 213 interacts with Routing Table manager. We will take RSVP into 214 consideration when defining the schema structure. As this draft 215 initially focuses on the forwarding engine, elements of RSVP 216 applicable to the forwarding engine will be considered in the 217 structure of the schema. 219 This draft focuses on a small subset of the QoS policy problem in 220 hopes of constructing a methodology that can be adapted for other 221 aspects of QoS and policy construction in general. Hence, RSVP will 222 not be considered in any detail in this iteration of the draft. 224 DiffServ operates exclusively in the forwarding engine. It has all 225 the same components of the RSVP forwarding engine with two major 226 differences. First, DiffServ performs classification based solely on 227 the DSCP field while RSVP examines a subset of a standard flow's 228 addressing 5-tuple. There are special cases in DiffServ where the 229 addressing 5-tuple can be examined. Most notably, this can occur at 230 the boundary between a DS domain and a non-DS domain. However, most 231 routers in a DiffServ domain will only need to classify based on the 232 DSCP field. 234 The second difference between RSVP and DiffServ is that the effects 235 of RSVP on the forwarding engine are more dynamic because each newly 236 admitted RSVP reservation requires a reconfiguration of the 237 forwarding engine. In contrast, DiffServ requires far fewer changes 238 to the forwarding engine after the PHBs have been configured. 240 The approach advocated by the authors for the creation of policies is 241 to first identify the attributes with which policies are to be 242 constructed. These attributes are the parameters to expressions that 243 are necessary to construct policies. There is also a parallel desire 244 to define the operators, relations, precedence constructs necessary 245 to construct the conditions and actions proposed by the core policy 246 schema. These efforts are beyond the scope of this document. However, 247 this aspect of the policy schema will be addressed in a subsequent 248 document. 250 2.1. Specific Needs Of DiffServ 252 DiffServ-specific rules can focus on two particular areas: the core 253 of the network and the edges of the network. The attributes used to 254 manipulate QoS capabilities in the core of the network primarily 255 address the behavioral characteristics of each supported DiffServ 256 class (or queue). At the edges of the DiffServ network, the 257 additional complexities of flow classification, policing, RSVP 258 mappings, remarkings, and billing have to be considered. In addition, 259 the standards for edges of the DiffServ network need more detail 260 before the edges can be incorporated in the policy model. Therefore, 261 this draft will initially focus on the core of the DiffServ network. 262 However, it is expected that as the DiffServ standards evolve to 263 better define the sematics of edge devices, these attributes will 264 also be added to the QoS schema. 266 2.1. Specific Needs Of RSVP 268 This first iteration of this document will focus exclusively on the 269 forwarding aspects of network QoS. Therefore, while the forwarding 270 aspects of RSVP will be considered, the management of the RSVP 271 signaling protocol will not be considered. This will be considered in 272 a future iteration of this draft. 274 3. Methodology 276 As there is a clear need to define QoS attributes from which to 277 construct policies, there are some very basic issues that need to be 278 considered. Considering these issues should help to construct the 279 proper schema for QoS attributes as well as a general Policy schema. 281 3.1 Level of Abstraction for Expressing QoS Policies 283 The first issue requiring consideration is the level of abstraction 284 at which QoS policies should be expressed. If we consider policies as 285 rules used to react to events and manipulate attributes or generate 286 new events, this concept can be applied as broadly as a business goal 287 and as specifically as an interaction within a device. An example of 288 business level policy might be: from 1:00 pm PST to 7:00 am EST sell 289 off 40% of capacity on the open market. In contrast, a device 290 specific policy might be: if the queue depth grows at a geometric 291 rate over a specified duration, trigger a potential link failure 292 event. 294 As policies are a function of parameters (attributes) and operators 295 (boolean, arithmetic, relational, etc.), both need to be defined in 296 order to construct policies that are broadly implementable. If the 297 parameters to the rules are specified too narrowly, they will reflect 298 the individual implementations of QoS in each device. As there is 299 currently little consensus in the industry on what the correct 300 implementation model for QoS is, most defined attributes would only 301 be applicable to the unique characteristics of a few individual 302 devices. Lastly, standardizing all of these potential implementation 303 alternatives would be a never-ending task as new implementations 304 appear on the market. 306 In contrast, if you start with a business policy like "Bob gets Gold 307 Service," that is not enough. We also have to define the service 308 semantics if we want to have uniform application of the policy in the 309 network devices. Any service definition would have to be grounded in 310 semantics like Delay, Jitter, Bandwidth, Reliability, Loss, Billing, 311 and over-subscription rules, just to name a few. Getting a written 312 agreement to the service semantics of Gold Service would not only be 313 extremely painful given the broad number of possible combinations, 314 but it would also limit the number of business policies available to 315 network administrators. 317 3.2 Level of Abstraction for Defining QoS Attributes and Classes 319 We therefore propose that the Policy Framework Working Group first 320 focus on those policies that define the Services for DiffServ capable 321 devices and networks. This means that we will need to standardize the 322 attributes that are needed to support policies at the services level. 323 For example, to preserve the Delay characteristics committed to the 324 end-user, a network administrator may wish to create policies that 325 monitor the queue depths in a device and adjust resource allocations 326 when delay budgets are at risk (perhaps as a result of a network 327 topology change). Another example could be the criteria for allowing 328 over-subscription of a service and the consequences (notify billing 329 agent or terminate session if network characteristics change). This 330 has the benefit of maximizing the flexibility that network 331 administrators have in defining new services. In addition, once the 332 policies for the services are defined, it is relatively easy for 333 network administrators to construct policies that define business 334 goals on top of the policies that define the service goals. 336 As mentioned above, the one obstacle in creating service-oriented 337 policies is the issue of supporting diverse implementations of QoS. 338 The solution is to define the QoS attributes at the behavioral level. 339 For DiffServ, this means that we must define the attributes that 340 represent the characteristics of the DiffServ PHBs. Just as it is up 341 to vendors to map PHBs to individual implementations, it is up to 342 these same vendors to map the attributes necessary to monitor and 343 manage the PHB to the specific vendor's implementation of the 344 behavior. This mapping can either be accommodated by a proxy agent 345 like a PIB, or it can be supported directly in the device. 347 3.3 Characterization of QoS Attributes 349 The QoS attributes and container classes will be described in more 350 detail in section 4. However, we should consider the basic 351 characteristics of the attributes to understand the methodology for 352 representing them. 354 There are essentially two types of attributes, state and 355 configuration. Configuration attributes describe the desired state 356 of the device. State attributes describe the actual state of the 357 device. Configuration attributes include desired or proposed 358 thresholds, bandwidth allocations, and classification characteristics 359 (more rules...). State attributes include the current actual value of 360 these configuration attributes in devices as well as attributes that 361 represent dynamic state (queue depths, excess capacity consumption, 362 loss rates, and so forth). 364 One should note that state attributes tend to be device-specific. In 365 contrast, a configuration attribute can be represented and applied to 366 a set of devices (e.g., all devices in the same domain that share the 367 same AS number, or all core devices that share the same delay bound 368 for a specific service). This suggests that the schema for 369 configuration attributes will not be the same as the schema that 370 supports state attributes. 372 3.4 Identifying Common Shared Policies 374 Another issue that arises is how to distinguish policies for 375 individual devices or even components of a device from policies that 376 apply to a set of devices. These contextual issues depend on more 377 than just the policy schema in order for them to function properly. 378 Hence, ongoing efforts in the DMTF to define devices, services, 379 users, groups, and collections of devices are all relevant to the 380 proper construction of a policy model. Context is a key aspect of 381 policies that still requires a great deal more work. The next 382 iteration of this draft will include some preliminary results from 383 these modeling efforts. 385 3.5 QoS Schema Derivation 387 The question of contexts also begs the question of what core model 388 QoS attributes should be derived from. Current thinking is that QoS 389 is part of the policy model. However, QoS is fundamentally a set of 390 characteristics of a networking device. It is supported with 391 schedulers, classifiers, policers, and buffer managers. Similarly, 392 security is also a characteristic of devices, as authentication and 393 encryption capabilities represent services that networked devices 394 perform (irrespective of interactions with policy servers). As such, 395 we argue that QoS attributes should be part of a networking device 396 schema rather than a policy schema. Although a policy schema may use 397 QoS attributes to define policies, the policy schema really needs to 398 focus on the semantics of representing the policy itself (conditions, 399 actions, operators, etc.). However, this does not preclude the Policy 400 Framework working group from standardizing the QoS schema. While this 401 iteration of this draft concentrates on defining an information model 402 that can represent DiffServ QoS, the ultimate goal is to be able to 403 apply policies that control these features in network devices. 405 3.6 Attribute Representation 407 The last issue to be considered is the question of how attributes are 408 represented. If QoS attributes are represented as absolute numbers 409 (e.g., Class AF2 gets 2 Mbs of bandwidth), it is more difficult to 410 make them uniform across multiple ports in a device or multiple 411 devices because of the broad variation in link capacities. However, 412 expressing attributes in relative or proportional terms (e.g., Class 413 AF2 gets 5% of the total link bandwidth) makes it more difficult to 414 express certain types of conditions and actions, such as: 416 (If ConsumedBandwidth = AssignedBandwidth Then ...). 418 There are really three alternatives to address this problem. 419 First, multiple attributes can be defined to express the same 420 value in various forms. This idea has been rejected because of the 421 likelihood of inconsistencies between the attributes. The second 422 alternative is to create multi-modal attributes that express the 423 same value but in different terms based on the access or 424 assignment mode. This option was rejected because it significantly 425 complicates the model and is impossible to express in current 426 directory access protocols (e.g., LDAP). The last option is to 427 express all attributes in absolutes, but make the operators in the 428 policy schema more sophisticated. Thus, to represent a percentage, 429 division and multiplication operators are required (e.g., Class 430 AF2 gets .05 * the total link bandwidth). This is the approach 431 that has been taken in this draft. 433 4. The Class Hierarchy 435 The following sections describe the class hierarchy of the 436 information model for modeling QoS at the device level. Section 4.1 437 defines the structure of the class hierarchy, and section 4.2 defines 438 the classes and their attributes that make up this class hierarchy. 440 4.1 Structure of the Class Hierarchy 442 This draft defines two different class hierarchies that are not 443 necessarily rooted from the same point in the overall schema. 444 However, it is intended that these two hierarchies be used together 445 to control and administer devices that are running Differentiated and 446 Integrated Services. Therefore, we propose one class hierarchy to 447 manage the state of these services, and a different class hierarchy 448 to manage the configuration of these services. Both of these 449 hierarchies are derived from the Common Information Model, and are 450 compatible with the Directory Enabled Networks (DEN) effort. 452 The structure of the Class Hierarchy for managing the state of 453 Differentiated and Integrated Services is as follows: 455 | 456 +--ManagedSystemElement 457 | | 458 | +--LogicalElement 459 | | | 460 | | +--Service 461 | | | | 462 | | | +--NetworkService 463 | | | | | 464 | | | | +--ForwardingService 465 | | | | | | 466 | | | | | +--DiffServService 467 | | | | | | | 468 | | | | | | +--AFService 469 | | | | | | | | 470 | | | | | | | +--AFEdgeService 471 | | | | | | | 472 | | | | | | +--EFService 473 | | | | | | | | 474 | | | | | | | +--EFEdgeService 475 | | | | | | | 476 | | | | | | +--PrecedenceService 477 | | | | | | 478 | | | | | +--IntServService 479 | | | | | | 480 | | | | | +--DropPrecedenceService 481 The structure of the Class Hierarchy for managing the configuration 482 of Differentiated and Integrated Services is as follows: 484 | 485 +--Configuration 486 | | 487 | +--BehaviorConfiguration 488 | | | 489 | | +--AFConfiguration 490 | | | | 491 | | | +--AFEdgeConfiguration 492 | | | | | 493 | | | | +--AFRoleConfiguration 494 | | | | | 495 | | | | +--AFVendorConfiguration 496 | | | 497 | | +--EFConfiguration 498 | | | | 499 | | | +--EFEdgeConfiguration 500 | | | | | 501 | | | | +--EFRoleConfiguration 502 | | | | | 503 | | | | +--EFVendorConfiguration 504 | | | 505 | | +--IntServConfiguration 506 | | | 507 | | +--DropPrecedenceConfiguration 508 | | | 509 | | +--PrecedenceConfiguration 511 4.2 Class and Attribute Definitions 513 4.2.1 ManagedSystemElement 515 This is an abstract class that is defined in the Core Model of CIM. 516 This is the base class for the System Element hierarchy. Any 517 distinguishable component of a System is a candidate for inclusion in 518 this class, including physical components (e.g., chips and cards) and 519 logical components (e.g., software components, services, and other 520 objects). Please refer to [CIM] for the full definition of this 521 class. 523 4.2.2 LogicalElement 525 This is an abstract class that is defined in the Core Model of CIM. 526 It is a subclass of the ManagedSystemElement class. This is the base 527 class for all components of a managed System that represent abstract 528 system components, such as Files, Processes, or system capabilities 529 in the form of Logical Devices and Services. Please refer to [CIM] 530 for the full definition of this class. 532 4.2.3 Service 534 This is an abstract class that is defined in the Core Model of CIM. 535 It is a subclass of the LogicalElement class. This is the base class 536 for all objects that contain the information necessary to represent 537 and manage the functionality provided by a Device and/or 538 SoftwareFeature. Note that a Service is a general-purpose object that 539 is used to configure and manage the implementation of functionality. 540 It is not the functionality itself. Please refer to [CIM] for the 541 full definition of this class. 543 4.2.4 NetworkService 545 This is an abstract class that is defined in the Network Common Model 546 of CIM. It is a subclass of the Service class. This is the base class 547 that serves as the root of the network service hierarchy. Network 548 services represent generic functions that are available from the 549 network that configure and/or modify the traffic being sent. Please 550 refer to [CIM] for the full definition of this class. 552 4.2.5 ForwardingService 554 This is a concrete class that is defined in the Network Common Model 555 of CIM. It is a subclass of the NetworkService class. This class 556 represents the forwarding of network traffic by receiving data from 557 one or more communication sources and sending that data via other 558 communication sources. Please refer to [CIM] for the full definition 559 of this class. 561 4.2.6 DiffServService 563 This is a concrete class that is a proposed addition to the Network 564 Common Model of CIM. It is a subclass of the ForwardingService class. 565 This class represents a specialization of the general concept of 566 forwarding network traffic by adding specific semantics that 567 characterize the operation of Differentiated Services. 569 The attributes defined below all have the semantics of a counter that 570 is being reset every second. The class definition is as follows: 572 NAME DiffServService 573 DESCRIPTION A concrete class for describing the common 574 characteristics of differentiated services 575 that are used to affect traffic forwarding. 576 DERIVED FROM ForwardingService 577 TYPE Structural 578 PROPERTIES ConsumedBandwidth 579 ConsumedPackets 580 CurrentBandwidth 581 CurrentDelay 582 LostPackets 584 4.2.6.1 The Attribute ConsumedBandwidth 586 The ConsumedBandwidth attribute defines the total bandwidth that has 587 been consumed during the past second, including lost packets. 589 NAME ConsumedBandwidth 590 DESCRIPTION Total bandwidth consumed during the last second, 591 in Kbits/second 592 SYNTAX Integer 594 4.2.6.2 The Attribute ConsumedPackets 596 The ConsumedPackets attribute defines the total number of packets 597 that have been consumed during the past second, including lost 598 packets. 600 NAME ConsumedPackets 601 DESCRIPTION Total number of packets consumed during the last 602 second, in packets/second 603 SYNTAX Integer 605 4.2.6.3 The Attribute CurrentBandwidth 607 The CurrentBandwidth attribute defines the instantaneous value of the 608 current bandwidth available for this link. 610 NAME CurrentBandwidth 611 DESCRIPTION Instantaneous bandwidth currently available in this 612 link, in Kbits/Second 613 SYNTAX Integer 615 4.2.6.4 The Attribute CurrentDelay 617 The CurrentDelay attribute defines the instantaneous value of the 618 current delay for this link. 620 NAME CurrentDelay 621 DESCRIPTION Instantaneous delay in this link, in Kbits/sec 622 SYNTAX Integer 624 4.2.6.5 The Attribute LostPackets 626 The LostPackets attribute defines the total number of packets that 627 have been lost during the last second on this link. 629 NAME LostPackets 630 DESCRIPTION Total number of packets lost during the last second 631 SYNTAX Integer 633 4.2.7 AFService 635 This is a concrete class that is a proposed addition to the Network 636 Common Model of CIM. It is a subclass of the DiffServService class. 637 This class represents a specialization to the general concept of 638 forwarding network traffic by adding specific semantics that 639 characterize the operation of the Assured Forwarding Service defined 640 in Differentiated Services [AF]. 642 The first two attributes defined below have the semantics of a 643 counter that is being reset every second. The class definition is as 644 follows: 646 NAME AFService 647 DESCRIPTION A concrete class for describing the common 648 characteristics of differentiated services 649 that are used to affect traffic forwarding 650 using the AF PHB Group. 651 DERIVED FROM DiffServService 652 TYPE Structural 653 PROPERTIES AssignedBandwidth 654 MaxDelay 655 SmoothingInterval 656 RELATIONSHIPS AFDropPrecedenceServices 658 4.2.7.1 The Attribute AssignedBandwidth 660 The AssignedBandwidth attribute defines the bandwidth that has been 661 assigned to this link through device-specific configuration commands. 663 NAME AssignedBandwidth 664 DESCRIPTION Assigned bandwidth to this link in Kbits/second 665 SYNTAX Integer 667 4.2.7.2 The Attribute MaxDelay 669 The MaxDelay attribute defines the total delay through this link. 671 NAME MaxDelay 672 DESCRIPTION Total delay in this link, in microseconds 673 SYNTAX Integer 675 4.2.7.3 The Attribute SmoothingInterval 677 The SmoothingInterval is a constant used to calculate the level of 678 congestion in the link, so that instantaneous bursts can be properly 679 filtered over time. 681 NAME SmoothingInterval 682 DESCRIPTION Constant used to calculate the level of congestion in 683 the link 684 SYNTAX Integer 686 4.2.7.4 The Relationship AFDropPrecedenceServices 688 The AFDropPrecedenceServices relationship is an aggregation that 689 makes explicit the dependency between an instance of an AF service 690 class and the instances of the drop precedence classes that it uses. 691 For example, [AF] defines four service classes, each with three drop 692 precedences. However, the semantics are that the AF class can not be 693 completely specified until the drop precedences are specified. This 694 is an example of a "whole-part" relationship, where the antecedent 695 (the AFService instance) is not "complete" until its constituent 696 parts (the instances of the DropPrecedence class) are defined and 697 "attached" to it. 699 The multiplicity of this relationship is one-or-more (on the 700 AFService side) to zero-or-more (on the DropPrecedence side). This 701 means that a particular AFService instance can use zero or more 702 DropPrecedence instances, and that multiple AFService instances can 703 use the same DropPrecedence instance. 705 4.2.8 AFEdgeService 707 This is a concrete class that is a proposed addition to the Network 708 Common Model of CIM. It is a subclass of the AFService class. This 709 class represents a specialization to the general concept of 710 forwarding network traffic by adding specific semantics that 711 characterize the operation of the Assured Forwarding Service defined 712 in Differentiated Services [AF] that are specific to edge devices (as 713 opposed to distribution and core devices). 715 The class definition is as follows: 717 NAME AFEdgeService 718 DESCRIPTION A concrete class for describing the common 719 characteristics of differentiated services 720 that are used to affect traffic forwarding 721 using the AF PHB Group, specifically for 722 edge devices. 723 DERIVED FROM AFService 724 TYPE Structural 725 PROPERTIES 727 4.2.9 EFService 729 This is a concrete class that is a proposed addition to the Network 730 Common Model of CIM. It is a subclass of the DiffServService class. 731 This class represents a specialization to the general concept of 732 forwarding network traffic by adding specific semantics that 733 characterize the operation of the Expedited Forwarding Service 734 defined in Differentiated Services [EF]. 736 The first two attributes defined below have the semantics of a 737 counter that is being reset every second. The class definition is as 738 follows: 740 NAME EFService 741 DESCRIPTION A concrete class for describing the common 742 characteristics of differentiated services 743 that are used to affect traffic forwarding 744 using the EF PHB Group. 745 DERIVED FROM DiffServService 746 TYPE Structural 747 PROPERTIES DSCP 748 MaxAssignedBandwidth 749 MaxDelay 750 RELATIONSHIPS EFDropPrecedenceServices 752 4.2.9.1 The Attribute DSCP 754 The DSCP attribute defines the Differentiated Services Code Point 755 that this link uses to represent the EF service through device- 756 specific configuration commands. 758 NAME DSCP 759 DESCRIPTION DiffServ Code Point used to select the EF service 760 SYNTAX String 762 4.2.9.2 The Attribute MaxAssignedBandwidth 764 The MaxAssignedBandwidth attribute defines the maximum bandwidth that 765 has been assigned to this link through device-specific configuration 766 commands. 768 NAME MaxAssignedBandwidth 769 DESCRIPTION Maximum assigned bandwidth to this link in 770 Kbits/second 771 SYNTAX Integer 773 4.2.9.3 The Attribute MaxDelay 775 The MaxDelay attribute defines the maximum delay that this link has. 777 NAME MaxAssignedBandwidth 778 DESCRIPTION Maximum delay of this link in microseconds 779 SYNTAX Integer 781 4.2.9.4 The Relationship EFDropPrecedenceServices 783 The EFDropPrecedenceServices relationship is an aggregation that 784 makes explicit the dependency between an instance of an EF service 785 class and the instances of the drop precedence classes that it uses. 786 For example, [EF] defines a service class. However, one could define 787 additional EF service classes as well as assign a drop precedence to 788 each. If a drop precedence is assigned to an EF service class, then 789 the semantics are that the EF class can not be completely specified 790 until the drop precedence(s) are specified. This is an example of a 791 "whole-part" relationship, where the antecedent (the EFService 792 instance) is not "complete" until its constituent parts (the 793 instances of the DropPrecedence class) are defined and "attached" to 794 it. 796 The multiplicity of this relationship is one-or-more (on the 797 EFService side) to zero-or-more (on the DropPrecedence side). This 798 means that a particular EFService instance can use zero or more 799 DropPrecedence instances, and that multiple EFService instances can 800 use the same DropPrecedence instance. sp 801 4.2.10 EFEdgeService 803 This is a concrete class that is a proposed addition to the Network 804 Common Model of CIM. It is a subclass of the EFService class. This 805 class represents a specialization to the general concept of 806 forwarding network traffic by adding specific semantics that 807 characterize the operation of the Expedited Forwarding Service 808 defined in Differentiated Services [EF] that are specific to edge 809 devices (as opposed to distribution and core devices). 811 The class definition is as follows: 813 NAME EFEdgeService 814 DESCRIPTION A concrete class for describing the common 815 characteristics of differentiated services 816 that are used to affect traffic forwarding 817 using the EF PHB Group, specifically for 818 edge devices. 819 DERIVED FROM EFService 820 TYPE Structural 821 PROPERTIES 823 4.2.11 PrecedenceService 825 This is a concrete class that is a proposed addition to the Network 826 Common Model of CIM. It is a subclass of the DiffServService class. 827 This class represents a specialization to the general concept of 828 forwarding network traffic by adding specific semantics that 829 characterize the operation of the Expedited Forwarding Service 830 defined in Differentiated Services [EF] that are specific to edge 831 devices (as opposed to distribution and core devices). 833 The class definition is as follows: 835 NAME PrecedenceService 836 DESCRIPTION A concrete class for describing the common 837 characteristics of differentiated services 838 that are used to affect traffic forwarding. 839 This class defines the concept of traffic 840 precedence, so that precedence may be used in 841 implementing differentiated services such as 842 those specified in [AF] and [EF]. 843 DERIVED FROM DiffServService 844 TYPE Structural 845 PROPERTIES ToS 847 4.2.11.1 The Attribute ToS 849 The Type of Service, or ToS, attribute, defines the notion of 850 precedence for different types of traffic. See [DIFFSERV] for more 851 information on the definition, backward compatibility with the ToS 852 byte of IPv4 traffic, and use of this attribute. 854 NAME ToS 855 DESCRIPTION Type of Service setting, used to provide different 856 Priorities for different types of traffic. 857 SYNTAX String 859 4.2.12 IntServService 861 This is a concrete class that is a proposed addition to the Network 862 Common Model of CIM. It is a subclass of the ForwardingService class. 863 This class represents a specialization to the general concept of 864 forwarding network traffic as applied to the Integrated Services 865 model. An example of a protocol using this model is RSVP. 867 The class definition is as follows: 869 NAME IntServService 870 DESCRIPTION A concrete class for describing the common 871 characteristics of integrated services 872 that are used to affect traffic forwarding 873 when using signaling mechanisms (e.g., RSVP). 874 DERIVED FROM ForwardingFService 875 TYPE Structural 876 PROPERTIES 878 4.2.13 DropPrecedenceService 880 This is a concrete class that is a proposed addition to the Network 881 Common Model of CIM. It is a subclass of the ForwardingService class. 882 This class represents a specialization to the general concept of 883 forwarding network traffic that meets a particular specification, and 884 dropping traffic that doesn't. 886 The class definition is as follows: 888 NAME DropPrecedenceService 889 DESCRIPTION A concrete class for describing the common 890 characteristics of network forwarding services 891 that examine traffic and either forward it or 892 drop it. The dropping is done through an active 893 queue management mechanism (e.g., RED [RED]). 894 DERIVED FROM EFService 895 TYPE Structural 896 PROPERTIES DSCP 897 InitialLossLevelStart 898 InitialLossLevelStop 899 FullLossLevelStart 900 FullLossLevelStop 902 4.2.13.1 The Attribute DSCP 904 The DSCP attribute defines the Differentiated Services Code Point 905 that this link uses to represent the EF service through device- 906 specific configuration commands. 908 NAME DSCP 909 DESCRIPTION DiffServ Code Point used to select the Drop 910 Precedence service 911 SYNTAX String 913 4.2.13.2 The Attribute InitialLossLevelStart 915 The InitialLossLevelStart attribute defines the value of the average 916 queue depth at which point whatever active queue management algorithm 917 is being used should start dropping packets. The rate of packet drop 918 will increase as a function of the increase of the average queue 919 size, until the average queue size reaches the full loss level. This 920 attribute is used in conjunction with the InitialLossLevelStop 921 attribute to define a rate at which the drop probability should 922 increase until the average queue size reaches the maximum threshold. 924 NAME InitialLossLevelStart 925 DESCRIPTION Initial value at which packets will be dropped 926 SYNTAX String 928 4.2.13.3 The Attribute InitialLossLevelStop 930 The InitialLossLevelStop attribute defines the value of the average 931 queue depth at which whatever active queue management algorithm is 932 being used should start dropping packets. It, in conjunction with the 933 InitialLossLevelStart attribute, define the slope of the packet 934 dropping function. 936 NAME InitialLossLevelStop 937 DESCRIPTION Initial value at which packets will be dropped 938 SYNTAX String 940 4.2.13.4 The Attribute FullLossLevelStart 942 The FullLossLevelStart attribute defines the value of the average 943 queue depth at which point whatever active queue management algorithm 944 is being used should start dropping all packets. 946 NAME FullLossLevelStart 947 DESCRIPTION Value at which all packets will be dropped 948 SYNTAX String 950 4.2.13.5 The Attribute FullLossLevelStop 952 The FullLossLevelStop attribute defines the value of the average 953 queue depth at which point whatever active queue management algorithm 954 is being used should start dropping all packets. 956 NAME FullLossLevelStop 957 DESCRIPTION Value at which all packets will be dropped 958 SYNTAX String 960 4.2.14 Configuration 962 This is a concrete class that is defined in the Core Model of CIM. It 963 is a top-level class that enables the grouping of sets of parameters 964 (defined in, for example, Setting objects) and dependencies for one 965 or more ManagedSystemElements. The Configuration object represents a 966 certain behavior, or a desired functional state, for the 967 ManagedSystemElements. The desired functional state is typically 968 driven by external requirements such as time or location. Please 969 refer to [CIM] for the full definition of this class. 971 4.2.15 BehaviorConfiguration 973 This is a concrete class that is a proposed addition to the Network 974 Common Model of CIM. It is a subclass of the Configuration class. 975 This class represents specialized configuration needs that can be 976 used to configure the behavior of network services, such as Assured 977 Forwarding and Expedited Forwarding. 979 The class definition is as follows: 981 NAME BehaviorConfiguration 982 DESCRIPTION A concrete class for describing the common 983 configuration characteristics of network 984 services, such as Assured Forwarding and 985 Expedited Forwarding. 986 DERIVED FROM Configuration 987 TYPE Structural 988 PROPERTIES 990 4.2.16 AFConfiguration 992 This is a concrete class that is a proposed addition to the Network 993 Common Model of CIM. It is a subclass of the BehaviorConfiguration 994 class. This class represents specialized configuration needs that can 995 be used to configure the behavior of the Assured Forwarding service. 997 The class definition is as follows: 999 NAME AFConfiguration 1000 DESCRIPTION A concrete class for describing the common 1001 configuration characteristics of the Assured 1002 Forwarding service. 1003 DERIVED FROM BehaviorConfiguration 1004 TYPE Structural 1005 PROPERTIES AssignedBandwidth 1006 MaxDelay 1007 SmoothingInterval 1008 RELATIONSHIPS AFConfigDropPrecedenceServices 1010 4.2.16.1 The Attribute AssignedBandwidth 1012 The AssignedBandwidth attribute defines the desired bandwidth (e.g., 1013 the bandwidth that will be configured for this device) to this link 1014 through device-specific configuration commands. 1016 NAME AssignedBandwidth 1017 DESCRIPTION Assigned bandwidth to this link in Kbits/second 1018 SYNTAX Integer 1020 4.2.16.2 The Attribute MaxDelay 1022 The MaxDelay attribute defines the desired total delay (e.g., the 1023 delay resulting from the configuration of this device) through this 1024 link. 1026 NAME MaxDelay 1027 DESCRIPTION Total delay in this link, in microseconds 1028 SYNTAX Integer 1030 4.2.16.3 The Attribute SmoothingInterval 1032 The SmoothingInterval is a constant used to calculate the level of 1033 congestion in the link, so that instantaneous bursts can be properly 1034 filtered over time. This attribute represents the value of this 1035 constant that will be used when the device is configured. 1037 NAME SmoothingInterval 1038 DESCRIPTION Constant used to calculate the level of congestion in 1039 the link 1040 SYNTAX Integer 1042 4.2.16.4 The Relationship AFConfigDropPrecedenceServices 1044 The AFConfigDropPrecedenceServices relationship is an aggregation 1045 that makes explicit the dependency between an instance of an 1046 AFConfiguration class and the instances of the drop precedence 1047 classes that it uses. For example, [AF] defines four service classes, 1048 each with three drop precedences. However, the semantics are that the 1049 AF class can not be completely specified until the drop precedences 1050 are specified. This is an example of a "whole-part" relationship, 1051 where the antecedent (the AFService instance) is not "complete" until 1052 its constituent parts (the instances of the DropPrecedence class) are 1053 defined and "attached" to it. This association is used to define the 1054 initial configuration of these services. 1056 The multiplicity of this relationship is one-or-more (on the 1057 AFConfiguration side) to zero-or-more (on the DropPrecedence side). 1058 This means that a particular AFConfiguration instance can use zero or 1059 more DropPrecedence instances, and that multiple AFConfiguration 1060 instances can use the same DropPrecedence instance. 1062 4.2.17 AFEdgeConfiguration 1064 This is a concrete class that is a proposed addition to the Network 1065 Common Model of CIM. It is a subclass of the AFConfiguration class. 1066 This class represents specialized configuration needs that can be 1067 used to configure the behavior of the Assured Forwarding service for 1068 edge devices. 1070 The class definition is as follows: 1072 NAME AFEdgeConfiguration 1073 DESCRIPTION A concrete class for describing the common 1074 configuration characteristics of the Assured 1075 Forwarding service for edge devices. 1076 DERIVED FROM AFConfiguration 1077 TYPE Structural 1078 PROPERTIES 1080 4.2.18 AFRoleConfiguration 1082 This is a concrete class that is a proposed addition to the Network 1083 Common Model of CIM. It is a subclass of the AFEdgeConfiguration 1084 class. This class represents specialized configuration needs that can 1085 be used to configure the behavior of the Assured Forwarding service 1086 for edge devices by using roles to identify groups of devices and 1087 groups of interfaces that are to be configured. This enforces the 1088 semantics of managing the common configuration of a group of 1089 interfaces and/or devices. 1091 The class definition is as follows: 1093 NAME AFRoleConfiguration 1094 DESCRIPTION A concrete class for describing the common 1095 configuration characteristics of the Assured 1096 Forwarding service for edge devices that are 1097 identified by roles. Note that roles can also be 1098 used to identify the interfaces of a device or a 1099 group of devices. 1100 DERIVED FROM AFEdgeConfiguration 1101 TYPE Structural 1102 PROPERTIES 1104 4.2.19 AFVendorConfiguration 1106 This is a concrete class that is a proposed addition to the Network 1107 Common Model of CIM. It is a subclass of the AFEdgeConfiguration 1108 class. This class represents specialized configuration needs that can 1109 be used to configure the behavior of the Assured Forwarding service 1110 for edge devices on a per-vendor and per-device basis. 1112 Vendor-specific configuration is, of course, unique to each vendor. 1113 Therefore, a standard set of attributes can not be defined in a 1114 specification. Instead, this class provides an array of OctetStrings 1115 (implemented as the Constraint attribute) and a single encoding of 1116 who the vendor is (represented by the ConstraintEncoding attribute). 1117 The Constraint attribute provides a way for the vendor to store, 1118 retrieve, manage, and distribute configuration commands that are 1119 specific to the vendor identified by the (registered) OID value 1120 contained in the ContraintEncoding attribute. 1122 This class therefore provides a general escape mechanism for 1123 representing common configuration policies that are specific to a 1124 particular vendor. This enables the vendor to implement a standards- 1125 compliant architecture that can be used to configure vendor-specific 1126 functions. As its name suggests, this class is intended for vendor- 1127 specific extensions. Standardized extensions are not expected to use 1128 this class. 1130 The class definition is as follows: 1131 NAME AFVendorConfiguration 1132 DESCRIPTION A concrete class for describing the common 1133 configuration characteristics of the Assured 1134 Forwarding service for edge devices that are 1135 specific to a particular vendor. 1136 DERIVED FROM AFEdgeConfiguration 1137 TYPE Structural 1138 PROPERTIES Constraint[] 1139 ConstraintEncoding 1141 4.2.19.1. The Multi-valued Attribute Constraint 1143 This attribute provides a general escape mechanism for representing 1144 configuration commands controlled by policy that have not been 1145 modeled with specific attributes. One use of this is to model 1146 vendor-specific configuration commands. 1148 The format of the uint8 array is left unspecified in this 1149 definition. It is instead determined by the OID value stored in the 1150 ConstraintEncoding attribute. Since ConstraintEncoding is single- 1151 valued, all of the values of Constraint share the same format and 1152 semantics. 1154 A policy decision point can readily determine whether it supports 1155 the values stored in an instance of Constraint by checking the OID 1156 value from ConstraintEncoding against the set of OIDs it recognizes. 1157 The action for the policy decision point to take in case it does not 1158 recognize the format of this data could itself be modeled as a 1159 policy rule, governing the behavior of the policy decision point. 1161 The attribute definition is as follows: 1163 NAME Constraint 1164 DESCRIPTION Escape mechanism for representing constraints 1165 that have not been modeled as specific 1166 attributes. The format of the values is 1167 identified by the OID stored in the 1168 ConstraintEncoding attribute. 1169 SYNTAX OctetString 1171 4.2.19.2. The Attribute ConstraintEncoding 1173 This attribute identifies the encoding and semantics of the 1174 Constraint attribute values in this instance. The value of this 1175 attribute is a single string, representing an OID which identifies 1176 the vendor. 1178 The attribute definition is as follows: 1180 NAME ConstraintEncoding 1181 DESCRIPTION An OID encoded as a string, identifying the 1182 format and semantics for this instance's 1183 Constraint attribute. 1184 SYNTAX string 1186 4.2.20 EFConfiguration 1187 This is a concrete class that is a proposed addition to the Network 1188 Common Model of CIM. It is a subclass of the BehaviorConfiguration 1189 class. This class represents specialized configuration needs that can 1190 be used to configure the behavior of the Expedited Forwarding 1191 service. 1193 The class definition is as follows: 1195 NAME EFConfiguration 1196 DESCRIPTION A concrete class for describing the common 1197 configuration characteristics of the Assured 1198 Forwarding service. 1199 DERIVED FROM BehaviorConfiguration 1200 TYPE Structural 1201 PROPERTIES DSCP 1202 MaxAssignedBandwidth 1203 MaxDelay 1204 RELATIONSHIPS EFConfigDropPrecedenceServices 1206 4.2.20.1 The Attribute DSCP 1208 The DSCP attribute defines the Differentiated Services Code Point 1209 that this link uses to represent the EF service through device- 1210 specific configuration commands. 1212 NAME DSCP 1213 DESCRIPTION DiffServ Code Point used to select the EF service 1214 SYNTAX String 1216 4.2.20.2 The Attribute MaxAssignedBandwidth 1218 The MaxAssignedBandwidth attribute defines the desired bandwidth 1219 (e.g., the bandwidth that will be configured for this device) to this 1220 link through device-specific configuration commands. 1222 NAME MaxAssignedBandwidth 1223 DESCRIPTION Maximum assigned bandwidth to this link in 1224 Kbits/second 1225 SYNTAX Integer 1227 4.2.20.3 The Attribute MaxDelay 1229 The MaxDelay attribute defines the desired total delay (e.g., the 1230 delay resulting from the configuration of this device) through this 1231 link. 1233 NAME MaxDelay 1234 DESCRIPTION Total delay in this link, in microseconds 1235 SYNTAX Integer 1237 4.2.20.4 The Relationship EFConfigDropPrecedenceServices 1239 The EFConfigDropPrecedenceServices relationship is an aggregation 1240 that makes explicit the dependency between an instance of an 1241 EFConfiguration service class and the instances of the drop 1242 precedence classes that it uses. For example, [EF] defines a service 1243 class. However, one could define additional EF service classes as 1244 well as assign a drop precedence to each. If a drop precedence is 1245 assigned to an EF service class, then the semantics are that the EF 1246 class can not be completely specified until the drop precedence(s) 1247 are specified. This is an example of a "whole-part" relationship, 1248 where the antecedent (the EFService instance) is not "complete" until 1249 its constituent parts (the instances of the DropPrecedence class) are 1250 defined and "attached" to it. 1252 The multiplicity of this relationship is one-or-more (on the 1253 EFConfiguration side) to zero-or-more (on the DropPrecedence side). 1254 This means that a particular EFConfiguration instance can use zero or 1255 more DropPrecedence instances, and that multiple EFConfiguration 1256 instances can use the same DropPrecedence instance. 1258 4.2.21 EFEdgeConfiguration 1260 This is a concrete class that is a proposed addition to the Network 1261 Common Model of CIM. It is a subclass of the EFConfiguration class. 1262 This class represents specialized configuration needs that can be 1263 used to configure the behavior of the Expedited Forwarding service 1264 for edge devices. 1266 The class definition is as follows: 1268 NAME EFEdgeConfiguration 1269 DESCRIPTION A concrete class for describing the common 1270 configuration characteristics of the Expedited 1271 Forwarding service for edge devices. 1272 DERIVED FROM EFConfiguration 1273 TYPE Structural 1274 PROPERTIES 1276 4.2.22 EFRoleConfiguration 1278 This is a concrete class that is a proposed addition to the Network 1279 Common Model of CIM. It is a subclass of the EFEdgeConfiguration 1280 class. This class represents specialized configuration needs that can 1281 be used to configure the behavior of the Expedited Forwarding service 1282 for edge devices by using roles to identify groups of devices and 1283 groups of interfaces that are to be configured. This enforces the 1284 semantics of managing the common configuration of a group of 1285 interfaces and/or devices. 1287 The class definition is as follows: 1289 NAME EFRoleConfiguration 1290 DESCRIPTION A concrete class for describing the common 1291 configuration characteristics of the Expedited 1292 Forwarding service for edge devices that are 1293 identified by roles. Note that roles can also be 1294 used to identify the interfaces of a device or a 1295 group of devices. 1296 DERIVED FROM EFEdgeConfiguration 1297 TYPE Structural 1298 PROPERTIES 1300 4.2.23 EFVendorConfiguration 1302 This is a concrete class that is a proposed addition to the Network 1303 Common Model of CIM. It is a subclass of the EFEdgeConfiguration 1304 class. This class represents specialized configuration needs that can 1305 be used to configure the behavior of the ExpeditedForwarding service 1306 for edge devices on a per-vendor and per-device basis. 1308 Vendor-specific configuration is, of course, unique to each vendor. 1309 Therefore, a standard set of attributes can not be defined in a 1310 specification. Instead, this class provides an array of OctetStrings 1311 (implemented as the Constraint attribute) and a single encoding of 1312 who the vendor is (represented by the ConstraintEncoding attribute). 1313 The Constraint attribute provides a way for the vendor to store, 1314 retrieve, manage, and distribute configuration commands that are 1315 specific to the vendor identified by the (registered) OID value 1316 contained in the ContraintEncoding attribute. 1318 This class therefore provides a general escape mechanism for 1319 representing common configuration policies that are specific to a 1320 particular vendor. This enables the vendor to implement a standards- 1321 compliant architecture that can be used to configure vendor-specific 1322 functions. As its name suggests, this class is intended for vendor- 1323 specific extensions. Standardized extensions are not expected to use 1324 this class. 1326 The class definition is as follows: 1328 NAME EFVendorConfiguration 1329 DESCRIPTION A concrete class for describing the common 1330 configuration characteristics of the Expedited 1331 Forwarding service for edge devices that are 1332 specific to a particular vendor. 1333 DERIVED FROM EFEdgeConfiguration 1334 TYPE Structural 1335 PROPERTIES Constraint[] 1336 ConstraintEncoding 1338 4.2.23.1. The Multi-valued Attribute Constraint 1340 This attribute provides a general escape mechanism for representing 1341 configuration commands controlled by policy that have not been 1342 modeled with specific attributes. One use of this is to model 1343 vendor-specific configuration commands. 1345 The format of the uint8 array is left unspecified in this 1346 definition. It is instead determined by the OID value stored in the 1347 ConstraintEncoding attribute. Since ConstraintEncoding is single- 1348 valued, all of the values of Constraint share the same format and 1349 semantics. 1351 A policy decision point can readily determine whether it supports 1352 the values stored in an instance of Constraint by checking the OID 1353 value from ConstraintEncoding against the set of OIDs it recognizes. 1354 The action for the policy decision point to take in case it does not 1355 recognize the format of this data could itself be modeled as a 1356 policy rule, governing the behavior of the policy decision point. 1358 The attribute definition is as follows: 1360 NAME Constraint 1361 DESCRIPTION Escape mechanism for representing constraints 1362 that have not been modeled as specific 1363 attributes. The format of the values is 1364 identified by the OID stored in the 1365 ConstraintEncoding attribute. 1366 SYNTAX OctetString 1368 4.2.23.2. The Attribute ConstraintEncoding 1370 This attribute identifies the encoding and semantics of the 1371 Constraint attribute values in this instance. The value of this 1372 attribute is a single string, representing an OID which identifies 1373 the vendor. 1375 The attribute definition is as follows: 1377 NAME ConstraintEncoding 1378 DESCRIPTION An OID encoded as a string, identifying the 1379 format and semantics for this instance's 1380 Constraint attribute. 1381 SYNTAX string 1383 4.2.24 IntServConfiguration 1385 This is a concrete class that is a proposed addition to the Network 1386 Common Model of CIM. It is a subclass of the BehaviorConfiguration 1387 class. This class represents specialized configuration needs that can 1388 be used to configure the behavior of Integrated Services, such as 1389 RSVP. 1391 The class definition is as follows: 1393 NAME IntServConfiguration 1394 DESCRIPTION A concrete class for describing the common 1395 configuration characteristics of the signaling 1396 protocols, such as RSVP. 1397 DERIVED FROM BehaviorConfiguration 1398 TYPE Structural 1399 PROPERTIES 1401 4.2.25 DropPrecedenceConfiguration 1403 This is a concrete class that is a proposed addition to the Network 1404 Common Model of CIM. It is a subclass of the BehaviorConfiguration 1405 class. This class represents specialized configuration needs that can 1406 be used to configure the behavior of Drop Precedence Services, 1407 regardless of which higher-level class is using them. 1409 The class definition is as follows: 1410 NAME DropPrecedenceConfiguration 1411 DESCRIPTION A concrete class for describing the common 1412 configuration characteristics of drop precedence 1413 services independent of what other higher-level 1414 service uses it. 1415 DERIVED FROM BehaviorConfiguration 1416 TYPE Structural 1417 PROPERTIES 1418 RELATIONSHIPS AFDropPrecedenceServices, 1419 EFDropPrecedenceServices, 1420 AFConfigDropPrecedenceServices, 1421 EFConfigDropPrecedenceServices 1423 Note: AFDropPrecedenceServices and EFDropPrecedenceServices are 1424 defined previously in sections 4.2.7.4 and 4.2.9.4, respectively. The 1425 AFConfigDropPrecedenceServices and EFConfigDropPrecedenceServices are 1426 defined previously in sections 4.2.16.4 and 4.2.20.4, respectively. 1428 4.2.26 PrecedenceConfiguration 1430 This is a concrete class that is a proposed addition to the Network 1431 Common Model of CIM. It is a subclass of the BehaviorConfiguration 1432 class. This class represents specialized configuration needs that can 1433 be used to configure the behavior of Precedence Services, regardless 1434 of which higher-level class is using them. 1436 The class definition is as follows: 1438 NAME PrecedenceConfiguration 1439 DESCRIPTION A concrete class for describing the common 1440 configuration characteristics of the signaling 1441 protocols, such as RSVP. 1442 DERIVED FROM BehaviorConfiguration 1443 TYPE Structural 1444 PROPERTIES ToS 1446 4.2.26.1 The Attribute ToS 1448 The Type of Service, or ToS, attribute, defines the notion of 1449 precedence for different types of traffic. See [DIFFSERV] for more 1450 information on the definition, backward compatibility with the ToS 1451 byte of IPv4 traffic, and use of this attribute. The purpose of this 1452 attribute is to define the configuration value for the ToS setting of 1453 this link. 1455 NAME ToS 1456 DESCRIPTION Type of Service setting, used to provide different 1457 Priorities for different types of traffic. 1458 SYNTAX String 1460 5. Mapping to Example Policies 1462 All that is left is some usage cases that demonstrate how these 1463 attributes can be expressed and used to create policies. In order to 1464 express these attributes in a meaningful way, they have to be bound 1465 to a router or an interface on a router. This requires the 1466 introduction of two additional concepts that can flexibly group the 1467 set of devices and interfaces. The first concept is a means for 1468 binding a particular policy to a set of devices that execute or act 1469 on the policy. To support this capability, we propose a new required 1470 attribute, called PolicyScope, listing the devices for which this 1471 policy is applicable. This attribute should be defined in the 1472 PolicyRule object defined in the Core Information Model. The second 1473 concept requires a means for binding an attribute to a specific 1474 interface or set of interfaces. This binding, called a Role, takes 1475 the form of a qualifier preceding the instance name. Roles are 1476 described in [TERMS]. 1478 So let's consider the following condition: 1480 Customer1.ReliableService.ConsumedBandwidth > 1500 1482 The qualifier "Customer1" is a Role that refers to a specific 1483 interface of a device. The DiffServ class, or queue (e.g., AF3, 1484 precedence 6, or EF) is represented in the directory with a unique 1485 instance with a unique name. In this example, ReliableService is the 1486 instance name for an AFService class using the DSCPs for AF2. 1487 ConsumedBandwidth is an attribute containing the current bandwidth 1488 rate being sent on specified DiffServ class (queue) of the specified 1489 interface. Hence, the condition reads: 1491 If Customer1 is receiving more then 1500 Kb of AF2 traffic, 1492 then.... 1494 However, the concept of Roles has additional benefits because we can 1495 also express a single policy that can be applied to a set of 1496 interfaces simultaneously. Let's consider the following sample 1497 action: 1499 CoreInterfaces.LowDelayConfig.MaxDelay = 20 1501 In this particular case, we are qualifying this action to only apply 1502 to the interfaces as specified by the CoreInterfaces role. In this 1503 case we are assuming that this is the set of interfaces in a device 1504 participating in the core of the DiffServ domain. Further, 1505 LowDelayConfig is an instance of the EFConfiguration class. As 1506 mentioned earlier, configuration classes are used to request a change 1507 in the configuration of device or service while state classes are 1508 used to model the actual state of the device or service. So, this 1509 action expresses the changing of the upper bound on the maximum delay 1510 that will be tolerated for this service on each sending interface to 1511 the core. As a side note, the intent of the attribute MaxDelay is to 1512 provide a simple way of expressing an upper bound on the number of 1513 packets that can be queued up while avoiding implementation details 1514 for where or how packets are queued or scheduled. 1516 6. Security Considerations 1518 Security and denial of service considerations are not explicitly 1519 considered in this memo, as they are appropriate for the underlying 1520 policy architecture implementing the distribution and communication 1521 of the information described in this draft. However, the information 1522 in this draft explicitly makes use of the security measures 1523 recommended in the policy architecture defined by the Policy 1524 Framework working group. Specifically, any mechanisms used to 1525 distribute and communicate the information described in this draft 1526 must minimize theft and denial of service threats. Second, it must be 1527 ensured that the entities (such as PEPs and PDPs) involved in policy 1528 control can verify each other's identity and establish necessary 1529 trust before communicating. 1531 The communication tunnel between policy clients and policy servers 1532 SHOULD be secured by the use of an IPSEC [IPSEC] channel. It is 1533 advisable that this tunnel makes use of both the AH (Authentication 1534 Header) and ESP (Encapsulating Security Payload) protocols, in order 1535 to provide confidentiality, data origin authentication, integrity and 1536 replay prevention. 1538 7. Acknowledgments 1539 8. References 1541 [TERMS] S. Bradner, "Key words for use in RFCs to Indicate 1542 Requirement Levels", Internet RFC 2119, March 1997. 1543 [DIFFARCH] D. Black, S. Blake, M. Carlson, E. Davies, Z. Whang, 1544 W. Weiss, "An Architecture for Differentiated Services", 1545 RFC2475, December 1998 1546 [DIFFSERV] K. Nichols and S. Blake, "Definition of the 1547 Differentiated Services Field (DS Byte) in the 1548 IPv4 and IPv6 Headers", RFC2474, December 1998 1549 [AF] J. Heinanen, F. Baker, W. Weiss, J. Wroclawski, "Assured 1550 Forwarding PHB Group", RFC2597, June 1999 1551 [EF] V. Jacobson, K. Nichols, K. Poduri, "An Expedited 1552 Forwarding PHB", RFC2598, June 1999 1553 [RAPFRAME] R. Yavatkar, D. Pendarakis, R. Guerin, "A Framework for 1554 Policy-based Admission Control", Internet Draft, 1555 , May 1998 1556 [CIM]CIM Specification and CIM Schemata are available at: 1557 http://www.dmtf.org/spec/cims.html 1558 [IPSEC] R. Atkinson, "Security Architecture for the Internet 1559 Protocol", RFC1825, Aug. 1995. 1560 [RED] Floyd, S., and Jacobson, V., "Random Early Detection 1561 gateways for Congestion Avoidance", IEEE/ACM Transactions 1562 on Networking, Volume 1, Number 4, August 1993, 1563 pp. 397-413. 1565 11. Authors' Addresses 1567 Walter Weiss 1568 Lucent Technologies 1569 300 Baker Ave. 1570 Concord, MA. 01742 1571 Phone: +1-978-287-9130 1572 Fax: +1-978-287-9050 1573 E-mail: wweiss@lucent.com 1575 John Strassner 1576 Cisco Systems 1577 Bldg E 1578 190 West Tasman Drive 1579 San Jose, CA 95134 1580 Phone: +1-408-527-1069 1581 Fax: +1-408-527-2477 1582 E-mail: johns@cisco.com 1584 Andrea Westerinen 1585 Microsoft Corporation 1586 One Microsoft Way 1587 Redmond, WA 98052 1588 Phone: +1 425-705-2553 1589 Email: andreawe@microsoft.com 1591 10. Full Copyright Statement 1593 Copyright (C) The Internet Society (1999). All Rights Reserved. 1595 This document and translations of it may be copied and furnished to 1596 others, and derivative works that comment on or otherwise explain it 1597 or assist in its implementation may be prepared, copied, published 1598 and distributed, in whole or in part, without restriction of any 1599 kind, provided that the above copyright notice and this paragraph 1600 are included on all such copies and derivative works. However, this 1601 document itself may not be modified in any way, such as by removing 1602 the copyright notice or references to the Internet Society or other 1603 Internet organizations, except as needed for the purpose of 1604 developing Internet standards in which case the procedures for 1605 copyrights defined in the Internet Standards process must be 1606 followed, or as required to translate it into languages other than 1607 English. 1609 The limited permissions granted above are perpetual and will not be 1610 revoked by the Internet Society or its successors or assigns. 1612 This document and the information contained herein is provided on an 1613 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1614 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1615 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1616 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1617 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1619 2360