idnits 2.17.1 draft-mfine-cops-pib-01.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 Internet-Drafts being working documents. ** 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 == It seems as if not all pages are separated by form feeds - found 0 form feeds but 61 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** 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. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (25 June 1999) is 9072 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) == Outdated reference: A later version (-08) exists of draft-ietf-rap-cops-06 == Outdated reference: A later version (-05) exists of draft-ietf-rap-pr-00 ** Downref: Normative reference to an Historic draft: draft-ietf-rap-pr (ref. 'COPS-PR') -- Possible downref: Normative reference to a draft: ref. 'QOS-POL' ** Downref: Normative reference to an Informational draft: draft-ietf-rap-framework (ref. 'RAP-FRAMEWORK') == Outdated reference: A later version (-06) exists of draft-ietf-diffserv-model-00 ** Downref: Normative reference to an Informational draft: draft-ietf-diffserv-model (ref. 'MODEL') Summary: 10 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group M. Fine 2 Internet Draft K. McCloghrie 3 Expires December 1999 Cisco Systems 4 J. Seligson 5 K. Chan 6 Nortel Networks 7 S. Hahn 8 Intel 9 A. Smith 10 Extreme Networks 12 25 June 1999 14 Quality of Service Policy Information Base 16 draft-mfine-cops-pib-01.txt 18 Status of this Memo 20 This document is an Internet-Draft and is in full conformance with all 21 provisions of Section 10 of RFC2026. Internet-Drafts are working 22 documents of the Internet Engineering Task Force (IETF), its areas, and 23 its working groups. Note that other groups may also distribute working 24 documents as Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference material 29 or to cite them other than as ``work in progress.'' 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 To view the current status of any Internet-Draft, please check the 38 ``1id-abstracts.txt'' listing contained in an Internet-Drafts Shadow 39 Directory, see http://www.ietf.org/shadow.html. 41 Disclaimer 43 This draft is preliminary and is known to be inconsistent in some 44 respects with the Diffserv Conceptual Model [MODEL]. It is intended to 45 correct this prior to the next version, as well as checking for full 46 consistency with RFC 2474 and RFC 2475. 48 1. Glossary 50 PRC Policy Rule Class. A type of policy data. 51 PRI Policy Rule Instance. An instance of a PRC. 52 PIB Policy Information Base. The database of policy information. 53 PDP Policy Decision Point. See [RAP-FRAMEWORK]. 54 PEP Policy Enforcement Point. See [RAP-FRAMEWORK]. 55 PRID Policy Rule Instance Identifier. Uniquely identifies an 56 instance of a a PRC. 58 2. Introduction 60 This document defines a set of policy rule classes for describing 61 quality of service (QoS) policies. 63 This document structures QoS policy information as instances of policy 64 rule classes. A policy rule class (PRC) is an ordered set of scalar 65 attributes. Policy rule classes are arranged in a hierarchical 66 structure similar to tables in SNMP's SMIv2 [SNMP-SMI]. As with SNMP 67 tables, they are identified by a sequence of integer identifiers (an 68 Object Identifier). 70 For each policy rule class a device may have zero or more policy rule 71 instances. Each policy rule instance is also identified by a sequence 72 of integers where the first part of the sequence is the ID of the PRC. 73 Collections of policy rule classes are defined in PIB modules. These 74 modules are written using a structure designed for policy information as 75 described below. 77 3. The Structure of Policy Information 79 The Structure of Policy Information (SoPI) defines the set of rules for 80 writing Policy Information Base (PIB) modules. The SoPI is purposely 81 defined as a slightly modified version of SNMP's SMIv2 [SNMP-SMI], the 82 rules which govern the definition of SNMP MIB modules. The differences 83 between the SMIv2 and the SoPI allow the definition of a PIB to take 84 advantage of the different features that a policy protocol, such as 85 [COPS-PR], can have compared to SNMP. However, these differences are 86 small enough to allow all those familiar with MIBs to leverage that 87 familiarity, by quickly learning the small number of differences. 89 3.1. Differences from SMIv2 91 The SoPI differs from SMIv2 as follows: 93 (1) The module begins with keyword PIB-DEFINITIONS rather than the 94 keyword DEFINITIONS, to identify it as a PIB rather than a MIB. 96 (2) All policy rule classes as expressed as tables, where each table 97 is a PRC, and the columar objects in a table are attributes of 98 the class. In contrast to SNMP, there are no scalar objects in a 99 PIB. This makes for a more consistent "class-based" structure. 101 (3) The OBJECT-TYPE macro has a mandatory additional clause, POLICY- 102 ACCESS. This clause can only be applied to a policy rule class 103 (i.e., the table definition). It takes the value "install", 104 "install-notify" or "notify". Defining a PRC as "install" or 105 "install-notify" means that the PDP can install new instances of 106 this PRC, or modify existing ones. Defining PRC as "install- 107 notify" or "notify" means that the PEP must include all instances 108 of this PRC when a) it sends its initial request message to the 109 PDP, and b) in response to a PDP message to synchronize state. 111 (4) The OBJECT-TYPE macro also has an additional optional clause, 112 INSTALL-ERRORS. This clause enumerates possible reasons for 113 rejecting the install decision from the PDP. This clause may 114 only appear on a policy rule class (i.e., on a table object 115 type). If this clause is not present, the install can still 116 fail, but no error specific to the policy class can be reported. 117 A generic PIB error may be reported when an installation fails 118 even if the INSTALL-ERRORS clause is missing. 120 To facilitate future extensions to the PIB, the attributes of a class 121 may be augmented in another, perhaps enterprise specific, PIB by 122 defining a class (using the AUGMENTS clause) in that newer PIB. 123 Instances of the new class are related to instances of the existing 124 class by means of the instance index. 126 3.2. Mapping the PIB to a MIB 128 The SoPI has been designed so that a PIB can be easily and 129 algorithmically mapped into a MIB. If such a MIB were implemented by an 130 SNMP agent, it would provide SNMP management applications with the 131 ability to query a PEP to determine the set of policies currently 132 installed (e.g., via COPS) in that PEP. Such a MIB might also allow 133 some of the PRIs of PRCs whose POLICY-ACCESS is "notify" to be 134 configured with their values via an SNMP management application. 135 However, there will be implementations for which the values of some 136 notify PRCs are fixed, and not modifiable via SNMP. Another purpose of 137 such a mapping could be to allow existing MIB-based tools to be used for 138 PIBs. 140 The mapping of a PIB to a MIB is achieved by means of the following 141 rules. 143 (1) Replace the keyword POLICY-DEFINITIONS with the keyword 144 DEFINITIONS. 146 (2) Delete all the POLICY-ACCESS clauses. 148 (3) Add a MAX-ACCESS clause for each OBJECT-TYPE. For each table and 149 entry OBJECT-TYPE the MAX-ACCESS is "not-accessible". For each 150 attribute that is an index, the MAX-ACCESS is "not-accessible". 151 For the remaining attributes, the MAX-ACCESS is "read-only" if 152 the POLICY-ACCESS for the class is "install" or "install-notify", 153 and it is "read-create" if the POLICY-ACCESS for the class is 154 "notify". 156 Note that these access clause mappings assume that policy 157 configuration (i.e., installation) is performed solely by a 158 policy server and SNMP is used, if at all, for monitoring 159 purposes only. Under the scenario where a policy server is not 160 present and SNMP is to be used for rudimentary policy 161 configuration, it is permissible to map POLICY-ACCESS values of 162 "install" and "install-notify" to a MAX-ACCESS value of "read- 163 create" to support SNMP-based operations. Policy server 164 operations always take precedence over SNMP-based operations when 165 both are supported such that the appearance of a policy server 166 must cause the MAX-ACCESS clause mapping to revert back to "read- 167 only" as previously described. 169 (4) Add a columnar attribute of type RowStatus with name status and 170 with the next available OID if the POLICY-ACCESS is "notify". 172 (5) Delete all the INSTALL-ERRORS clauses. 174 (6) Add appropriate conformance clauses, which allow conformant 175 implementations to provide just read-only access to all objects. 177 3.3. Error Codes 179 Error values are returned by the PEP to the PDP during policy 180 installation to signify the inability of the PEP to complete the 181 requested operation. Two error codes are currently defined: Generic PIB 182 (GP) and Class Specific (CS). The Generic PIB error code and its 183 associated sub-codes are implicitly associated with all classes and can 184 thus always be returned if appropriate for the given situation. The 185 Class Specific error code value and its associated sub-codes are 186 explicitly associated with individual classes via the INSTALL-ERRORS 187 clause. Class Specific error sub-codes are defined in the INSTALL-ERRORS 188 clause and have significance only in the context of the class in which 189 there were defined. When a Class Specific error code is returned, it 190 must be returned together with a PRID which establishes the context 191 within which the receiver interpretes the sub-code. 193 The currently defined error code values and the Generic PIB error sub- 194 codes are as follows: 196 Error-Code: 198 1 = Generic PIB (GP) 199 2 = Class Specific (CS) 201 GP Sub-Codes: 203 1 = Class instantiation space exhausted. No more 204 instances may be instantiated at this time. 205 2 = Invalid PRI. The PRID used to identify a PRI 206 in a class specifies a non-existent instance. 208 4. General PIB Concepts 210 4.1. Roles 212 The policy to apply to an interface may depend on many factors such as 213 immutable characteristics of the interface (e.g., ethernet or frame 214 relay), the status of the interface (e.g., half or full duplex), or user 215 configuration (e.g., branch office or headquarters interface). Rather 216 than specifying policies explicitly for each interface in the QoS 217 domain, policies are specified in terms of interface functionality. 219 To describe these functionalities of an interface we use the concept of 220 "roles". A role is simply a string that is associated with an 221 interface. A given interface may have any number of roles 222 simultaneously. Policy rule classes have an attribute called a "role- 223 combination" which is an unordered set of roles. Instances of a given 224 policy rule class are applied to interface if and only if the set of 225 roles in the role combination is identical to the set of the roles of 226 the interface. 228 Thus, roles provide a way to bind policy to interfaces without having to 229 explicitly identify interfaces in a consistent manner across all network 230 devices. (The SNMP experience with ifIndex has proved this to be a 231 difficult task.) That is, roles provide a level of indirection to the 232 application of a set of policies to specific interfaces. Furthermore, 233 if the same policy is being applied to several interfaces, that policy 234 need be pushed to the device only once, rather than once per interface, 235 as long as the interfaces are configured with the same role combination. 237 We point out that, in the event that the administrator needs to have 238 unique policy for each interface, this can be achieved by configuring 239 each interface with a unique role. 241 The PEP reports all its role combinations to the PDP at connect time or 242 whenever they change. 244 The comparing of roles (or role combinations) must be case insensitive. 245 For display purposes, roles (or role combinations) should preserve the 246 case specified by the user. 248 The concept and usage of roles in this document is consistent with that 249 specified in [QOS-POL]. Roles are currently under discussion in the 250 IETF's Policy WG; as and when that discussion reaches a conclusion, this 251 PIB will be updated in accordance with that conclusion. 253 4.2. Reporting of Device Capabilities 255 Each network device providing the Differentiated Services has its own 256 inherent capabilities. These capabilities can be hardware specific, 257 e.g. an ethernet interface supporting input classification, or can be 258 statically configured, e.g. supported queuing disciplines. These 259 capabilities are communicated to the PDP when initial DiffServ Policy 260 Service is requested by the PEP. Knowing device capabilities, the PDP 261 can send the policy rule instances (PRIs) relevant to the specific 262 device, rather than sending the entire PIB. 264 5. DiffServ PIB Concepts 266 5.1. Filters, Filter Groups and Classifiers 268 The basis of differential QoS treatment of packets is a filter. This is 269 simply a general specification for matching a pattern to appear in 270 packets belonging to flows, e.g. microflows or bandwidth aggregates. 271 Associated with each filter is a permit/deny flag which effectively 272 gives a negation operation. 274 Sets of these filters are used to create classifiers. Classifiers are 275 applied to interfaces with a direction flag to indicate an ingress or 276 egress classifier. Filters are combined, in order, into filter groups; 277 filter groups are then combined, in order, to build a classifier. This 278 allows a rudimentary classification grammar to be defined. On input, 279 each packet is checked against the ingress classifier on the interface. 280 Similarly, on output each packet is checked against the egress 281 classifier on the interface. The result of the classifier then feeds 282 into appropriate meters and actions to be applied to packets. 284 For each classifier, the packet is checked against the set of filter 285 groups in the appropriate order. The detailed operation of the PIB 286 syntax is as follows. If a packet matches a filter in the first filter 287 group of a classifier and the sense is "permit" then the subsequent 288 meters and actions associated with that classifier are applied to that 289 packet and no further filters are compared. If the sense is "deny" then 290 the rest of the filters in the current filter group are skipped and 291 operation proceeds with the first filter of the next filter group. If 292 the packet does not match any of the filters in the filter group then 293 the next filter group is tried. This process is continued until a 294 definitive match is obtained. Each classifier must cover all possible 295 matches i.e. it must be complete." 297 5.2. Applying QoS Policy Using Targets 299 The task of applying QoS policy within a network requires the 300 specification of several components. The flows to which QoS policy 301 should be applied must be identified. The interfaces of the device on 302 which the policy should be enforced must be known. A certain set of 303 parameters to support flow metering is also required. The combination of 304 these components provides the target against which QoS policy is to be 305 applied. Within the context of the QoS PIB, the association between 306 these components is defined efficiently using the Target class. 308 The Target class serves to logically link several other QoS policy 309 classes. Flow classification rules, specifying behavior aggregate (BA) 310 or multi-field (MF) classification parameters, are indirectly identified 311 using the Policy Rule Identifier (PRID) for the appropriate 312 classification class (e.g., IP, 802). Interface information is specified 313 using the role combination tag, defined in the Interface Type class, to 314 identify the group of interfaces on which classification is to be 315 performed. The direction of packet flow on the identified interfaces is 316 provided as well. A link to the metering component is provided using the 317 PRID for the appropriate metering class (TBD). 319 Once a target has been defined, actions based on the classification and 320 metering phases must be specified. The Target class satisfies this 321 requirement by providing the linkage between a target specification and 322 an Action class instance. A precedence component is also provided so 323 that a definitive order of evaluation may be defined for Target class 324 instances being applied to the same interface role and flow direction 325 targets. The Target class thus functions as the integration point for 326 the range of components used for the application of QoS policy. 328 5.3. Queue Modeling with Queue Sets 330 The traffic processing capabilities of an interface are determined by 331 the queuing resources that are associated with the interface. These 332 capabilities are represented abstractly using queue sets. A queue set is 333 comprised of one or more individual queues and facilitates treating the 334 collection of queues as a single unit based on their combined behaviors. 335 A device may support a number of different queue sets. The number of 336 queues sets supported by a device is typically related to the number of 337 unique combinations of interface properties within that device. The 338 queue set abstraction is not limited to modeling physical interface 339 properties, however, and can be used to represent logical and dynamic 340 queuing behavior as well. 342 Each individual queue in a set is characterized by the interface 343 bandwidth it can consume, the queuing discipline it employs and it's 344 relationship with other queues in the set. Interface bandwidth 345 allocation per queue can be represented in either relative or absolute 346 terms. A queue's drain size (i.e., the maximum number of bytes that may 347 be drained from the queue in one cycle) can be used to determine the 348 relative bandwidth allocation. The sum of the drain sizes of all of the 349 related queues in a set is used to compute the percentage of interface 350 bandwidth allocated to a specific queue based on its drain size. The 351 maximum interface bandwidth that is available may also be described in 352 absolute terms by specifying the potential consumption rate in bits per 353 second. 355 The traffic processing paradigm employed by a given queue is represented 356 by queue discipline attributes. Several general purpose and well-known 357 queuing disciplines (e.g., priority, fifo, weighted fair queuing) are 358 supported and a mechanism to define additional paradigms in an 359 extensible fashion is provided. The relationship among queues within a 360 set is specified using a service order attribute. This attribute 361 provides an additional level of service precedence among queues. This is 362 required for describing the behavior of queues utilizing the same 363 processing discipline (e.g., a series of priority queues) and when the 364 various queues that comprise a queue set are serviced using a mix of 365 queuing disciplines (e.g., priority and weighted round robin queues). 366 These individual queue attributes, when combined, support the 367 representation of (potentially) complex queuing systems associated with 368 an interface type (i.e., role combination). 370 5.4. IP Mapping to and from Layer 2 372 The PIB specifies QoS policy by assigning DSCP values to specific 373 queues, but in order to provide a complete QoS picture, the PIB must 374 consider that not all devices on the network are diffserv capable, i.e., 375 capable of setting/inspecting a packet's DSCP value. Specifically, the 376 network might include layer 2 devices (switches) that can only support 377 IEEE 802.1p classes of service. In order to support network 378 configuration that consist of diffserv capable devices and devices that 379 can only support IEEE 802.1p, the PIB has included a mapping table that 380 can allow the DSCP values to be mapped to specific IEEE 802.1p tag 381 values. 383 DSCP ---------- DSCP -------- DSCP ---------- DSCP 384 ----->|diffserv|--------->|L2 |--------->|diffserv|------> 385 | router | 802.1p |switch| 802.1p | router | 802.1p 386 ---------- priority -------- priority ---------- priority 388 A second case exists where packets coming into the network are arriving 389 from a non-diffserv enabled device and no DSCP exists with in the 390 packet, but an 802.1p tag does exist. In the case where the diffserv 391 device has the ability to set a DSCP in the packet, the diffserv router 392 can map the layer 2 tag into a DSCP value. The PIB supports a mapping 393 table that can be used to map from the layer 2 tag to a DSCP value. 394 This allows different policies to be applied to packets based on the 395 ingress port at the L2 switch as shown in the figure below. 397 ---------- ------------ DSCP 398 -->| L2 |--------->| diffserv |-------> 399 -->| switch | 802.1p | router | 802.1p 400 ---------- priority ------------ priority 402 Alternatively, the diffserv router can have policies applied to it that 403 cause it to reclassify the incoming packet using a MF classifier, 404 ignoring the incoming 802.1p tag. 406 6. Summary of the PIB Modules 408 This section gives a brief summary of the top-level groups in the three 409 modules defined in this document. 411 Device Configuration Group 412 This group contains device configuration information. This 413 configuration is either set by management or reflects the physical 414 configuration of the device. 416 QoS Interface Group 417 This group is used to indicate to the PDP the types of interface 418 configured on the PEP. Note that this group indicates the types of 419 interfaces, not the configuration of each and every interface on 420 the device. 422 Diffserv Domain Configuration Group 423 This group contains diffserv domain wide DSCP mapping policies to 424 be applied to all devices within the administrative domain. 426 QoS Action Group 427 This group contains the policies that define the Action to be taken 428 after the result of the classification. This group also contains 429 the policies that associate the classifiers and the actions. 431 IP Classification and Policing Group 432 This group contains the policies that define the IP classifier 433 elements. 435 802 Classification and Policing Group 436 This group contains the policies that define the IEEE 802 437 classifier elements. 439 7. PIB Operational Overview 441 This section provides an operation overview of how the three modules are 442 used in concert to provide policy to the PEP. 444 After initial PEP to PDP communication setup, using [COPS-PR] for 445 example, the PEP will provide to the PDP the PIB Policy Rule Classes 446 (PRCs), interface types, and interface type capabilities it support. 448 The PRCs the PEP supports is reported to the PDP in the PRC Support 449 Table, qosPrcSupportTable. Each instance of the qosPrcSupportTable 450 class indicates a PRC that the PEP understands, that the PDP can send 451 its instances as part of the policy information. 453 The interface types the PEP supports is reported to the PDP in the 454 Interface Type Table, qosInterfaceTypeTable. Each instance of this 455 class describes the characteristic of an interface type. Each interface 456 type is identified by a role combination. Each interface type's 457 inherent capability is reported to the PDP using the Interface Type 458 Table. Examples of capability are classification, policing, dropping, 459 queuing, and shaping. An interface type has a queue set, 460 qosIfQueueSetTable, associated with it. The queue set indicates the 461 queues, qosIfQueueTable, and their queuing disciplines an interface type 462 supports. 464 The PDP, with knowledge of the PEP's capabilities, will provide to the 465 PEP with: 467 (1) Administration domain policy information in 468 qosIfDscpAssignmentTable 469 qosDiffServMappingTable 470 qosCosToDscpTable 472 (2) Interface type and role specific IP policy information in 473 qosIpFilterTable 474 qosIpClassifierDefinitionTable 475 qosActionTable 476 qosTargetTable 478 (3) Interface type and role specific IEEE 802 policy information in 479 qos802FilterTable 480 qos802ClassifierDefinitionTable 482 Instances of the qosTargetTable define how the Traffic Conditioning 483 Elements are combined into Traffic Conditioning Blocks, as described in 484 draft-ietf-diffserv-model-00.txt. Each instance of the qosTargetTable 485 applies to an interface type defined by its roles and direction (ingress 486 or egress). This is pictured in the following diagram where the 487 InterfaceRoles X, and Y would be used by the network device to associate 488 the traffic conditioning block with the interfaces needing each of thess 489 policies. 491 +----------------------------+ +----------------------------+ 492 | qosIpAclDefinitionEntries | | qosTargetEntry | 493 | with AclType = IP | | with AclType = IP | 494 | AclId = 1 | <------------ AclId = 1 | 495 | referencing its list of | | InterfaceRoles = X | 496 | qosIpAceEntries | | Order = 5 | 497 +----------------------------+ | Action ----+ | 498 +-------------------|--------+ 499 | 500 v 501 +----------------+ 502 | qosActionEntry | 503 +----------------+ 505 +----------------------------+ +----------------------------+ 506 | qos802AclDefinitionEntries | | qosTargetEntry | 507 | with AclType = 802 | | with AclType = 802 | 508 | AclId = 10 | <------------ AclId = 10 | 509 | referencing its list of | | InterfaceRoles = Y | 510 | qos802AceEntries | | Order = 15 | 511 +----------------------------+ | Action ----+ | 512 +-------------------|--------+ 513 | 514 v 515 +----------------+ 516 | qosActionEntry | 517 +----------------+ 519 Figure 7.1 Diffserv PIB Table Relationships 521 Notice in the above diagram, IEEE 802 type classifiers are intermixed 522 with the IP type classifiers, sharing the same pool of Traffic 523 Conditioning Elements. The qosTargetTable allows use of heterogeneous 524 classifiers with same instance of qosActionTable. Using IP and IEEE 802 525 classifiers together is just one example. Other types of classifiers 526 may be used heterogeneously. 528 After receiving the PIB, the PEP will associate the Classifier and 529 Action with the corresponding interfaces supporting the specific 530 interface type and roles. 532 8. PIB Definitions 534 NOTE 535 In these PIB definitions, we use the term "access control entry" (ACE) 536 synonymous with filter, "access control list" (ACL) synonymous with 537 filter group, and sets of ACLs synonymous with classifier. 539 8.1. The Policy Framework PIB Module 541 POLICY-FRAMEWORK-PIB PIB-DEFINITIONS ::= BEGIN 543 IMPORTS 544 Unsigned32, MODULE-IDENTITY, OBJECT-TYPE 545 FROM SNMPv2-SMI 546 TEXTUAL-CONVENTION 547 FROM SNMPv2-TC 548 SnmpAdminString 549 FROM SNMP-FRAMEWORK-MIB; 551 policyFrameworkPib MODULE-IDENTITY 552 LAST-UPDATED "9906241800Z" 553 ORGANIZATION "IETF RAP WG" 554 CONTACT-INFO " 555 Michael Fine 556 Cisco Systems, Inc. 557 170 West Tasman Drive 558 San Jose, CA 95134-1706 USA 559 Phone: +1 408 527 8218 560 Email: mfine@cisco.com 562 Keith McCloghrie 563 Cisco Systems, Inc. 564 170 West Tasman Drive, 565 San Jose, CA 95134-1706 USA 566 Phone: +1 408 526 5260 567 Email: kzm@cisco.com 569 John Seligson 570 Nortel Networks, Inc. 571 4401 Great America Parkway 572 Santa Clara, CA 95054 USA 573 Phone: +1 408 495 2992 574 Email: jseligso@nortelnetworks.com" 575 DESCRIPTION 576 "A PIB module containing the base set of policy 577 rule classes that are required for support of 578 all policies." 580 ::= { tbd } 582 policyBasePibClasses 583 OBJECT IDENTIFIER ::= { policyFrameworkPib 1 } 585 -- 586 -- Textual Conventions 587 -- 589 -- 590 -- Interface Role 591 -- 593 Role ::= TEXTUAL-CONVENTION 594 STATUS current 595 DESCRIPTION 596 "A display string but where the characters '+', ' ' (space), 597 NULL, LF, CR, BELL, BS, HT (tab) VT and FF are illegal." 599 SYNTAX SnmpAdminString (SIZE (0..31)) 601 -- 602 -- Interface Role Combination 603 -- 605 RoleCombination ::= TEXTUAL-CONVENTION 606 STATUS current 607 DESCRIPTION 608 "A Display string consisting of a set of roles concatenated 609 with a '+' character where the roles are in lexicographic 610 order from minimum to maximum." 612 SYNTAX SnmpAdminString (SIZE (0..255)) 614 -- 615 -- Policy Instance Index 616 -- 618 PolicyInstanceId ::= TEXTUAL-CONVENTION 619 STATUS current 620 DESCRIPTION 621 "A textual convention for an attribute that is an integer 622 index of a class. It is used for attributes that exist 623 for the purpose of providing a policy rule instance with 624 a unique instance identifier. 626 For any instance identifier that refers to another policy 627 rule instance, that other policy instance must exist. 628 Furthermore, it is an error to try to delete a policy rule 629 instance that is referred to by another instance without 630 first deleting the referencing instance. 632 Class instances of this type need not be contiguous." 634 SYNTAX Unsigned32 636 -- 637 -- Device Configuration Group 638 -- 640 -- This group contains device configuration information. This 641 -- configuration is either set by management or reflects the physical 642 -- configuration of the device. This configuration is generally 643 -- reported to the PDP (i.e., the policy server) when configuration 644 -- is performed by the policy server so that the PDP can determine 645 -- what policies to download to the PEP (i.e., the device). Class 646 -- instances may also be downloaded by a network manager prior to 647 -- static configuration. 648 -- 650 policyDeviceConfig OBJECT IDENTIFIER ::= { policyBasePibClasses 1 } 652 -- 653 -- PRC Support Table 654 -- 656 policyPrcSupportTable OBJECT-TYPE 657 SYNTAX SEQUENCE OF PolicyPrcSupportEntry 658 POLICY-ACCESS notify 659 STATUS current 660 DESCRIPTION 661 "Each instance of this class specifies a PRC that the device 662 supports and a bit string to indicate the attributes of the 663 class that are supported. These PRIs are sent to the PDP to 664 indicate to the PDP which PRCs, and which attributes of these 665 PRCs, the device supports. This table can also be downloaded 666 by a network manager when static configuration is used. 668 All install and install-notify PRCs supported by the device 669 must be represented in this table." 671 ::= { policyDeviceConfig 1 } 673 policyPrcSupportEntry OBJECT-TYPE 674 SYNTAX PolicyPrcSupportEntry 675 STATUS current 676 DESCRIPTION 677 "An instance of the policyPrcSupport class that identifies a 678 specific policy class and associated attributes as supported 679 by the device." 681 INDEX { policyPrcSupportIndex } 682 ::= { policyPrcSupportTable 1 } 684 PolicyPrcSupportEntry ::= SEQUENCE { 685 policyPrcSupportIndex PolicyInstanceId, 686 policyPrcSupportSupportedPrc OBJECT IDENTIFIER, 687 policyPrcSupportSupportedAttrs OCTET STRING 688 } 690 policyPrcSupportIndex OBJECT-TYPE 691 SYNTAX PolicyInstanceId 692 STATUS current 693 DESCRIPTION 694 "An arbitrary integer index that uniquely identifies an 695 instance of the policyPrcSupport class." 697 ::= { policyPrcSupportEntry 1 } 699 policyPrcSupportSupportedPrc OBJECT-TYPE 700 SYNTAX OBJECT IDENTIFIER 701 STATUS current 702 DESCRIPTION 703 "The object identifier of a supported PRC. There may not 704 be more than one instance of the policyPrcSupport class with 705 the same value of policyPrcSupportSupportedPrc." 707 ::= { policyPrcSupportEntry 2 } 709 policyPrcSupportSupportedAttrs OBJECT-TYPE 710 SYNTAX OCTET STRING 711 STATUS current 712 DESCRIPTION 713 "A bit string representing the supported attributes of the 714 class that is identified by the policyPrcSupportSupportedPrc 715 object. 717 Each bit of this bit mask corresponds to a class attribute, 718 with the most significant bit of the i-th octet of this octet 719 string corresponding to the (8*i - 7)-th attribute, and the 720 least significant bit of the i-th octet corresponding to the 721 (8*i)-th class attribute. Each bit of this bit mask specifies 722 whether or not the corresponding class attribute is currently 723 supported, with a '1' indicating support and a '0' indicating 724 no support. If the value of this bit mask is N bits long and 725 there are more than N class attributes then the bit mask is 726 logically extended with 0's to the required length." 728 ::= { policyPrcSupportEntry 3 } 730 -- 731 -- PIB Incarnation Table 732 -- 734 policyDevicePibIncarnationTable OBJECT-TYPE 735 SYNTAX SEQUENCE OF PolicyDevicePibIncarnationEntry 736 POLICY-ACCESS install-notify 737 STATUS current 738 DESCRIPTION 739 "This class contains a single policy rule instance that 740 identifies the current incarnation of the PIB and the PDP 741 or network manager that installed this incarnation. The 742 instance of this class is reported to the PDP at client 743 connect time so that the PDP can (attempt to) ascertain the 744 current state of the PIB. A network manager may use the 745 instance to determine the state of the device with regard 746 to existing NMS interactions." 748 ::= { policyDeviceConfig 2 } 750 policyDevicePibIncarnationEntry OBJECT-TYPE 751 SYNTAX PolicyDevicePibIncarnationEntry 752 STATUS current 753 DESCRIPTION 754 "An instance of the policyDevicePibIncarnation class. Only 755 one instance of this policy class is ever instantiated." 757 INDEX { policyDevicePibIncarnationIndex } 758 ::= { policyDevicePibIncarnationTable 1 } 760 PolicyDevicePibIncarnationEntry ::= SEQUENCE { 761 policyDevicePibIncarnationIndex PolicyInstanceId, 762 policyDevicePibIncarnationName SnmpAdminString, 763 policyDevicePibIncarnationId OCTET STRING, 764 policyDevicePibIncarnationTtl Unsigned32 765 } 767 policyDevicePibIncarnationIndex OBJECT-TYPE 768 SYNTAX PolicyInstanceId 769 STATUS current 770 DESCRIPTION 771 "An index to uniquely identify an instance of this 772 policy class." 774 ::= { policyDevicePibIncarnationEntry 1 } 776 policyDevicePibIncarnationName OBJECT-TYPE 777 SYNTAX SnmpAdminString 778 STATUS current 779 DESCRIPTION 780 "The name of the entity that installed the current 781 incarnation of the PIB into the device. The name may 782 reference a PDP when dynamic configuration is being 783 used or a network manager when static configuration 784 is being used. By default, it is the zero length 785 string." 787 ::= { policyDevicePibIncarnationEntry 2 } 789 policyDevicePibIncarnationId OBJECT-TYPE 790 SYNTAX OCTET STRING 791 STATUS current 792 DESCRIPTION 793 "An ID to identify the current incarnation. It has meaning 794 to the PDP/manager that installed the PIB and perhaps its 795 standby PDPs/managers. By default, it is the zero-length 796 string." 798 ::= { policyDevicePibIncarnationEntry 3 } 800 policyDevicePibIncarnationTtl OBJECT-TYPE 801 SYNTAX Unsigned32 802 STATUS current 803 DESCRIPTION 804 "The number of seconds after a client close or TCP timeout 805 for which the PEP continues to enforce the policy in the PIB. 806 After this interval, the PIB is considered expired and the 807 device no longer enforces the policy installed in the PIB. 808 Policy enforcement timing only applies to policies that have 809 been installed dynamically (e.g., by a PDP via COPS)." 811 ::= { policyDevicePibIncarnationEntry 4 } 813 END 814 8.2. The QoS IP PIB 816 (1) QOS-POLICY-IP-PIB PIB-DEFINITIONS ::= BEGIN 818 IMPORTS 819 Unsigned32, IpAddress, Integer32, 820 MODULE-IDENTITY, OBJECT-TYPE 821 FROM SNMPv2-SMI 822 TruthValue, TEXTUAL-CONVENTION 823 FROM SNMPv2-TC 824 RoleCombination, PolicyInstanceId 825 FROM POLICY-FRAMEWORK-PIB; 827 qosPolicyIpPib MODULE-IDENTITY 828 LAST-UPDATED "9906241800Z" 829 ORGANIZATION "IETF RAP WG" 830 CONTACT-INFO " 831 Michael Fine 832 Cisco Systems, Inc. 833 170 West Tasman Drive 834 San Jose, CA 95134-1706 USA 835 Phone: +1 408 527 8218 836 Email: mfine@cisco.com 838 Keith McCloghrie 839 Cisco Systems, Inc. 840 170 West Tasman Drive, 841 San Jose, CA 95134-1706 USA 842 Phone: +1 408 526 5260 843 Email: kzm@cisco.com 845 John Seligson 846 Nortel Networks, Inc. 847 4401 Great America Parkway 848 Santa Clara, CA 95054 USA 849 Phone: +1 408 495 2992 850 Email: jseligso@nortelnetworks.com" 851 DESCRIPTION 852 "The PIB module containing an initial set of policy 853 rule classes that describe the quality of service 854 (QoS) policies. It includes general classes that may 855 be extended by other PIB specifications as well as 856 an initial set of PIB classes related to IP 857 processing." 858 ::= { tbd } 860 qosPolicyGenPibClasses OBJECT IDENTIFIER ::= { qosPolicyIpPib 1 861 } qosPolicyIpPibClasses OBJECT IDENTIFIER ::= { qosPolicyIpPib 862 2 } 864 -- -- Textual Conventions -- 866 -- -- Diffserv Codepoint -- 868 Dscp ::= TEXTUAL-CONVENTION 869 STATUS current 870 DESCRIPTION 871 "An integer that is in the range of the diffserv 872 codepoint 873 values." 875 SYNTAX INTEGER (0..63) 877 -- -- Interface types -- 879 QosInterfaceQueueCount ::= TEXTUAL-CONVENTION 880 STATUS current 881 DESCRIPTION 882 "An integer that describes the number of queues an 883 interface 884 supports. It is limited to the number of DSCP values." 886 SYNTAX INTEGER (1..64) 888 -- -- QoS Interface Group -- -- -- This group specifies the 889 configuration of the various interface -- types including the 890 setting of queueing parameters and the -- mapping of DSCPs and 891 802.1 CoS to queues. -- 893 qosIfParameters OBJECT IDENTIFIER ::= { qosPolicyGenPibClasses 1 894 } 896 -- -- Interface Type Table -- 898 qosInterfaceTypeTable OBJECT-TYPE 899 SYNTAX SEQUENCE OF QosInterfaceTypeEntry 900 POLICY-ACCESS notify 901 STATUS current 902 DESCRIPTION 903 "Interface type definitions. This class describes the 904 types 905 of interfaces that exist on the device. An interface type 906 is denoted by its designated role identifier as well as 907 by the queue set and queue capabilities it supports." 909 ::= { qosIfParameters 1 } 911 qosInterfaceTypeEntry OBJECT-TYPE 912 SYNTAX QosInterfaceTypeEntry 913 STATUS current 914 DESCRIPTION 915 "An instance of this class describes the characteristics 916 of a type of an interface. Interface type characteristics 917 include a role combination identifier, a queue set 918 identifier and a queue capabilities attribute. An 919 instance is required for each different unique role 920 combination identifier which represents the different 921 interface types that are operational in the device at 922 any given time. The PEP does not report which specific 923 interfaces have which characteristics." 925 INDEX { qosInterfaceTypeIndex } 926 ::= { qosInterfaceTypeTable 1 } 928 QosInterfaceTypeEntry ::= SEQUENCE { 929 qosInterfaceTypeIndex PolicyInstanceId, 930 qosInterfaceTypeRoles RoleCombination, 931 qosInterfaceTypeQueueSet PolicyInstanceId, 932 qosInterfaceTypeCapabilities BITS } 934 qosInterfaceTypeIndex OBJECT-TYPE 935 SYNTAX PolicyInstanceId 936 STATUS current 937 DESCRIPTION 938 "An arbitrary integer index that uniquely identifies a 939 instance of the qosInterfaceType class. Class instances 940 may not be contiguous." 942 ::= { qosInterfaceTypeEntry 1 } 944 qosInterfaceTypeRoles OBJECT-TYPE 945 SYNTAX RoleCombination 946 STATUS current 947 DESCRIPTION 948 "The role combination that is used to identify interfaces 949 with the characteristics specified by the attributes 950 of this class instance. Interface role combination 951 identifiers are used within a number of classes to 952 logically identify a physical set of interfaces to which 953 policy rules and actions are applied. Role combination 954 identifiers must exist in this table prior to being 955 referenced in other class instances." 957 ::= { qosInterfaceTypeEntry 2 } 959 qosInterfaceTypeQueueSet OBJECT-TYPE 960 SYNTAX PolicyInstanceId 961 STATUS current 962 DESCRIPTION 963 "The index of the queue set that is associated with 964 interfaces that are identified with the role combination 965 identifier that is associated with this class instance." 967 ::= { qosInterfaceTypeEntry 3 } 969 qosInterfaceTypeCapabilities OBJECT-TYPE 970 SYNTAX BITS { 971 other(0), 973 -- Classification support 974 inputIpClassification(1), 975 outputIpClassification(2), 976 input802Classification(3), 977 output802Classification(4), 979 -- Queuing discipline support 980 singleQueuingDiscipline(5), 981 hybridQueuingDiscipline(6) 982 } 983 STATUS current 984 DESCRIPTION 985 "An enumeration of interface capabilities. Used by the 986 PDP or network manager to select which policies and 987 configuration it should push to the PEP." 989 ::= { qosInterfaceTypeEntry 4 } 991 -- -- Interface Queue Table -- -- The Interface Queue Table 992 enumerates the individual queues that -- comprise a given queue 993 set. Information specific to each queue -- is exported by this 994 table. -- 996 qosIfQueueTable OBJECT-TYPE 997 SYNTAX SEQUENCE OF QosIfQueueEntry 998 POLICY-ACCESS notify 999 STATUS current 1000 DESCRIPTION 1001 "Contains information about the individual queues that 1002 comprise a queue set implemented on the device." 1004 ::= { qosIfParameters 2 } 1006 qosIfQueueEntry OBJECT-TYPE 1007 SYNTAX QosIfQueueEntry 1008 STATUS current 1009 DESCRIPTION 1010 "A conceptual row in the qosIfQueueTable. 1012 Each row identifies a specific queue within a given queue 1013 set and contains detailed information about the queue. 1014 Queues 1015 are associated with a given set through this table and 1016 a queue set is associated with an interface set through 1017 the qosInterfaceTypeTable." 1019 INDEX { qosIfQueueSetId, 1020 qosIfQueueIndex } 1021 ::= { qosIfQueueTable 1 } 1023 QosIfQueueEntry ::= SEQUENCE { 1024 qosIfQueueSetId PolicyInstanceId, 1025 qosIfQueueIndex QosInterfaceQueueCount, 1026 qosIfQueueGenDiscipline INTEGER, 1027 qosIfQueueExtDiscipline OBJECT IDENTIFIER, 1028 qosIfQueueDrainSize Integer32, 1029 qosIfQueueAbsBandwidth Unsigned32, 1030 qosIfQueueServiceOrder QosInterfaceQueueCount, 1031 qosIfQueueSize Integer32 } 1033 qosIfQueueSetId OBJECT-TYPE 1034 SYNTAX PolicyInstanceId 1035 STATUS current 1036 DESCRIPTION 1037 "An index that uniquely identifies a specific queue set. 1039 The 1040 queue set that is identified with this value is 1041 associated 1042 with an interface set through the 1043 qosInterfaceTypeQueueSet 1044 object in the qosInterfaceTypeTable. The individual 1045 queues 1046 that are members of this set all have the same value for 1047 this attribute (i.e., they have the same set ID)." 1049 ::= { qosIfQueueEntry 1 } 1051 qosIfQueueIndex OBJECT-TYPE 1052 SYNTAX QosInterfaceQueueCount 1053 STATUS current 1054 DESCRIPTION 1055 "An arbitrary index that uniquely identifies a specific 1056 queue within a set of queues that is identified by the 1057 qosIfQueueSetId value." 1059 ::= { qosIfQueueEntry 2 } 1061 qosIfQueueGenDiscipline OBJECT-TYPE 1062 SYNTAX INTEGER { 1063 other(1), -- Use qosIfQueueExtDiscipline 1064 fifo(2), -- First In First Out queuing 1065 pq(3), -- Priority Queuing 1066 fq(4), -- Fair Queuing 1067 wfq(5) -- Weighted Fair Queuing 1068 } 1069 STATUS current 1070 DESCRIPTION 1071 "This object identifies the queuing discipline that is 1072 associated with the specified queue. Several general 1073 purpose and well-known queuing disciplines are supported 1074 by this attribute. Queuing disciplines that differ from 1075 those that are supported by this object are specified 1076 by setting this attribute to other(1) and providing 1077 the object identifier that represents the different 1078 queuing paradigm in the qosIfQueueExtDiscipline object. 1080 A value of fifo(2) indicates that the queue is serviced 1081 on a first-in-first-out (FIFO) basis. This discipline is 1082 generally employed when only a single queue is available 1083 for a given interface. 1085 A value of pq(3) indicates that the queue is serviced 1086 using a priority queuing discipline. This technique is 1087 used when several queues are available for a given 1088 interface. Each queue is assigned a priority and queues 1089 are serviced in order of priority. Higher priority queues 1090 are completely drained before lower priority queues are 1091 serviced. 1093 A value of fq(4) indicates that the queue is serviced 1094 using a fair queuing discipline. This technique is used 1095 when several queues are available for a given interface. 1096 Each queue is treated equally and is serviced in a 1097 round-robin fashion. 1099 A value of wfq(5) indicates that the queue is serviced 1100 using a weighted fair queuing discipline. This technique 1101 is 1102 used when several queues are available for a given 1103 interface. 1104 Each queue is serviced based on queue weights which 1105 determine 1106 the scheduling and frequency of queue servicing. Queues 1107 that 1108 are assigned a greater weight are implicitly provided 1109 with 1110 more bandwidth. 1112 Note that the processing disciplines for all of the 1113 queues 1114 in a given set must be considered when trying to 1115 establish 1116 a processing profile for a given interface." 1118 ::= { qosIfQueueEntry 3 } 1120 qosIfQueueExtDiscipline OBJECT-TYPE 1121 SYNTAX OBJECT IDENTIFIER 1122 STATUS current 1123 DESCRIPTION 1124 "This object identifies the queuing discipline that is 1125 associated with the specified queue. This attribute 1126 provides a means through which additional queuing 1127 mechanisms 1128 can be identified should the general queuing disciplines 1129 be inadequate for a given device. As such. this attribute 1131 is 1132 consulted only when the value of the 1133 qosIfQueueGenDiscipline 1134 object is other(1). It contains an object identifier that 1135 uniquely identifies a queuing paradigm. 1137 Note that the processing disciplines for all of the 1138 queues 1139 in a given set must be considered when trying to 1140 establish 1141 a processing profile for a given interface." 1143 ::= { qosIfQueueEntry 4 } 1145 qosIfQueueDrainSize OBJECT-TYPE 1146 SYNTAX Integer32 1147 STATUS current 1148 DESCRIPTION 1149 "The maximum number of bytes that may be drained from the 1150 queue in one cycle. The percentage of the interface 1151 bandwidth allocated to this queue can be calculated from 1152 this attribute and the sum of the drain sizes of all the 1153 queues in a specific queue cluster in a queue set. 1155 This attribute represents the relative bandwidth that is 1156 available to a given queue with respect to other queues 1157 with 1158 which it is associated. The absolute bandwidth that is 1159 available to a given queue is specified by the attribute 1160 qosIfQueueAbsBandwidth. When an absolute bandwidth is 1161 specified, the value of this object must be -1." 1163 ::= { qosIfQueueEntry 5 } 1165 qosIfQueueAbsBandwidth OBJECT-TYPE 1166 SYNTAX Unsigned32 1167 STATUS current 1168 DESCRIPTION 1169 "The maximum interface bandwidth that is available for 1170 consumption when servicing this queue. The available 1171 bandwidth is modeled in terms of bytes per second. 1173 This attribute represents the absolute bandwidth that is 1174 available to a given queue. The relative bandwidth that 1175 is 1176 available to a given queue, with respect to other queues 1177 with 1178 which it is associated, is specified by the attribute 1179 qosIfQueueDrainSize. When a relative bandwidth is 1180 specified, 1181 the value of this object must be -1." 1183 ::= { qosIfQueueEntry 6 } 1185 qosIfQueueServiceOrder OBJECT-TYPE 1186 SYNTAX QosInterfaceQueueCount 1187 STATUS current 1188 DESCRIPTION 1189 "This object is used to provide an additional level of 1190 priority that is required for certain queuing disciplines 1191 and when the different queues that comprise a queue set 1192 are serviced using a mix of queuing disciplines. This 1193 object can be used to specify, for example, the order in 1194 which queues will be serviced when priority queuing is 1195 used. It also supports the ability to describe the 1196 servicing hierarchy when a hybrid queuing scheme, such 1197 as priority queuing coupled with weighted fair queuing, 1198 is used. 1200 Queue service priority is assigned such that a lower 1201 service order value indicates a higher priority. For 1202 example, a priority queue with a value of 1 will be 1203 serviced (i.e., drained) before another priority queue 1204 with a service order value of 2. 1206 Note that multiple queues that are logically associated, 1207 based on the queuing discipline that is being employed, 1208 will be assigned the same service order value. Under 1209 this scenario, other parameters that are related to the 1210 queuing discipline determine the order of queue servicing 1211 (e.g., queue drain size is used for 'wfq'). 1213 For example, an interface that is associated with a queue 1214 set supporting two priority queues and three queues that 1215 are serviced using WFQ would be modeled as follows: 1217 Q Index Q Discipline Q Drain Size Q Service Order 1218 22 pq(1) - 1 1219 23 pq(1) - 2 1220 24 wfq(3) 500 3 1221 25 wfq(3) 350 3 1222 26 wfq(3) 150 3 1224 The queue set presented in this example would service 1225 all queued traffic in queue 22 first, followed by all of 1226 the queued traffic in queue 23. Next the queued traffic 1227 in queues 24 through 26 would be serviced in a round 1228 robin fashion with queue 24 receiving 50% of the 1229 available 1230 bandwidth, queue 25 receiving 35% of the available 1231 bandwidth and queue 26 receiving 15% of the available 1232 bandwidth. This example is presented for expository 1233 purposes and has been simplified accordingly. 1235 Note that, in this example, queues 24, 25 and 26 form a 1236 queue cluster. Members of a queue cluster are all 1237 assigned 1238 the same qosIfQueueServiceOrder as there are tightly 1239 coupled. The qosIfQueueDrainSize attribute is used to 1240 determine the additional processing characteristics of 1241 the individual queues in a cluster." 1243 ::= { qosIfQueueEntry 7 } 1245 qosIfQueueSize OBJECT-TYPE 1246 SYNTAX Integer32 1247 STATUS current 1248 DESCRIPTION 1249 "The size of the queue in bytes. Some devices set queue 1250 size 1251 in terms of packets. These devices must calculate the 1252 queue 1253 size in packets by assuming an average packet size 1254 suitable 1255 for the particular interface. 1257 Some devices have a fixed size buffer to be shared among 1258 all 1259 queues. These devices must allocate a fraction of the 1260 total buffer space to this queue calculated as the the 1261 ratio 1262 of the queue size to the sum of the queue sizes for the 1263 interface." 1265 ::= { qosIfQueueEntry 8 } 1267 -- -- DSCP Assignment Table -- -- Supports the assignment of 1268 DSCPs to queues for each -- interface type. -- 1270 qosIfDscpAssignmentTable OBJECT-TYPE 1271 SYNTAX SEQUENCE OF QosIfDscpAssignmentEntry 1272 POLICY-ACCESS install 1273 STATUS current 1274 DESCRIPTION 1275 "Supports the assignment of DSCP values to a queue for 1276 each interface with a specific queue count. There will be 1277 64 instances of this class for each supported combination 1278 of queue count and role combination." 1280 ::= { qosIfParameters 3 } 1282 qosIfDscpAssignmentEntry OBJECT-TYPE 1283 SYNTAX QosIfDscpAssignmentEntry 1284 STATUS current 1285 DESCRIPTION 1286 "An instance of the qosIfDscpAssignment class." 1288 INDEX { qosIfDscpAssignmentIndex } 1289 ::= { qosIfDscpAssignmentTable 1 } 1291 QosIfDscpAssignmentEntry ::= SEQUENCE { 1292 qosIfDscpAssignmentIndex PolicyInstanceId, 1293 qosIfDscpAssignmentRoles RoleCombination, 1294 qosIfDscpAssignmentDscp Dscp, 1295 qosIfDscpAssignmentQueue QosInterfaceQueueCount } 1297 qosIfDscpAssignmentIndex OBJECT-TYPE 1298 SYNTAX PolicyInstanceId 1299 STATUS current 1300 DESCRIPTION 1301 "An index that is used to uniquely identify the 1302 instance of the qosIfDscpAssignment class." 1304 ::= { qosIfDscpAssignmentEntry 1 } 1306 qosIfDscpAssignmentRoles OBJECT-TYPE 1307 SYNTAX RoleCombination 1308 STATUS current 1309 DESCRIPTION 1310 "The role combination with which an interface must be 1311 configured to support the DSCP-to-queue assignment 1312 described by this instance. The specified role 1313 combination must be defined in the qosInterfaceType 1314 table prior to being referenced by this entry. 1315 Otherwise a 'priAssociationUnknown(3)' error code 1316 will be returned." 1318 ::= { qosIfDscpAssignmentEntry 2 } 1320 qosIfDscpAssignmentDscp OBJECT-TYPE 1321 SYNTAX Dscp 1322 STATUS current 1323 DESCRIPTION 1324 "The DSCP to which this class instance applies." 1326 ::= { qosIfDscpAssignmentEntry 3 } 1328 qosIfDscpAssignmentQueue OBJECT-TYPE 1329 SYNTAX QosInterfaceQueueCount 1330 STATUS current 1331 DESCRIPTION 1332 "The specific queue, within the queue set that is 1333 associated with the interface set identified by the 1334 qosIfDscpAssignmentRoles tag, on which traffic with 1335 the specified DSCP, dictated by the 1336 qosIfDscpAssignmentDscp value, is placed. Failure to 1337 specify an appropriate queue results in a 1338 'priAssociationConflict(4)' error indication being 1339 returned." 1341 ::= { qosIfDscpAssignmentEntry 4 } 1343 -- -- The Generic QoS ACL Action Group -- 1345 qosAction OBJECT IDENTIFIER ::= { qosPolicyGenPibClasses 3 } 1347 -- -- The QoS Action Table -- -- The QoS Action Table describes 1348 actions that are associated with -- specific IP, IEEE 802 and 1349 other ACLs through the QoS Target -- Table. An action 1350 specification may be simple (i.e., a single -- action) or complex 1351 (i.e., multiple actions that are performed -- in "parallel"). -- 1353 qosActionTable OBJECT-TYPE 1354 SYNTAX SEQUENCE OF QosActionEntry 1355 POLICY-ACCESS install 1356 STATUS current 1357 DESCRIPTION 1358 "Contains the current set of configured actions. The 1359 actions 1360 are associated with IP, IEEE 802 and other ACLs and 1361 interfaces during operation." 1363 ::= { qosAction 1 } 1365 qosActionEntry OBJECT-TYPE 1366 SYNTAX QosActionEntry 1367 STATUS current 1368 DESCRIPTION 1369 "General action definitions. Each entry specifies an 1370 instance 1371 of the qosAction class which describes (potentially) 1372 several distinct action attributes. Each action is taken 1373 individually regarding the data in question. Several 1374 actions 1375 can be taken for a single frame. 1377 An instance of this class can not be deleted while it is 1378 being 1379 referenced in a target instance in another class. This 1380 class may be extended with actions that apply to specific 1381 QoS 1382 policies (e.g., IP, IEEE 802, security) using 1383 augmentation." 1385 INDEX { qosActionIndex } 1386 ::= { qosActionTable 1 } 1388 QosActionEntry ::= SEQUENCE { 1389 qosActionIndex PolicyInstanceId, 1390 qosActionDrop TruthValue, 1391 qosActionUpdateDSCP Integer32 } 1393 qosActionIndex OBJECT-TYPE 1394 SYNTAX PolicyInstanceId 1395 STATUS current 1396 DESCRIPTION 1397 "An arbitrary integer index that uniquely identifies 1398 the instance of the QoS Action class. Class instances 1399 may not be contiguous. Actions are associated with 1400 Target instances in other classes (e.g., the QoS 1401 Target class) using this attribute." 1403 ::= { qosActionEntry 1 } 1405 qosActionDrop OBJECT-TYPE 1406 SYNTAX TruthValue 1407 STATUS current 1408 DESCRIPTION 1409 "This action attribute, when specified, will cause the 1410 frame being evaluated to be dropped if the value is 1411 'true(1)'. A value of 'false(2)' indicates that this 1412 action will not be initiated (i.e., the frame will not 1413 be dropped) based on this attribute. 1415 Prior to discarding a packet, other actions that have 1416 been specified should be performed if they make protocol 1417 sense. For example, requests for traffic mirroring (if 1418 such an action is supported by a device) should be 1419 honored. However, updating protocol header values will 1420 typically not be necessary." 1422 ::= { qosActionEntry 2 } 1424 qosActionUpdateDSCP OBJECT-TYPE 1425 SYNTAX Integer32 (-1 | 0..63) 1426 STATUS current 1427 DESCRIPTION 1428 "This action component, when specified, will cause the 1429 value contained in the Differentiated Services (DS) 1430 field of an associated IP datagram to be updated with 1431 the value of this object. 1433 A value of -1 indicates that this action component has 1434 not 1435 been set to an appropriate value and should not be used 1436 for 1437 action initiation. The DSCP should remain unchanged." 1439 ::= { qosActionEntry 3 } 1441 -- -- The QoS Target Table -- -- The QoS Target Table supports 1442 the association of ACLs, -- interfaces and actions. It allows ACL 1443 class instances, as -- defined in various ACL Defintion classes, 1444 to be associated -- with specific interfaces/flow direction 1445 (based on interface -- role combination and traffic direction) 1446 and actions to be -- performed based on traffic classification. 1447 Furthermore, it -- allows heterogeneous ACL Definition class 1448 instances (e.g., -- IP, IEEE 802, security) to be applied to the 1449 same interface -- group in a prescribed order of precedence. -- 1451 qosTargetTable OBJECT-TYPE 1452 SYNTAX SEQUENCE OF QosTargetEntry 1453 POLICY-ACCESS install 1454 STATUS current 1455 DESCRIPTION 1456 "A class that applies a set of ACLs to interfaces 1457 specifying, 1458 for each interface, the precedence order of the ACL with 1459 respect to other ACLs applied to the same interface and, 1460 for 1461 each ACL, the action to take for a packet that matches a 1462 permit ACE in that ACL. Interfaces are specified 1463 abstractly 1464 in terms of interface roles. 1466 This class may contain ACLs that specify different types 1467 of traffic classification (e.g., IP ACLs and IEEE 802 1468 ACLs 1469 defined in their respective definition tables). An ACL is 1470 identified by its class and instance within that class. 1471 An 1472 ACL association is formed when ACLs apply to the same 1473 interfaces, as determined by the specified interface role 1474 and direction. ACL evaluation precedence within an 1475 association is determined by the precedence attribute." 1477 INSTALL-ERRORS { 1478 priPrecedenceConflict(1) -- precedence conflict detected 1479 } 1481 ::= { qosAction 2 } 1483 qosTargetEntry OBJECT-TYPE 1484 SYNTAX QosTargetEntry 1485 STATUS current 1486 DESCRIPTION 1487 "An instance of the qosTarget class. Instance creation 1488 may be prohibited based on the status of certain class 1489 attributes which must exist prior to class 1490 instantiation." 1492 INDEX { qosTargetIndex } 1493 ::= { qosTargetTable 1 } 1495 QosTargetEntry ::= SEQUENCE { 1496 qosTargetIndex PolicyInstanceId, 1497 qosTargetAclId PolicyInstanceId, 1498 qosTargetAclType OBJECT IDENTIFIER, 1499 qosTargetInterfaceRoles RoleCombination, 1500 qosTargetInterfaceDirection INTEGER, 1501 qosTargetOrder Unsigned32, 1502 qosTargetAction PolicyInstanceId } 1504 qosTargetIndex OBJECT-TYPE 1505 SYNTAX PolicyInstanceId 1506 STATUS current 1507 DESCRIPTION 1508 "An arbitrary integer index that uniquely identifies 1509 the instance of the QoS Target class." 1511 ::= { qosTargetEntry 1 } 1513 qosTargetAclId OBJECT-TYPE 1514 SYNTAX PolicyInstanceId 1515 STATUS current 1516 DESCRIPTION 1517 "This attribute identifies the ACL that is associated 1518 with this target. It identifies (potentially many) ACL 1519 class instances in a specific ACL Definition table 1520 where ACLs, and their associated ACEs, are defined. 1521 For example, instances in the qosIpAclDefinitionTable 1522 are identified by setting the value of this object 1523 equal to the qosIpAclDefinitionAclId of the instances 1524 being targeted. This value, together with the value of 1525 the corresponding qosTargetAclType attribute, 1526 uniquely identifies one or more instances of a specific 1527 ACL Definition class. 1529 Attempting to specify an unknown ACL class instance will 1530 result in an appropriate error indication being returned 1531 to the entity that is attempting to install the 1532 conflicting 1533 entry. For example, a 'priUnknown(2)' error indication is 1534 returned to the policy server in this situation." 1536 ::= { qosTargetEntry 2 } 1538 qosTargetAclType OBJECT-TYPE 1539 SYNTAX OBJECT IDENTIFIER 1540 STATUS current 1541 DESCRIPTION 1542 "The ACL Definition class that is being referenced by 1543 this instance of the ACL Target class. This policy 1544 class identifier, together with the corresponding 1545 qosTargetAclId attribute, uniquely identifies 1546 instances of a specific ACL Definition class. 1548 The object identifier value of this attribute must 1549 exist in the policyPrcSupportTable." 1551 ::= { qosTargetEntry 3 } 1553 qosTargetInterfaceRoles OBJECT-TYPE 1554 SYNTAX RoleCombination 1555 STATUS current 1556 DESCRIPTION 1557 "The interfaces to which this ACL applies specified 1558 in terms of a set of roles. The role combination 1559 specified by this attribute must exist in the 1560 qosInterfaceTypeTable prior to being association 1561 with an instance of this class." 1563 ::= { qosTargetEntry 4 } 1565 qosTargetInterfaceDirection OBJECT-TYPE 1566 SYNTAX INTEGER { 1567 in(1), 1568 out(2) 1569 } 1570 STATUS current 1571 DESCRIPTION 1572 "The direction of packet flow at the interface in 1573 question to which this ACL applies." 1575 ::= { qosTargetEntry 5 } 1577 qosTargetOrder OBJECT-TYPE 1578 SYNTAX Unsigned32 1579 STATUS current 1580 DESCRIPTION 1581 "An integer that determines the precedence order of 1582 this ACL in the list of ACLs applied to interfaces of 1583 the specified role combination. An ACL with a given 1584 precedence order is positioned in the list before one 1585 with a higher-valued precedence order. 1587 As an example, consider the following ACL Target 1588 association: 1590 Index IfRoleCombo IfDirection AclId AclType Order 1591 14 'eth1000+L2+L3' 'in' 8 '802' 1 1592 15 'eth1000+L2+L3' 'in' 3 '802' 2 1593 16 'eth1000+L2+L3' 'in' 12 'IP' 3 1594 17 'eth1000+L2+L3' 'in' 6 'IP' 4 1595 18 'eth1000+L2+L3' 'in' 21 'IP' 5 1597 Five distinct ACL specifications, 3 from an IP ACL 1598 Definition class and 2 from an IEEE 802 ACL Definition 1599 class, 1600 form an Acl Target association (e.g., based on the 1601 specified 1602 interface role combination and direction attributes) with 1603 a 1604 prescribed order of evaluation. The AclType and AclId 1605 attributes identify the ACL Definition instances in their 1606 respective classes. 1608 Precedence values within an association must be unique 1609 otherwise instance installation will be prohibited and an 1610 error value will be returned." 1612 ::= { qosTargetEntry 6 } 1614 qosTargetAction OBJECT-TYPE 1615 SYNTAX PolicyInstanceId 1616 STATUS current 1617 DESCRIPTION 1618 "This attribute identifies the action that is associated 1619 with this QoS Target instance. Actions are defined 1620 in the qosActionTable. The corresponding instance in 1621 the qosAction class (i.e., the class instance where 1622 the qosActionId is equal to the value of this object) 1623 must exist prior to being associated with an ACL Target 1624 entry." 1626 ::= { qosTargetEntry 7 } 1628 -- -- The IP Classification and Policing Group -- 1630 qosIpQos OBJECT IDENTIFIER ::= { qosPolicyIpPibClasses 1 } 1632 -- The IP ACE Table 1634 qosIpAceTable OBJECT-TYPE 1635 SYNTAX SEQUENCE OF QosIpAceEntry 1636 POLICY-ACCESS install 1637 STATUS current 1638 DESCRIPTION 1639 "ACE definitions. A packet has to match all fields in an 1640 ACE. Wildcards may be specified for those fields that 1641 are 1642 not relevant." 1644 ::= { qosIpQos 1 } 1646 qosIpAceEntry OBJECT-TYPE 1647 SYNTAX QosIpAceEntry 1648 STATUS current 1649 DESCRIPTION 1650 "An instance of the qosIpAce class." 1652 INDEX { qosIpAceIndex } 1653 ::= { qosIpAceTable 1 } 1655 QosIpAceEntry ::= SEQUENCE { 1656 qosIpAceIndex PolicyInstanceId, 1657 qosIpAceDstAddr IpAddress, 1658 qosIpAceDstAddrMask IpAddress, 1659 qosIpAceSrcAddr IpAddress, 1660 qosIpAceSrcAddrMask IpAddress, 1661 qosIpAceDscp Integer32, 1662 qosIpAceProtocol INTEGER, 1663 qosIpAceDstL4PortMin INTEGER, 1664 qosIpAceDstL4PortMax INTEGER, 1665 qosIpAceSrcL4PortMin INTEGER, 1666 qosIpAceSrcL4PortMax INTEGER, 1667 qosIpAcePermit TruthValue } 1669 qosIpAceIndex OBJECT-TYPE 1670 SYNTAX PolicyInstanceId 1671 STATUS current 1672 DESCRIPTION 1673 "An integer index to uniquely identify this ACE among all 1674 the 1675 ACEs." 1677 ::= { qosIpAceEntry 1 } 1679 qosIpAceDstAddr OBJECT-TYPE 1680 SYNTAX IpAddress 1681 STATUS current 1682 DESCRIPTION 1683 "The IP address to match against the packet's destination 1684 IP 1685 address." 1687 ::= { qosIpAceEntry 2 } 1689 qosIpAceDstAddrMask OBJECT-TYPE 1690 SYNTAX IpAddress 1691 STATUS current 1692 DESCRIPTION 1693 "A mask for the matching of the destination IP address. 1694 A zero bit in the mask means that the corresponding bit 1695 in 1696 the address always matches." 1698 ::= { qosIpAceEntry 3 } 1700 qosIpAceSrcAddr OBJECT-TYPE 1701 SYNTAX IpAddress 1702 STATUS current 1703 DESCRIPTION 1704 "The IP address to match against the packet's source IP 1705 address." 1707 ::= { qosIpAceEntry 4 } 1709 qosIpAceSrcAddrMask OBJECT-TYPE 1710 SYNTAX IpAddress 1711 STATUS current 1712 DESCRIPTION 1713 "A mask for the matching of the source IP address." 1715 ::= { qosIpAceEntry 5 } 1717 qosIpAceDscp OBJECT-TYPE 1718 SYNTAX Integer32 (-1 | 0..63) 1719 STATUS current 1720 DESCRIPTION 1721 "The value that the DSCP in the packet can have and 1722 match this ACE. A value of -1 indicates that a specific 1723 DSCP value has not been defined and thus all DSCP values 1724 are considered a match." 1726 ::= { qosIpAceEntry 6 } 1728 qosIpAceProtocol OBJECT-TYPE 1729 SYNTAX INTEGER (0..255) 1730 STATUS current 1731 DESCRIPTION 1732 "The IP protocol to match against the packet's protocol. 1733 A value of zero means match all." 1735 ::= { qosIpAceEntry 7 } 1737 qosIpAceDstL4PortMin OBJECT-TYPE 1738 SYNTAX INTEGER (0..65535) 1739 STATUS current 1740 DESCRIPTION 1741 "The minimum value that the packet's layer 4 destination 1742 port number can have and match this ACE." 1744 ::= { qosIpAceEntry 8 } 1746 qosIpAceDstL4PortMax OBJECT-TYPE 1747 SYNTAX INTEGER (0..65535) 1748 STATUS current 1749 DESCRIPTION 1750 "The maximum value that the packet's layer 4 destination 1751 port number can have and match this ACE. This value must 1752 be 1753 equal to or greater that the value specified for this ACE 1754 in 1755 qosIpAceDstL4PortMin." 1757 ::= { qosIpAceEntry 9 } 1759 qosIpAceSrcL4PortMin OBJECT-TYPE 1760 SYNTAX INTEGER (0..65535) 1761 STATUS current 1762 DESCRIPTION 1763 "The minimum value that the packet's layer 4 source port 1764 number can have and match this ACE." 1766 ::= { qosIpAceEntry 10 } 1768 qosIpAceSrcL4PortMax OBJECT-TYPE 1769 SYNTAX INTEGER (0..65535) 1770 STATUS current 1771 DESCRIPTION 1772 "The maximum value that the packet's layer 4 source port 1773 number can have and match this ACE. This value must be 1774 equal 1775 to or greater that the value specified for this ACE in 1776 qosIpAceSrcL4PortMin." 1778 ::= { qosIpAceEntry 11 } 1780 qosIpAcePermit OBJECT-TYPE 1781 SYNTAX TruthValue 1782 STATUS current 1783 DESCRIPTION 1784 "If the packet matches this ACE and the value of this 1785 attribute is true, then the matching process terminates 1786 and the QoS associated with this ACE (indirectly through 1787 the ACL) is applied to the packet. If the value of this 1788 attribute is false, then no more ACEs in this ACL are 1789 compared to this packet and matching continues with the 1790 first ACE of the next ACL." 1792 ::= { qosIpAceEntry 12 } 1794 -- -- The IP ACL Definition Table -- 1796 qosIpAclDefinitionTable OBJECT-TYPE 1797 SYNTAX SEQUENCE OF QosIpAclDefinitionEntry 1798 POLICY-ACCESS install 1799 STATUS current 1800 DESCRIPTION 1801 "A class that defines a set of ACLs each being an ordered 1802 list 1803 of ACEs. Each instance of this class identifies one ACE 1804 of 1805 an ACL and the precedence order of that ACE with respect 1806 to 1807 other ACEs in the same ACL." 1809 INSTALL-ERRORS { 1810 priPrecedenceConflict(1) -- precedence conflict detected 1811 } 1813 ::= { qosIpQos 2 } 1815 qosIpAclDefinitionEntry OBJECT-TYPE 1816 SYNTAX QosIpAclDefinitionEntry 1817 STATUS current 1818 DESCRIPTION 1819 "An instance of the qosIpAclDefinition class." 1821 INDEX { qosIpAclDefinitionIndex } 1822 ::= { qosIpAclDefinitionTable 1 } 1824 QosIpAclDefinitionEntry ::= SEQUENCE { 1825 qosIpAclDefinitionIndex PolicyInstanceId, 1826 qosIpAclDefinitionAclId PolicyInstanceId, 1827 qosIpAclDefinitionAceId PolicyInstanceId, 1828 qosIpAclDefinitionAceOrder Unsigned32 } 1830 qosIpAclDefinitionIndex OBJECT-TYPE 1831 SYNTAX PolicyInstanceId 1832 STATUS current 1833 DESCRIPTION 1834 "Unique index of this policy rule instance." 1836 ::= { qosIpAclDefinitionEntry 1 } 1838 qosIpAclDefinitionAclId OBJECT-TYPE 1839 SYNTAX PolicyInstanceId 1840 STATUS current 1841 DESCRIPTION 1842 "An ID for this ACL. There will be one instance of 1843 the class qosIpAclDefinition with this ID for each ACE in 1844 the ACL per role combination." 1846 ::= { qosIpAclDefinitionEntry 2 } 1848 qosIpAclDefinitionAceId OBJECT-TYPE 1849 SYNTAX PolicyInstanceId 1850 STATUS current 1851 DESCRIPTION 1852 "This attribute specifies the ACE in the qosIpAceTable 1853 that 1854 is in the ACL specified by qosIpAclIndex at the position 1855 specified by qosIpAceOrder. 1857 Attempting to specify an unknown class instance will 1858 result 1859 in an appropriate error indication being returned to the 1860 entity that is attempting to install the conflicting 1861 entry. 1862 For example, a 'priUnknown(2)' error indication is 1863 returned 1864 to the policy server in this situation." 1866 ::= { qosIpAclDefinitionEntry 3 } 1868 qosIpAclDefinitionAceOrder OBJECT-TYPE 1869 SYNTAX Unsigned32 1870 STATUS current 1871 DESCRIPTION 1872 "The precedence order of this ACE. The precedence order 1873 determines the position of this ACE in the ACL. An ACE 1874 with 1875 a given precedence order is positioned in the access 1876 control 1877 list before one with a higher-valued precedence order. 1879 Precedence values within a group must be unique otherwise 1880 instance installation will be prohibited and an error 1881 value will be returned." 1883 ::= { qosIpAclDefinitionEntry 4 } 1885 END 1887 8.3. The QoS IEEE 802 PIB 1889 (1) QOS-POLICY-802-PIB PIB-DEFINITIONS ::= BEGIN 1891 IMPORTS 1892 Unsigned32, Integer32, 1893 MODULE-IDENTITY, OBJECT-TYPE 1894 FROM SNMPv2-SMI 1895 TruthValue, PhysAddress, 1896 TEXTUAL-CONVENTION 1897 FROM SNMPv2-TC 1898 RoleCombination, PolicyInstanceId 1899 FROM POLICY-FRAMEWORK-PIB 1900 Dscp 1901 FROM QOS-POLICY-IP-PIB; 1903 qosPolicy802Pib MODULE-IDENTITY 1904 LAST-UPDATED "9906241800Z" 1905 ORGANIZATION "IETF RAP WG" 1906 CONTACT-INFO " 1907 Michael Fine 1908 Cisco Systems, Inc. 1909 170 West Tasman Drive 1910 San Jose, CA 95134-1706 USA 1911 Phone: +1 408 527 8218 1912 Email: mfine@cisco.com 1914 Keith McCloghrie 1915 Cisco Systems, Inc. 1916 170 West Tasman Drive, 1917 San Jose, CA 95134-1706 USA 1918 Phone: +1 408 526 5260 1919 Email: kzm@cisco.com 1921 John Seligson 1922 Nortel Networks, Inc. 1923 4401 Great America Parkway 1924 Santa Clara, CA 95054 USA 1925 Phone: +1 408 495 2992 1926 Email: jseligso@nortelnetworks.com" 1927 DESCRIPTION 1928 "The PIB module containing an initial set of policy 1929 rule classes that describe the quality of service 1930 (QoS) policies supported by devices for IEEE 802- 1931 based traffic." 1933 ::= { tbd } 1935 qosPolicy802PibClasses OBJECT IDENTIFIER ::= { qosPolicy802Pib 1 1936 } 1938 -- -- Textual Conventions -- 1940 -- -- IEEE 802 CoS -- 1942 QosIeee802Cos ::= TEXTUAL-CONVENTION 1943 STATUS current 1944 DESCRIPTION 1945 "An integer that is in the range of the IEEE 802 CoS 1946 values. This corresponds to the 802.1p priority values." 1948 SYNTAX INTEGER (0..7) 1950 -- -- General configuration information for the entire domain -- 1952 qos802DomainConfig OBJECT IDENTIFIER ::= { qosPolicy802PibClasses 1953 1 } 1955 -- -- Differentiated Services Code Point Mapping Table -- -- 1956 Supports the mapping of DSCP values to IEEE CoS values. -- 1958 qos802DscpMappingTable OBJECT-TYPE 1959 SYNTAX SEQUENCE OF Qos802DscpMappingEntry 1960 POLICY-ACCESS install 1961 STATUS current 1962 DESCRIPTION 1963 "Maps each DSCP to an QosIeee802Cos. When configured 1964 for the first time, all 64 entries of the table must 1965 be specified. Thereafter, instances may be modified but 1966 not deleted unless all instances are deleted." 1968 INSTALL-ERRORS { 1969 priInstNotComplete(1) -- required instances not 1970 created 1971 } 1973 ::= { qos802DomainConfig 1 } 1975 qos802DscpMappingEntry OBJECT-TYPE 1976 SYNTAX Qos802DscpMappingEntry 1977 STATUS current 1978 DESCRIPTION 1979 "An instance of the qos802DscpMapping class. A total of 1980 64 1981 class instances are constantly maintained after initial 1982 device 1983 configuration." 1985 INDEX { qos802DscpMappingDscp } 1986 ::= { qos802DscpMappingTable 1 } 1988 Qos802DscpMappingEntry ::= SEQUENCE { 1989 qos802DscpMappingDscp Dscp, 1990 qos802DscpMapping802Cos QosIeee802Cos } 1992 qos802DscpMappingDscp OBJECT-TYPE 1993 SYNTAX Dscp 1994 STATUS current 1995 DESCRIPTION 1996 "The DSCP class instance attribute that is used to 1997 determine the appropriate layer 2 CoS mappings. DSCP 1998 values 0 through 63 (inclusive) are maintained in 1999 the table." 2001 ::= { qos802DscpMappingEntry 1 } 2003 qos802DscpMapping802Cos OBJECT-TYPE 2004 SYNTAX QosIeee802Cos 2005 STATUS current 2006 DESCRIPTION 2007 "The IEEE 802 CoS value to use when mapping the DSCP 2008 value specified by the qos802DscpMappingDscp attribute 2009 to a IEEE 802 CoS." 2011 ::= { qos802DscpMappingEntry 2 } 2013 -- -- Layer 2 CoS-to-DSCP Mapping Table -- -- Supports the 2014 mapping of IEEE CoS values to DSCP values -- for generic QoS 2015 traffic classification -- 2017 qos802CosToDscpTable OBJECT-TYPE 2018 SYNTAX SEQUENCE OF Qos802CosToDscpEntry 2019 POLICY-ACCESS install 2020 STATUS current 2021 DESCRIPTION 2022 "Maps each of eight layer 2 CoS values to a DSCP. When 2023 configured for the first time, all 8 entries of the table 2024 must be specified. Thereafter, instances may be modified 2025 but not deleted unless all instances are deleted." 2027 INSTALL-ERRORS { 2028 priInstNotComplete(1) -- required instances not 2029 created 2030 } 2032 ::= { qos802DomainConfig 2 } 2034 qos802CosToDscpEntry OBJECT-TYPE 2035 SYNTAX Qos802CosToDscpEntry 2036 STATUS current 2037 DESCRIPTION 2038 "An instance of the qosCosToDscp class. A total of 8 2039 class instances are constantly maintained after initial 2040 device configuration." 2042 INDEX { qos802CosToDscpCos } 2043 ::= { qos802CosToDscpTable 1 } 2045 Qos802CosToDscpEntry ::= SEQUENCE { 2046 qos802CosToDscpCos QosIeee802Cos, 2047 qos802CosToDscpDscp Dscp } 2049 qos802CosToDscpCos OBJECT-TYPE 2050 SYNTAX QosIeee802Cos 2051 STATUS current 2052 DESCRIPTION 2053 "The layer 2 CoS class instance attribute that is used to 2054 determine the appropriate DSCP mappings. CoS values 0 2055 through 7 (inclusive) are maintained in the table." 2057 ::= { qos802CosToDscpEntry 1 } 2059 qos802CosToDscpDscp OBJECT-TYPE 2060 SYNTAX Dscp 2061 STATUS current 2062 DESCRIPTION 2063 "The DSCP value to use when mapping the layer 2 CoS value 2064 specified by the qosCosToDscp attribute to a DSCP." 2066 ::= { qos802CosToDscpEntry 2 } 2068 -- -- The IEEE 802 Classification and Policing Group -- 2070 qos802Qos OBJECT IDENTIFIER ::= { qosPolicy802PibClasses 2 } 2072 -- -- The IEEE 802 ACE Table -- -- The IEEE 802 ACE Table 2073 supports the specification of IEEE -- 802-based (e.g., 802.3) 2074 information that is used to perform -- traffic classification. 2075 -- 2077 qos802AceTable OBJECT-TYPE 2078 SYNTAX SEQUENCE OF Qos802AceEntry 2079 POLICY-ACCESS install 2080 STATUS current 2081 DESCRIPTION 2082 "IEEE 802-based ACE definitions. A class that contains 2083 attributes of IEEE 802 (e.g., 802.3) traffic that form 2084 an association that is used to perform traffic 2085 classification." 2087 ::= { qos802Qos 1 } 2089 qos802AceEntry OBJECT-TYPE 2090 SYNTAX Qos802AceEntry 2091 STATUS current 2092 DESCRIPTION 2093 "IEEE 802-based ACE definitions. An entry specifies 2094 (potentially) several distinct matching components. Each 2095 component is tested against the data in a frame 2096 individually. An overall match occurs when all of the 2097 individual components match the data they are compared 2098 against in the frame being processed. A failure of any 2099 one test causes the overall match to fail. 2101 Wildcards may be specified for those fields that are not 2102 relevant." 2104 INDEX { qos802AceIndex } 2105 ::= { qos802AceTable 1 } 2107 Qos802AceEntry ::= SEQUENCE { 2108 qos802AceIndex PolicyInstanceId, 2109 qos802AceDstAddr PhysAddress, 2110 qos802AceDstAddrMask PhysAddress, 2111 qos802AceSrcAddr PhysAddress, 2112 qos802AceSrcAddrMask PhysAddress, 2113 qos802AceVlanId Integer32, 2114 qos802AceVlanTagRequired INTEGER, 2115 qos802AceEtherType Integer32, 2116 qos802AceUserPriority BITS, 2117 qos802AcePermit TruthValue } 2119 qos802AceIndex OBJECT-TYPE 2120 SYNTAX PolicyInstanceId 2121 STATUS current 2122 DESCRIPTION 2123 "An arbitrary integer index that uniquely identifies this 2124 802 ACE among all of the 802 ACEs. Note that this 2125 identifier 2126 is used in instances of the qos802Acl class to associate 2127 a 2128 802 ACE with a 802 ACL. An active ACE/ACL association 2129 prohibits the deletion of the 802 ACE until the ACE/ACL 2130 association is terminated. Class instances may not be 2131 contiguous." 2133 ::= { qos802AceEntry 1 } 2135 qos802AceDstAddr OBJECT-TYPE 2136 SYNTAX PhysAddress 2137 STATUS current 2138 DESCRIPTION 2139 "The 802 address against which the 802 DA of incoming 2140 traffic 2141 streams will be compared. Frames whose 802 DA matches the 2142 physical address specified by this object, taking into 2143 account 2144 address wildcarding as specified by the 2145 qos802AceDstAddrMask 2146 object, are potentially subject to the processing 2147 guidelines 2148 that are associated with this entry through the related 2149 action class." 2151 ::= { qos802AceEntry 2 } 2153 qos802AceDstAddrMask OBJECT-TYPE 2154 SYNTAX PhysAddress 2155 STATUS current 2156 DESCRIPTION 2157 "This object specifies the bits in a 802 destination 2159 address 2160 that should be considered when performing a 802 DA 2161 comparison 2162 against the address specified in the qos802AceDstAddr 2163 object. 2165 The value of this object represents a mask that is 2166 logically 2167 and'ed with the 802 DA in received frames to derive the 2168 value 2169 to be compared against the qos802AceDstAddr address. A 2170 zero 2171 bit in the mask thus means that the corresponding bit in 2172 the 2173 address always matches. The qos802AceDstAddr value must 2174 also 2175 be masked using this value prior to any comparisons. 2177 The length of this object in octets must equal the length 2178 in 2179 octets of the qos802AceDstAddr. Note that a mask with no 2180 bits 2181 set (i.e., all zeroes) effectively wildcards the 2182 qos802AceDstAddr object." 2184 ::= { qos802AceEntry 3 } 2186 qos802AceSrcAddr OBJECT-TYPE 2187 SYNTAX PhysAddress 2188 STATUS current 2189 DESCRIPTION 2190 "The 802 MAC address against which the 802 MAC SA of 2191 incoming 2192 traffic streams will be compared. Frames whose 802 MAC SA 2193 matches the physical address specified by this object, 2194 taking into account address wildcarding as specified by 2195 the 2196 qos802AceSrcAddrMask object, are potentially subject to 2197 the 2198 processing guidelines that are associated with this entry 2199 through the related action class." 2201 ::= { qos802AceEntry 4 } 2203 qos802AceSrcAddrMask OBJECT-TYPE 2204 SYNTAX PhysAddress 2205 STATUS current 2206 DESCRIPTION 2207 "This object specifies the bits in a 802 MAC source 2208 address 2209 that should be considered when performing a 802 MAC SA 2210 comparison against the address specified in the 2211 qos802AceSrcAddr object. 2213 The value of this object represents a mask that is 2214 logically 2215 and'ed with the 802 MAC SA in received frames to derive 2216 the 2217 value to be compared against the qos802AceSrcAddr 2218 address. A 2219 zero bit in the mask thus means that the corresponding 2220 bit 2221 in the address always matches. The qos802AceSrcAddr value 2222 must also be masked using this value prior to any 2223 comparisons. 2225 The length of this object in octets must equal the length 2226 in 2227 octets of the qos802AceSrcAddr. Note that a mask with no 2228 bits 2229 set (i.e., all zeroes) effectively wildcards the 2230 qos802AceSrcAddr object." 2232 ::= { qos802AceEntry 5 } 2234 qos802AceVlanId OBJECT-TYPE 2235 SYNTAX Integer32 (-1 | 1..4094) 2236 STATUS current 2237 DESCRIPTION 2238 "The VLAN ID (VID) that uniquely identifies a VLAN 2239 within the device. This VLAN may be known or unknown 2240 (i.e., traffic associated with this VID has not yet 2241 been seen by the device) at the time this entry 2242 is instantiated. 2244 Setting the qos802AceVlanId object to -1 indicates that 2245 VLAN data should not be considered during traffic 2246 classification." 2248 ::= { qos802AceEntry 6 } 2250 qos802AceVlanTagRequired OBJECT-TYPE 2251 SYNTAX INTEGER { 2252 taggedOnly(1), 2253 priorityTaggedPlus(2), 2254 untaggedOnly(3), 2255 ignoreTag(4) 2256 } 2257 STATUS current 2258 DESCRIPTION 2259 "This object indicates whether the presence of an 2260 IEEE 802.1Q VLAN tag in data link layer frames must 2261 be considered when determining if a given frame 2262 matches this 802 ACE entry. 2264 A value of 'taggedOnly(1)' means that only frames 2265 containing a VLAN tag with a non-Null VID (i.e., a 2266 VID in the range 1..4094) will be considered a match. 2268 A value of 'priorityTaggedPlus(2)' means that only 2269 frames containing a VLAN tag, regardless of the value 2270 of the VID, will be considered a match. 2272 A value of 'untaggedOnly(3)' indicates that only 2273 untagged frames will match this filter component. 2275 The presence of a VLAN tag is not taken into 2276 consideration in terms of a match if the value is 2277 'ignoreTag(4)'." 2279 ::= { qos802AceEntry 7 } 2281 qos802AceEtherType OBJECT-TYPE 2282 SYNTAX Integer32 (-1 | 0..'ffff'h) 2283 STATUS current 2284 DESCRIPTION 2285 "This object specifies the value that will be compared 2286 against the value contained in the EtherType field of an 2287 IEEE 802 frame. Example settings would include 'IP' 2288 (0x0800), 'ARP' (0x0806) and 'IPX' (0x8137). 2290 Setting the qos802AceEtherTypeMin object to -1 indicates 2291 that EtherType data should not be considered during 2292 traffic 2293 classification. 2295 Note that the position of the EtherType field depends on 2296 the underlying frame format. For Ethernet-II 2297 encapsulation, 2298 the EtherType field follows the 802 MAC source address. 2299 For 2300 802.2 LLC/SNAP encapsulation, the EtherType value follows 2301 the 2302 Organization Code field in the 802.2 SNAP header. The 2303 value 2304 that is tested with regard to this filter component 2305 therefore 2306 depends on the data link layer frame format being used. 2307 If 2308 this 802 ACE component is active when there is no 2309 EtherType 2310 field in a frame (e.g., 802.2 LLC), a match is implied." 2312 ::= { qos802AceEntry 8 } 2314 qos802AceUserPriority OBJECT-TYPE 2315 SYNTAX BITS { 2316 matchPriority0(0), 2317 matchPriority1(1), 2318 matchPriority2(2), 2319 matchPriority3(3), 2320 matchPriority4(4), 2321 matchPriority5(5), 2322 matchPriority6(6), 2323 matchPriority7(7) 2324 } 2325 STATUS current 2326 DESCRIPTION 2327 "The set of values, representing the potential range 2328 of user priority values, against which the value 2329 contained 2330 in the user priority field of a tagged 802.1 frame is 2331 compared. A test for equality is performed when 2332 determining 2333 if a match exists between the data in a data link layer 2334 frame and the value of this 802 ACE component. Multiple 2335 values may be set at one time such that potentially 2336 several 2337 different user priority values may match this 802 ACE 2338 component. 2340 Setting all of the bits that are associated with this 2341 object causes all user priority values to match this 2342 attribute. This essentially makes any comparisons 2343 with regard to user priority values unnecessary. Untagged 2344 frames are treated as an implicit match." 2346 ::= { qos802AceEntry 9 } 2348 qos802AcePermit OBJECT-TYPE 2349 SYNTAX TruthValue 2350 STATUS current 2351 DESCRIPTION 2352 "If the frame matches this ACE and the value of this 2353 attribute is true, then the matching process terminates 2354 and the QoS associated with this 802-based ACE 2355 (indirectly 2356 through the 802 ACL) is applied to the packet. If the 2357 value of this attribute is false, then no more 802 ACEs 2358 in 2359 this 802 ACL are compared to this packet and matching 2360 continues with the first 802-based ACE of the next 802 2361 ACL." 2363 ::= { qos802AceEntry 10 } 2365 -- -- The IEEE 802 ACL Definition Table -- -- The IEEE 802 ACL 2366 Definition Table supports the association of -- distinct IEEE 2367 802-based (e.g., 802.3) traffic classification -- specifications 2368 into an ordered list. -- 2370 qos802AclDefinitionTable OBJECT-TYPE 2371 SYNTAX SEQUENCE OF Qos802AclDefinitionEntry 2372 POLICY-ACCESS install 2373 STATUS current 2374 DESCRIPTION 2375 "IEEE 802-based ACL definitions. A class that defines a 2376 set of 802 ACLs, each of which is comprised of an ordered 2377 list of 802 ACEs." 2379 INSTALL-ERRORS { 2380 priPrecedenceConflict(1) -- precedence conflict detected 2381 } 2383 ::= { qos802Qos 2 } 2385 qos802AclDefinitionEntry OBJECT-TYPE 2386 SYNTAX Qos802AclDefinitionEntry 2387 STATUS current 2388 DESCRIPTION 2389 "IEEE 802-based ACL definitions. An entry specifies an 2390 instance of this class that associates an 802 ACE with 2391 a given 802 ACL. The evaluation order of distinct 802 2392 ACEs that are associated with a specific 802 ACL is 2393 specified as well." 2395 INDEX { qos802AclDefinitionIndex } 2396 ::= { qos802AclDefinitionTable 1 } 2398 Qos802AclDefinitionEntry ::= SEQUENCE { 2399 qos802AclDefinitionIndex PolicyInstanceId, 2400 qos802AclDefinitionAclId PolicyInstanceId, 2401 qos802AclDefinitionAceId PolicyInstanceId, 2402 qos802AclDefinitionAceOrder Unsigned32 } 2404 qos802AclDefinitionIndex OBJECT-TYPE 2405 SYNTAX PolicyInstanceId 2406 STATUS current 2407 DESCRIPTION 2408 "An arbitrary integer index that uniquely identifies this 2409 802 ACE / 802 ACL association." 2411 ::= { qos802AclDefinitionEntry 1 } 2413 qos802AclDefinitionAclId OBJECT-TYPE 2414 SYNTAX PolicyInstanceId 2415 STATUS current 2416 DESCRIPTION 2417 "An index for this 802 ACL. Each 802 ACL in the device is 2418 assigned a unique integer index. There will (potentially) 2419 be 2420 multiple instances of the qos802AclDefinition class with 2421 this 2422 identifier, one for each 802 ACE that is associated with 2423 the 2424 specified 802 ACL. 2426 For example, assume that 2 802 ACLs, each comprised of 4 2427 802 2428 ACEs, have been installed. The instances of this class 2429 may 2430 appear as follows: 2432 Index AclId AceId AceOrder 2433 10 6 4 1 2434 11 6 5 2 2435 12 6 9 23 2436 13 6 11 24 2437 65 18 5 8 2438 66 18 9 12 2439 67 18 13 15 2440 70 18 14 16 2442 Note that this identifier is used in instances of the 2443 qosAclTarget class to associate an 802 ACL with an 2444 interface 2445 set and action. An active ACL Target association 2446 prohibits 2447 the deletion of all of the qos802AclDefinition instances 2448 with a given qos802AclDefinitionAclId (i.e., at least one 2449 entry for the specific qos802AclDefinitionAclId must be 2450 present in this table) until the ACL Target association 2451 is 2452 terminated." 2454 ::= { qos802AclDefinitionEntry 2 } 2456 qos802AclDefinitionAceId OBJECT-TYPE 2457 SYNTAX PolicyInstanceId 2458 STATUS current 2459 DESCRIPTION 2460 "This attribute identifies the 802 ACE in the 2461 qos802AceTable 2462 that is associated with the 802 ACL specified by 2463 qos802AclDefinitionAclId object. The corresponding 2464 instance 2465 in the qos802Ace class must exist prior to being 2466 associated 2467 with a 802 ACL. 2469 Attempting to specify an unknown class instance will 2470 result 2471 in an appropriate error indication being returned to the 2472 entity that is attempting to install the conflicting 2473 entry. 2474 For example, a 'priUnknown(2)' error indication is 2476 returned 2477 to the policy server in this situation." 2479 ::= { qos802AclDefinitionEntry 3 } 2481 qos802AclDefinitionAceOrder OBJECT-TYPE 2482 SYNTAX Unsigned32 2483 STATUS current 2484 DESCRIPTION 2485 "The precedence of the 802 ACE, identified via the 2486 qos802AclDefinitionAceId object, with regard to 2487 evaluation 2488 order. The precedence determines the order of evaluation 2489 of 2490 this ACE in relation to related 802 ACEs that are 2491 associated 2492 with an ACL. An ACE with a given precedence order in the 2493 access control list is evaluated before one with a 2494 higher- 2495 valued precedence order. 2497 Precedence values within a group must be unique otherwise 2498 instance installation will be prohibited and an error 2499 value will be returned. 2501 Note that qos802AclDefinitionAceOrder values within a 2502 given 2503 ACL need not be contiguous." 2505 ::= { qos802AclDefinitionEntry 4 } 2507 END 2509 9. Security Considerations 2511 The information contained in a PIB when transported by the COPS protocol 2512 [COPS-PR] may be sensitive, and its function of provisioning a PEP 2513 requires that only authorized communication take place. The use of 2514 IPSEC between PDP and PEP, as described in [COPS], provides the 2515 necessary protection against these threats. 2517 10. Intellectual Property Considerations 2519 The IETF is being notified of intellectual property rights claimed in 2520 regard to some or all of the specification contained in this document. 2521 For more information consult the online list of claimed rights. 2523 11. Authors' Addresses 2525 Michael Fine 2526 Cisco Systems, Inc. 2527 170 West Tasman Drive 2528 San Jose, CA 95134-1706 USA 2529 Phone: +1 408 527 8218 2530 Email: mfine@cisco.com 2532 Keith McCloghrie 2533 Cisco Systems, Inc. 2534 170 West Tasman Drive 2535 San Jose, CA 95134-1706 USA 2536 Phone: +1 408 526 5260 2537 Email: kzm@cisco.com 2539 John Seligson 2540 Nortel Networks, Inc. 2541 4401 Great America Parkway 2542 Santa Clara, CA 95054 USA 2543 Phone: +1 408 495 2992 2544 Email: jseligso@nortelnetworks.com 2546 Kwok Ho Chan 2547 Nortel Networks, Inc. 2548 600 Technology Park Drive 2549 Billerica, MA 01821 USA 2550 Phone: +1 978 288 8175 2551 Email: khchan@nortelnetworks.com 2552 Scott Hahn 2553 Intel 2554 2111 NE 25th Avenue 2555 Hillsboro, OR 97124 USA 2556 Phone: +1 503 264 8231 2557 Email: scott.hahn@intel.com 2559 Andrew Smith 2560 Extreme Networks 2561 10460 Bandley Drive 2562 Cupertino CA 95014 USA 2563 Phone: +1 408 342 0999 2564 Email: andrew@extremenetworks.com 2566 12. References 2568 [COPS] J. Boyle, R. Cohen, D. Durham, S. Herzog, R. Rajan, A. Sastry, 2569 "The COPS (Common Open Policy Service) Protocol" 2570 Internet-Draft, draft-ietf-rap-cops-06.txt, February 1999. 2572 [COPS-PR] F. Reichmeyer, S. Herzog, K. Chan, D. Durham, R. Yavatkar, 2573 S. Gai, K. McCloghrie, A. Smith, "COPS Usage for Policy 2574 Provisioning," draft-ietf-rap-pr-00.txt, June 1999. 2576 [QOS-POL] S. Gai, J. Strassner, D. Durham, S. Herzog, H. Mahon, 2577 F. Reichmeyer, "QoS Policy Framework Architecture", 2578 draft-sgai-policy-framework-00.txt, February 1999. 2580 [RAP-FRAMEWORK] R. Yavatkar, D. Pendarakis, "A Framework for 2581 Policy-based Admission Control", 2582 draft-ietf-rap-framework-03.txt, April 1999. 2584 [SNMP-SMI] K. McCloghrie, D. Perkins, J. Schoenwaelder, J. Case, 2585 M. Rose and S. Waldbusser, "Structure of Management Information 2586 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 2588 [MODEL] Y. Bernet, A. Smith, S. Blake, "A Conceptual Model for 2589 Diffserv Routers", draft-ietf-diffserv-model-00.txt, June 2590 1999. 2592 Table of Contents 2594 1 Glossary ........................................................ 2 2595 2 Introduction .................................................... 2 2596 3 The Structure of Policy Information ............................. 2 2597 3.1 Differences from SMIv2 ........................................ 3 2598 3.2 Mapping the PIB to a MIB ...................................... 3 2599 3.3 Error Codes ................................................... 5 2600 4 General PIB Concepts ............................................ 5 2601 4.1 Roles ......................................................... 5 2602 4.2 Reporting of Device Capabilities .............................. 6 2603 5 DiffServ PIB Concepts ........................................... 7 2604 5.1 Filters, Filter Groups and Classifiers ........................ 7 2605 5.2 Applying QoS Policy Using Targets ............................. 7 2606 5.3 Queue Modeling with Queue Sets ................................ 8 2607 5.4 IP Mapping to and from Layer 2 ................................ 9 2608 6 Summary of the PIB Modules ...................................... 10 2609 7 PIB Operational Overview ........................................ 11 2610 8 PIB Definitions ................................................. 14 2611 8.1 The Policy Framework PIB Module ............................... 14 2612 8.2 The QoS IP PIB ................................................ 21 2613 8.3 The QoS IEEE 802 PIB .......................................... 45 2614 9 Security Considerations ......................................... 59 2615 10 Intellectual Property Considerations ........................... 59 2616 11 Authors' Addresses ............................................. 59 2617 12 References ..................................................... 60