idnits 2.17.1 draft-ietf-rap-frameworkpib-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The 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? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 6. Security Considerations' ) ** 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 an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 249: '... instance MUST ensure that the attri...' RFC 2119 keyword, line 701: '... active instance MUST become inactive ...' RFC 2119 keyword, line 703: '... MUST be set to false."...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1340 has weird spacing: '... to the numbe...' == Line 1376 has weird spacing: '... to the numbe...' -- 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 (September 19, 2000) is 8620 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) == Unused Reference: 'SNMP-SMI' is defined on line 2133, but no explicit reference was found in the text == Outdated reference: A later version (-05) exists of draft-ietf-rap-pr-04 ** Downref: Normative reference to an Historic draft: draft-ietf-rap-pr (ref. 'COPS-PR') == Outdated reference: A later version (-07) exists of draft-ietf-rap-sppi-02 ** Downref: Normative reference to an Historic draft: draft-ietf-rap-sppi (ref. 'SPPI') ** Downref: Normative reference to an Informational RFC: RFC 2753 (ref. 'RAP-FRAMEWORK') Summary: 15 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Fine 3 Internet Draft K. McCloghrie 4 Expires March 2001 Cisco Systems 5 J. Seligson 6 K. Chan 7 Nortel Networks 8 S. Hahn 9 R. Sahita 10 Intel 11 A. Smith 12 No Affiliation 13 Francis Reichmeyer 14 PFN 16 September 19, 2000 18 Framework Policy Information Base 20 draft-ietf-rap-frameworkpib-02.txt 22 Status of this Memo 24 This document is an Internet-Draft and is in full conformance with 25 all provisions of Section 10 of RFC2026. Internet-Drafts are 26 working documents of the Internet Engineering Task Force (IETF), its 27 areas, and its working groups. Note that other groups may also 28 distribute working documents as Internet-Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six 31 months and may be updated, replaced, or obsoleted by other documents 32 at any time. It is inappropriate to use Internet-Drafts as 33 reference material or to cite them other than as ''work in 34 progress''. 36 To view the current status of any Internet-Draft, please check the 37 ''1id-abstracts.txt'' listing contained in an Internet-Drafts Shadow 38 Directory, see http://www.ietf.org/shadow.html. 40 Framework Policy Information Base September 2000 42 1. Glossary 44 PRC Provisioning Class. A type of policy data. 45 PRI Provisioning Instance. An instance of a PRC. 46 PIB Policy Information Base. The database of policy information. 47 PDP Policy Decision Point. See [RAP-FRAMEWORK]. 48 PEP Policy Enforcement Point. See [RAP-FRAMEWORK]. 49 PRID Provisioning Instance Identifier. Uniquely identifies an 50 instance of a PRC. 52 2. Introduction 54 [SPPI] describes a structure for specifying policy information that 55 can then be transmitted to a network device for the purpose of 56 configuring policy at that device. The model underlying this 57 structure is one of well-defined provisioning classes and instances 58 of these classes residing in a virtual information store called the 59 Policy Information Base (PIB). 61 One way to provision policy is by means of the COPS protocol [COPS] 62 with the extensions for provisioning [COPS-PR]. This protocol 63 supports multiple clients, each of which may provision policy for a 64 specific policy domain such as QoS, virtual private networks, or 65 security. 67 As described in [COPS-PR], each client supports a non-overlapping 68 and independent set of PIB modules. However, some provisioning 69 classes are common to all subject-categories (client-types) and need 70 to be present in each. This document presents a set of PRCs that 71 are common to all clients that provision policy using COPS for 72 Provisioning. 74 3. General PIB Concepts 76 3.1. Roles 78 The policy to apply to an interface may depend on many factors such 79 as immutable characteristics of the interface (e.g., ethernet or 80 frame relay), the status of the interface (e.g., half or full 81 duplex), or user configuration (e.g., branch office or headquarters 82 interface). Rather than specifying policies explicitly for each 83 interface of all devices in the network, policies are specified in 84 terms of interface functionality. 86 To describe these functionalities of an interface we use the concept 87 of "roles". A role is simply a string that is associated with an 88 interface. A given interface may have any number of roles 89 simultaneously. Provisioning classes have an attribute called a 90 "role-combination" which is a lexicographically ordered set of 91 roles. Instances of a given provisioning class are applied to an 93 Framework Policy Information Base September 2000 95 interface if and only if the set of roles in the role combination 96 matches the set of the roles of the interface. 98 Thus, roles provide a way to bind policy to interfaces without 99 having to explicitly identify interfaces in a consistent manner 100 across all network devices. (The SNMP experience with ifIndex has 101 proved this to be a difficult task.) That is, roles provide a level 102 of indirection to the application of a set of policies to specific 103 interfaces. Furthermore, if the same policy is being applied to 104 several interfaces, that policy need be pushed to the device only 105 once, rather than once per interface, as long as the interfaces are 106 configured with the same role combination. 108 We point out that, in the event that the administrator needs to have 109 unique policy for each interface, this can be achieved by 110 configuring each interface with a unique role. 112 The PEP reports all its role combinations to the PDP in the initial 113 COPS request (REQ) message and in subsequent request messages 114 generated in response to COPS state synchronization (SSQ) requests 115 and local configuration changes. 117 The comparing of roles (or role combinations) is case sensitive. 119 By convention, when formatting the role-combination for exchange 120 within a protocol message, within a PIB/MIB object's value, or as a 121 printed value, the set is formatted in lexicographical order of the 122 role's ASCII values; that is, the role that is first is formatted 123 first. For example, "a+b" and "b+a" are NOT different role- 124 combinations; rather, they are different formatting of the same 125 role-combination, and hence for this example: 126 - "a+b" is the valid formatting of that role-combination, 127 - "b+a" is an invalid formatting of that role-combination. 129 The role-combination of interfaces to which no roles have been 130 assigned is known as the "null" role-combination. (Note the 131 deliberate use of lower-case letters for "null" so that it avoids 132 confusion with the ASCII NULL character that has a value of zero but 133 a length of one.) 135 In an "install" or an "install-notify" class, the wildcard role- 136 combination "*" can be used. In addition to providing for interface- 137 specific roles, it also allows for other optimizations in reducing 138 the number of role-combinations for which a policy has to be 139 specified. For example: 141 Suppose we have three interfaces: 143 Roles A, B and R1 are assigned to interface I1 144 Roles A, B and R2 are assigned to interface I2 145 Roles A, B and R3 are assigned to interface I3 147 Framework Policy Information Base September 2000 149 Then, a PRI of a fictional IfDscpAssignTable that has the following 150 values for its attributes: 152 IfDscpAssignPrid = 1 153 IfDscpAssignRoles = "*+A+B" 154 IfDscpAssignName = "4queues" 155 IfDscpAssignDscpMap = 1 157 will apply to all three interfaces, because "*" matches with R1, R2 158 and R3. 160 Formally, 161 - The wildcard role is denoted by "*", 162 - The "*" role is not allowed to be defined as part of the role- 163 combination of an interface as notified by the PEP to the PDP; it 164 is only allowed in policies installed/deleted via COPS-PR from 165 the PDP to the PEP. 166 - For a policy to apply to an interface when the policy's role- 167 combination is "*+a+b", then the interface's role-combination: 168 - Must include "a" and "b", and 169 - Can include zero or more other roles. 170 - The wildcard character "*" is listed before the other roles as 171 "*" is lexicographically before "a"; however, the wildcard matches 172 any zero or more roles, irrespective of lexicographical order. 173 For example: "*+b+e+g" would match "a+b+c+e+f+g" 175 3.1.1. An Example 177 The functioning of roles might be best understood by an example. 178 Suppose I have a device with three interfaces, with roles as 179 follows: 181 IF1: "finance" 182 IF2: "finance" 183 IF3: "manager" 185 Suppose, I also have a PDP with two policies: 187 P1: Packets from finance department (role "finance") get DSCP 5 188 P2: Packets from managers (role "manager") get DSCP 6 190 To obtain policy, the PEP reports to the PDP that it has some 191 interfaces with role combination "finance" and some with role 192 combination "manager". In response, the PDP downloads policy P1 193 associated with role combination "finance" and downloads a second 194 policy P2 associated with role combination "manager". 196 Now suppose the finance person attached to IF2 is promoted to 197 manager and so the system administrator adds the role "manager" to 198 IF2. The PEP now reports to the PDP that it has three role 200 Framework Policy Information Base September 2000 202 combinations: some interfaces with role combination "finance", some 203 with role combination "manager" and some with role combination 204 "finance+manager". In response, the PDP downloads an additional 205 third policy associated with the new role combination 206 "finance+manager". 208 How the PDP determines the policy for this new role combination is 209 entirely the responsibility of the PDP. It could do so 210 algorithmically or by rule. For example, there might be a rule that 211 specifies that manager policy takes preference over department 212 policy. Or there might be a third policy installed in the PDP as 213 follows: 215 P3: Packets from finance managers (role "finance" and role 216 "manager") get DSCP 7 218 The point here is that the PDP is required to determine what policy 219 applies to this new role combination and to download a third policy 220 to the PEP for the role combination "finance+manager" even if that 221 policy is the same as one already downloaded. The PEP is not 222 required (or allowed) to construct policy for new role combinations 223 from existing policy. 225 3.2. Multiple PIB Instances 227 [COPS-PR] supports multiple, disjoint, independent instances of the 228 PIB to represent multiple instances of configured policy. The 229 intent is to allow for the pre-provisioning of policy that can then 230 be made active by a single, short decision from the PDP. 232 A COPS context can be defined as an independent COPS request state 233 for a particular subject category (client-type). 235 With the COPS-PR protocol, each of these states are identified by a 236 unique client handle. The creation and deletion of these PIB 237 instances is controlled by the PDP as described in [COPS-PR]. 239 Although many PIB instances may be configured on a device (the 240 maximum number of these instances being determined by the device 241 itself) only one of them can be active at any given time, the active 242 one being selected by the PDP. To facilitate this selection, the 243 Framework PIB supports an attribute to make a PIB instance the 244 active one and, similarly, to report the active PIB instance to the 245 PDP in a COPS request message. This attribute is in the Incarnation 246 Table described below. 248 Setting the attribute FrwkPibIncarnationActive to 'true' in one PIB 249 instance MUST ensure that the attribute is 'false' in all other 250 contexts. 252 Framework Policy Information Base September 2000 254 3.3. Reporting of Device Capabilities 256 Each network device providing policy-based services has its own 257 inherent capabilities. These capabilities can be hardware specific, 258 e.g., an ethernet interface supporting input classification, or can 259 be statically configured, e.g., supported queuing disciplines. 260 These capabilities are communicated to the PDP when initial policy 261 is requested by the PEP. Knowing device capabilities, the PDP can 262 send the provisioning instances (PRIs) relevant to the specific 263 device, rather than sending the entire PIB. 265 The PIB indicates which capabilities the PEP must report to the PDP 266 by means of the PIB-ACCESS clause as described in [SPPI]. 268 3.4. Reporting of Device Limitations 270 To facilitate efficient policy installation, it is important to 271 understand a device's limitations in relation to the advertised 272 device capabilities. Limitations may be class-based, e.g., an 273 "install" class is supported as a "notify" or only a limited number 274 of class instances may be created, or attribute-based. Attribute 275 limitations, such as supporting a restricted set of enumerations or 276 requiring related attributes to have certain values, detail 277 implementation limitations at a fine level of granularity. 279 A PDP can avoid certain installation issues in a proactive fashion 280 by taking into account a device's limitations prior to policy 281 installation rather than in a reactive mode during installation. As 282 with device capabilities, device limitations are communicated to the 283 PDP when initial policy is requested. 285 Reported device limitations may be accompanied by guidance values 286 that can be used by a PDP to determine acceptable values for the 287 identified attributes. 289 4. Summary of the Framework PIB 291 The Framework PIB comprises of three groups: 293 1. Base PIB classes Group 295 This contains PRCs intended to describe the PRCs supported 296 by the PEP, PRC and/or attribute limitations and its current 297 configuration. 299 PRC Support Table 301 As the technology evolves, we expect devices to be enhanced 302 with new PIBs, existing PIBs to add new PRCs and existing PRCs 303 to be augmented or extended with new attributes. Also, it is 304 likely that some existing PRCs or individual attributes of PRCs 305 will be deprecated. The PRC Support Table describes the PRCs 307 Framework Policy Information Base September 2000 309 that the device supports as well as the individual attributes 310 of each PRC. Using this information the PDP can potentially 311 tailor the policy to more closely match the capabilities of the 312 device. The PRC Support Table instances are specific to the 313 particular Subject Category (Client-Type). That is, the PRC 314 Support Table for Subject Category 'A' will not include 315 instances for classes supported by the Subject Category 'B'. 317 PIB Incarnation Table 319 This table contains exactly one row (corresponding to one PRI) 320 per context. It identifies the PDP that was the last to 321 download policy into the device and also contains an identifier 322 to identify the version of the policy currently downloaded. 323 This identifier, both its syntax and value, is meaningful only 324 to the PDPs. It is intended to be a mechanism whereby a PDP, 325 on connecting to a PEP, can easily identify a known incarnation 326 of policy. The incarnation PRC also includes an attribute to 327 indicate which context is the active one at the present time. 329 Component Limitations Table 331 Some devices may not be able to implement the full range of 332 values for all attributes. In principle, each PRC supports a 333 set of errors that the PEP can report to the PDP in the event 334 that the specified policy is not implementable. There are two 335 problems with this: it may be preferable for the PDP to be 336 informed of the device limitations before actually attempting 337 to install policy, and while the error can indicate that a 338 particular attribute value is unacceptable to the PEP, this 339 does not help the PDP ascertain which values would be 340 acceptable. To alleviate these limitations, the PEP can report 341 some limitations of attribute values and/or classes in the 342 Component Limitations Table. 344 Device Identification Table 346 This class contains a single provisioning instance that 347 contains device-specific information that is used to facilitate 348 efficient policy installation by a PDP. The instance of this 349 class is reported to the PDP in a COPS request message so that 350 the PDP can take into account certain device characteristics 351 during policy installation. 353 2. Device Capabilities group 355 This group contains the PRCs that describe the characteristics of 356 interfaces of the device and the Role Combinations assigned to 357 them. 359 Interface Capabilities Set Table 361 The interfaces the PEP supports are described by rows in 363 Framework Policy Information Base September 2000 365 this table (frwkIfCapSetTable). Each row, or instance of this 366 class, assigns a name to the interface and has references to 367 capabilities that the interface supports. The references can 368 specify instances in relevant capability tables in any PIB. The 369 PEP notifies the PDP of these interface names and capabilities 370 and then the PDP configures the interfaces, per role 371 combination. 373 Interface Capability and Role Combo Table 375 The Interface Capabilities Set Table describes the interfaces 376 the PEP supports by their capabilities. Configuration is done 377 in terms of these interface capability set names (ifCapSetName) 378 and the role combinations assigned to them; The PDP does not 379 deal with individual interfaces on the device. Each row of this 380 class is a 381 two-tuple. 383 3. Classifier group 385 This group contains the IP and IEEE 802 Classifier elements. 386 The set of tables consist of a Base Filter table that contains 387 the Index InstanceId and the Permit flag for the filter. This 388 frwkBaseFilterTable is extended to form the IP Filter table 389 and the 802 Filter table. 391 The Extended classes do not have a separate Index value. 392 Instances of the extended classes have the same indices as 393 their base class instance. Inheritance is achieved using the 394 EXTENDS keyword as defined in [SPPI]. The Filter Group 395 Definition table uses ReferenceId Textual Convention semantics 396 to reference filter instances and TagId and TagReferenceId 397 Textual Convention semantics [SPPI] to form sets of filters 398 that could be referenced by some other association table 399 instance. 401 Framework Policy Information Base September 2000 403 5. The Framework PIB Module 405 FRAMEWORK-PIB PIB-DEFINITIONS ::= BEGIN 407 IMPORTS 408 Unsigned32, Integer32, MODULE-IDENTITY, 409 MODULE-COMPLIANCE, OBJECT-TYPE 410 FROM COPS-PR-SPPI 411 InstanceId, ReferenceId, Prid, TagId 412 FROM COPS-PR-SPPI-TC 413 InetAddress, InetAddressType 414 FROM INET-ADDRESS-MIB 415 TruthValue, TEXTUAL-CONVENTION, PhysAddress 416 FROM SNMPv2-TC 417 Role, RoleCombination 418 FROM POLICY-DEVICE-AUX-MIB 419 SnmpAdminString 420 FROM SNMP-FRAMEWORK-MIB 421 OBJECT-GROUP 422 FROM SNMPv2-CONF; 424 frameworkPib MODULE-IDENTITY 425 SUBJECT-CATEGORIES { all } 426 LAST-UPDATED "200009061200Z" 427 ORGANIZATION "IETF RAP WG" 428 CONTACT-INFO " 429 Michael Fine 430 Cisco Systems, Inc. 431 170 West Tasman Drive 432 San Jose, CA 95134-1706 USA 433 Phone: +1 408 527 8218 434 Email: mfine@cisco.com 436 Keith McCloghrie 437 Cisco Systems, Inc. 438 170 West Tasman Drive, 439 San Jose, CA 95134-1706 USA 440 Phone: +1 408 526 5260 441 Email: kzm@cisco.com 443 John Seligson 444 Nortel Networks, Inc. 445 4401 Great America Parkway 446 Santa Clara, CA 95054 USA 447 Phone: +1 408 495 2992 448 Email: jseligso@nortelnetworks.com" 449 DESCRIPTION 450 "A PIB module containing the base set of provisioning 451 classes that are required for support of policies for 452 all subject-categories." 454 ::= { tbd } 456 Framework Policy Information Base September 2000 458 -- 459 -- The root OID for PRCs in the Framework PIB 460 -- 462 frwkBasePibClasses 463 OBJECT IDENTIFIER ::= { frameworkPib 1 } 465 -- 466 -- Textual Conventions 467 -- 469 -- 470 -- PRC Support Table 471 -- 473 frwkPrcSupportTable OBJECT-TYPE 474 SYNTAX SEQUENCE OF FrwkPrcSupportEntry 475 PIB-ACCESS notify,5 476 STATUS current 477 DESCRIPTION 478 "Each instance of this class specifies a PRC that the device 479 supports and a bit string to indicate the attributes of the 480 class that are supported. These PRIs are sent to the PDP to 481 indicate to the PDP which PRCs, and which attributes of 482 these PRCs, the device supports. This table can also be 483 downloaded by a network manager when static configuration is 484 used. 486 All install and install-notify PRCs supported by the device 487 must be represented in this table. Notify PRCs may be 488 represented for informational purposes." 490 ::= { frwkBasePibClasses 1 } 492 frwkPrcSupportEntry OBJECT-TYPE 493 SYNTAX FrwkPrcSupportEntry 494 STATUS current 495 DESCRIPTION 496 "An instance of the frwkPrcSupport class that identifies a 497 specific PRC and associated attributes as supported 498 by the device." 500 PIB-INDEX { frwkPrcSupportPrid } 501 UNIQUENESS { frwkPrcSupportSupportedPrc } 503 ::= { frwkPrcSupportTable 1 } 505 Framework Policy Information Base September 2000 507 FrwkPrcSupportEntry ::= SEQUENCE { 508 frwkPrcSupportPrid InstanceId, 509 frwkPrcSupportSupportedPrc OBJECT IDENTIFIER, 510 frwkPrcSupportSupportedAttrs OCTET STRING, 511 frwkPrcSupportMaxPris Unsigned32 512 } 514 frwkPrcSupportPrid OBJECT-TYPE 515 SYNTAX InstanceId 516 STATUS current 517 DESCRIPTION 518 "An arbitrary integer index that uniquely identifies an 519 instance of the frwkPrcSupport class." 521 ::= { frwkPrcSupportEntry 1 } 523 frwkPrcSupportSupportedPrc OBJECT-TYPE 524 SYNTAX OBJECT IDENTIFIER 525 STATUS current 526 DESCRIPTION 527 "The object identifier of a supported PRC. There may not 528 be more than one instance of the frwkPrcSupport class with 529 the same value of frwkPrcSupportSupportedPrc." 531 ::= { frwkPrcSupportEntry 2 } 533 frwkPrcSupportSupportedAttrs OBJECT-TYPE 534 SYNTAX OCTET STRING 535 STATUS current 536 DESCRIPTION 537 "A bit string representing the supported attributes of the 538 class that is identified by the frwkPrcSupportSupportedPrc 539 object. 541 Each bit of this bit mask corresponds to a class attribute, 542 with the most significant bit of the i-th octet of this 543 octet string corresponding to the (8*i - 7)-th attribute, 544 and the least significant bit of the i-th octet 545 corresponding to the (8*i)-th class attribute. Each bit of 546 this bit mask specifies whether or not the corresponding 547 class attribute is currently supported, with a '1' 548 indicating support and a '0' indicating no support. If the 549 value of this bit mask is N bits long and there are more 550 than N class attributes then the bit mask is logically 551 extended with 0's to the required length." 553 ::= { frwkPrcSupportEntry 3 } 555 Framework Policy Information Base September 2000 557 frwkPrcSupportMaxPris OBJECT-TYPE 558 SYNTAX Unsigned32 559 STATUS current 560 DESCRIPTION 561 "A non-negative value indicating the maximum number of 562 provisioning instances that can be installed in the 563 identified provisioning class. Note that actual number of 564 PRIs that can be installed in a PRC at any given time may be 565 less than this value based on the current operational state 566 (e.g.,resources currently consumed) of the device." 568 ::= { frwkPrcSupportEntry 4 } 570 -- 571 -- PIB Incarnation Table 572 -- 574 frwkPibIncarnationTable OBJECT-TYPE 575 SYNTAX SEQUENCE OF FrwkPibIncarnationEntry 576 PIB-ACCESS install-notify,7 577 STATUS current 578 DESCRIPTION 579 "This class contains a single provisioning instance per 580 installed context that identifies the current incarnation 581 of the PIB and the PDP or network manager that installed 582 this incarnation. The instance of this class is reported to 583 the PDP in the REQ message so that the PDP can (attempt to) 584 ascertain the current state of the PIB and the active 585 context. A network manager may use the instance to 586 determine the state of the device with regard to existing 587 NMS interactions." 589 ::= { frwkBasePibClasses 2 } 591 frwkPibIncarnationEntry OBJECT-TYPE 592 SYNTAX FrwkPibIncarnationEntry 593 STATUS current 594 DESCRIPTION 595 "An instance of the frwkPibIncarnation class. Only 596 one instance of this policy class is ever instantiated. 597 per context" 599 PIB-INDEX { frwkPibIncarnationPrid } 600 UNIQUENESS { frwkPibIncarnationName } 602 ::= { frwkPibIncarnationTable 1 } 604 Framework Policy Information Base September 2000 606 FrwkPibIncarnationEntry ::= SEQUENCE { 607 frwkPibIncarnationPrid InstanceId, 608 frwkPibIncarnationName SnmpAdminString, 609 frwkPibIncarnationId OCTET STRING, 610 frwkPibIncarnationLongevity INTEGER, 611 frwkPibIncarnationTtl Unsigned32, 612 frwkPibIncarnationActive TruthValue 613 } 615 frwkPibIncarnationPrid OBJECT-TYPE 616 SYNTAX InstanceId 617 STATUS current 618 DESCRIPTION 619 "An index to uniquely identify an instance of this 620 policy class." 622 ::= { frwkPibIncarnationEntry 1 } 624 frwkPibIncarnationName OBJECT-TYPE 625 SYNTAX SnmpAdminString 626 STATUS current 627 DESCRIPTION 628 "The name of the PDP that installed the current incarnation 629 of the PIB into the device. By default, it is the zero 630 length string." 632 ::= { frwkPibIncarnationEntry 2 } 634 frwkPibIncarnationId OBJECT-TYPE 635 SYNTAX OCTET STRING 636 STATUS current 637 DESCRIPTION 638 "An ID to identify the current incarnation. It has meaning 639 to the PDP/manager that installed the PIB and perhaps its 640 standby PDPs/managers. By default, it is the zero-length 641 string." 643 ::= { frwkPibIncarnationEntry 3 } 645 Framework Policy Information Base September 2000 647 frwkPibIncarnationLongevity OBJECT-TYPE 648 SYNTAX INTEGER { 649 expireNever(1), 650 expireImmediate(2), 651 expireOnTimeout(3) 652 } 653 STATUS current 654 DESCRIPTION 655 "This attribute controls what the PEP does with the 656 downloaded policy on a Client Close message or a loss of 657 connection to the PDP. 659 If set to expireNever, the PEP continues to operate with the 660 installed policy indefinitely. If set to expireImmediate, 661 the PEP immediately expires the policy obtained from the PDP 662 and installs policy from local configuration. If set to 663 expireOnTimeout, the PEP continues to operate with the 664 policy installed by the PDP for a period of time specified 665 by frwkPibIncarnationTtl. After this time (and it has not 666 reconnected to the original or new PDP) the PEP expires this 667 policy and reverts to local configuration. 669 For all cases, it is the responsibility of the PDP to check 670 the incarnation and download new policy, if necessary, on a 671 reconnect. 673 Policy enforcement timing only applies to policies that have 674 been installed dynamically (e.g., by a PDP via COPS)." 676 ::= { frwkPibIncarnationEntry 4 } 678 frwkPibIncarnationTtl OBJECT-TYPE 679 SYNTAX Unsigned32 680 STATUS current 681 DESCRIPTION 682 "The number of seconds after a Client Close or TCP timeout 683 for which the PEP continues to enforce the policy in the 684 PIB. After this interval, the PIB is considered expired and 685 the device no longer enforces the policy installed in the 686 PIB. 688 This attribute is only meaningful if 689 frwkPibIncarnationLongevity is set to expireOnTimeout." 691 ::= { frwkPibIncarnationEntry 5 } 693 Framework Policy Information Base September 2000 695 frwkPibIncarnationActive OBJECT-TYPE 696 SYNTAX TruthValue 697 STATUS current 698 DESCRIPTION 699 "If this attribute is set to TRUE, then the PIB instance 700 to which this PRI belongs becomes the active PIB instance. 701 The previous active instance MUST become inactive and the 702 frwkPibIncarnationActive attribute in that PIB instance 703 MUST be set to false." 705 ::= { frwkPibIncarnationEntry 6 } 707 -- 708 -- Device Identification Table 709 -- 711 -- This table supports the ability to export general 712 -- purpose device information to facilitate efficient 713 -- communication between the device and a PDP 715 frwkDeviceIdTable OBJECT-TYPE 716 SYNTAX SEQUENCE OF FrwkDeviceIdEntry 717 PIB-ACCESS notify,5 718 STATUS current 719 DESCRIPTION 720 "This class contains a single provisioning instance that 721 contains device-specific information that is used to 722 facilitate efficient policy installation by a PDP. The 723 instance of this class is reported to the PDP in a COPS 724 request message so that the PDP can take into account 725 certain device characteristics during policy installation." 727 ::= { frwkBasePibClasses 3 } 729 frwkDeviceIdEntry OBJECT-TYPE 730 SYNTAX FrwkDeviceIdEntry 731 STATUS current 732 DESCRIPTION 733 "An instance of the frwkDeviceId class. Only one instance of 734 this policy class is ever instantiated." 736 PIB-INDEX { frwkDeviceIdPrid } 737 UNIQUENESS { frwkDeviceIdDescr } 739 ::= { frwkDeviceIdTable 1 } 741 Framework Policy Information Base September 2000 743 FrwkDeviceIdEntry ::= SEQUENCE { 744 frwkDeviceIdPrid InstanceId, 745 frwkDeviceIdDescr SnmpAdminString, 746 frwkDeviceIdMaxMsg Unsigned32, 747 frwkDeviceIdMaxContexts Unsigned32 748 } 750 frwkDeviceIdPrid OBJECT-TYPE 751 SYNTAX InstanceId 752 STATUS current 753 DESCRIPTION 754 "An index to uniquely identify an instance of this 755 policy class." 757 ::= { frwkDeviceIdEntry 1 } 759 frwkDeviceIdDescr OBJECT-TYPE 760 SYNTAX SnmpAdminString (SIZE(0..255)) 761 STATUS current 762 DESCRIPTION 763 "A textual description of the PEP. This value should include 764 the name and version identification of the PEP's hardware 765 and software." 767 ::= { frwkDeviceIdEntry 2 } 769 frwkDeviceIdMaxMsg OBJECT-TYPE 770 SYNTAX Unsigned32 771 STATUS current 772 DESCRIPTION 773 "The maximum message size, in octets, that the device 774 is capable of processing. Received messages with a 775 size in excess of this value must cause the PEP to return an 776 error to the PDP containing the global error code 777 'maxMsgSizeExceeded'." 779 ::= { frwkDeviceIdEntry 3 } 781 frwkDeviceIdMaxContexts OBJECT-TYPE 782 SYNTAX Unsigned32 783 STATUS current 784 DESCRIPTION 785 "The maximum number of unique contexts supported by 786 the device." 788 ::= { frwkDeviceIdEntry 4 } 790 Framework Policy Information Base September 2000 792 -- 793 -- Component Limitations Table 794 -- 796 -- This table supports the ability to export information 797 -- detailing provisioning class/attribute implementation limitations 798 -- to the policy management system. 800 frwkCompLimitsTable OBJECT-TYPE 801 SYNTAX SEQUENCE OF FrwkCompLimitsEntry 802 PIB-ACCESS notify, 7 803 STATUS current 804 DESCRIPTION 805 "Each instance of this class identifies a policy class or 806 attribute and a limitation related to the implementation of 807 the class/attribute in the device. Additional information 808 providing guidance related to the limitation may also be 809 present. These PRIs are sent to the PDP to indicate which 810 PRCs or PRC attributes the device supports in a restricted 811 manner." 813 ::= { frwkBasePibClasses 4 } 815 frwkCompLimitsEntry OBJECT-TYPE 816 SYNTAX FrwkCompLimitsEntry 817 STATUS current 818 DESCRIPTION 819 "An instance of the frwkCompLimits class that identifies 820 a PRC or PRC attribute and a limitation related to the PRC 821 or PRC attribute implementation supported by the device. 822 All PRIs of this class represent errors that would be 823 returned in relation to the identified component for policy 824 installation requests that don't abide by the restrictions 825 indicated by the limitation type (error code) and, possibly, 826 a provided guidance value." 828 PIB-INDEX { frwkCompLimitsPrid } 829 UNIQUENESS { frwkCompLimitsComponent, 830 FrwkCompLimitsTypeGlobal, 831 frwkCompLimitsType, 832 frwkCompLimitsSubType, 833 frwkCompLimitsGuidance } 835 ::= { frwkCompLimitsTable 1 } 837 FrwkCompLimitsEntry ::= SEQUENCE { 838 frwkCompLimitsPrid InstanceId, 839 frwkCompLimitsComponent OBJECT IDENTIFIER, 840 frwkCompLimitsTypeGlobal TruthValue, 841 frwkCompLimitsType Integer32, 842 frwkCompLimitsSubType INTEGER, 843 frwkCompLimitsGuidance OCTET STRING 844 } 846 Framework Policy Information Base September 2000 848 frwkCompLimitsPrid OBJECT-TYPE 849 SYNTAX InstanceId 850 STATUS current 851 DESCRIPTION 852 "An arbitrary integer index that uniquely identifies an 853 instance of the frwkCompLimits class." 855 ::= { frwkCompLimitsEntry 1 } 857 frwkCompLimitsComponent OBJECT-TYPE 858 SYNTAX OBJECT IDENTIFIER 859 STATUS current 860 DESCRIPTION 861 "The object identifier of a PRC or PRC attribute that 862 is supported in some limited fashion with regard to it's 863 definition in the associated PIB module. The same PRC or 864 PRC attribute identifier may appear in the table several 865 times, once for each implementation limitation 866 acknowledged by the device. " 868 ::= { frwkCompLimitsEntry 2 } 870 frwkCompLimitsTypeGlobal OBJECT-TYPE 871 SYNTAX TruthValue 872 STATUS current 873 DESCRIPTION 874 "A boolean value that has value TRUE if the 875 frwkCompLimitsType value is a Global component limitation 876 code defined in [COPS-PR], else has value FALSE which 877 implies the frwkCompLimitsType is a PRC specific component 878 limitation code defined in the INSTALL-ERRORS clause of 879 that PRC [SPPI]." 881 ::= { frwkCompLimitsEntry 3 } 883 frwkCompLimitsType OBJECT-TYPE 884 SYNTAX Integer32 885 STATUS current 886 DESCRIPTION 887 "A value describing an implementation limitation for the 888 device related to the PRC or PRC attribute identified by 889 the frwkCompLimitsComponent data in this class instance. 890 Values for this object are derived from the defined 891 error values associated with the PRC of the identified 892 attribute or the PRC itself. All genericPrc and specificPrc 893 (defined in a PRC INSTALL-ERRORS clause) error codes 894 represent valid limitation type values. The enumeration 895 values for generic Class-Specific errors are listed in 896 [COPS-PR]. 898 Framework Policy Information Base September 2000 900 For example, an implementation of the frwkIpFilter class may 901 be limited in several ways, such as address mask, protocol 902 and Layer 4 port options. These limitations could be 903 exported using this table with the following instances: 905 Component Type 906 -------------------------------------------------- 907 'frwkIpFilterDstAddrMask' 'attrValueSupLimited' 908 'frwkIpFilterSrcAddrMask' 'attrValueSupLimited' 909 'frwkIpFilterProtocol' 'attrValueSupLimited' 910 'frwkIpFilterProtocol' 'attrValueSupLimited' 911 'frwkIpFilterDstL4PortMin' 'invalidDstL4PortData' 912 'frwkIpFilterDstL4PortMax' 'invalidDstL4PortData' 913 'frwkBaseFilterPermit' 'attrEnumSupLimited' 915 The above entries describe a number of limitations that 916 may be in effect for the frwkIpFilter class on a given 917 device. The limitations include restrictions on acceptable 918 values for certain attributes and indications of the 919 relationship between related attributes. 921 Also, an implementation of a PRC may be limited in the ways 922 it can be accessed. For instance: 923 Component Type 924 -------------------------------------------------- 925 'DscpMapEntry' 'priNotifyOnly' 927 If the errors defined in the INSTALL-ERRORS section are not 928 generic Class-Specific errors (in the example, 929 'invalidDstL4PortData') then the Error code sent must be 930 'priSpecificError'[COPS-PR] and the Sub-Error code must 931 contain the enumeration value from the INSTALL-ERRORS 932 section for the PRC (in the example, the enumeration value 933 for 'invalidDstL4PortData') [SPPI]." 935 ::= { frwkCompLimitsEntry 4 } 937 frwkCompLimitsSubType OBJECT-TYPE 938 SYNTAX INTEGER { 939 none(1), 940 lengthMin(2), 941 lengthMax(3), 942 rangeMin(4), 943 rangeMax(5), 944 enumMin(6), 945 enumMax(7), 946 enumOnly(8), 947 valueOnly(9), 948 extendsOid(10) 949 } 950 STATUS current 951 DESCRIPTION 953 Framework Policy Information Base September 2000 955 "This object indicates the type of guidance related 956 to the noted limitation (as indicated by the 957 frwkCompLimitsType attribute) that is provided 958 in the frwkCompLimitsGuidance attribute. 960 A value of 'none(1)' means that no additional 961 guidance is provided for the noted limitation type. 963 A value of 'lengthMin(2)' means that the guidance 964 attribute provides data related to the minimum 965 acceptable length for the value of the identified 966 component. A corresponding class instance 967 specifying the 'lengthMax(3)' value is required 968 in conjunction with this sub-type. 970 A value of 'lengthMax(3)' means that the guidance 971 attribute provides data related to the maximum 972 acceptable length for the value of the identified 973 component. A corresponding class instance 974 specifying the 'lengthMin(2)' value is required 975 in conjunction with this sub-type. 977 A value of 'rangeMin(4)' means that the guidance 978 attribute provides data related to the lower bound 979 of the range for the value of the identified 980 component. A corresponding class instance 981 specifying the 'rangeMax(5)' value is required 982 in conjunction with this sub-type. 984 A value of 'rangeMax(5)' means that the guidance 985 attribute provides data related to the upper bound 986 of the range for the value of the identified 987 component. A corresponding class instance 988 specifying the 'rangeMin(4)' value is required 989 in conjunction with this sub-type. 991 A value of 'enumMin(6)' means that the guidance 992 attribute provides data related to the lowest 993 enumeration acceptable for the value of the 994 identified component. A corresponding 995 class instance specifying the 'enumMax(7)' 996 value is required in conjunction with this sub-type. 998 A value of 'enumMin(7)' means that the guidance 999 attribute provides data related to the largest 1000 enumeration acceptable for the value of the 1001 identified component. A corresponding 1002 class instance specifying the 'enumMin(6)' 1003 value is required in conjunction with this sub-type. 1005 A value of 'enumOnly(8)' means that the guidance 1006 attribute provides data related to a single 1007 enumeration acceptable for the value of the 1009 Framework Policy Information Base September 2000 1011 identified component. 1013 A value of 'valueOnly(9)' means that the guidance 1014 attribute provides data related to a single 1015 value that is acceptable for the identified 1016 component. 1018 A value of 'extendsOid(10)' means that the guidance 1019 attribute provides data related to a PRC that 1020 AUGMENTS or EXTENDS the identified policy class." 1022 ::= { frwkCompLimitsEntry 5 } 1024 frwkCompLimitsGuidance OBJECT-TYPE 1025 SYNTAX OCTET STRING (SIZE(0..255)) 1026 STATUS current 1027 DESCRIPTION 1028 "A value used to convey additional information related 1029 to the implementation limitation noted by the 1030 frwkCompLimitsType and frwkCompLimitsSubType 1031 attribute. The value of this attribute must be 1032 interpreted in the context of the frwkCompLimitsType and 1033 frwkCompLimitsSubType values. Note that a guidance 1034 value will not necessarily be provided for all exported 1035 limitations. If a guidance value is not provided, the 1036 value must be a zero-length string. 1038 The format of the guidance value, if one is present as 1039 indicated by the frwkCompLimitsSubType attribute, 1040 is described by the following table. Note that the 1041 type of guidance value is dictated by the type of the 1042 component whose limitation is being exported. 1044 Base Type Length Value 1045 --------- ------ ----- 1046 INTEGER 32-bit value 1047 OCTET STRING 1 byte octets of data 1048 OID 1 byte 32-bit OID components." 1050 ::= { frwkCompLimitsEntry 6 } 1052 Framework Policy Information Base September 2000 1054 -- 1055 -- The device interface capabilities and role combo classes group 1056 -- 1058 frwkDeviceCapClasses 1059 OBJECT IDENTIFIER ::= { frameworkPib 2 } 1061 -- 1062 -- Interface Capability Set Table 1063 -- 1065 frwkIfCapSetTable OBJECT-TYPE 1066 SYNTAX SEQUENCE OF FrwkIfCapSetEntry 1067 PIB-ACCESS notify,4 1068 STATUS current 1069 DESCRIPTION 1070 "This class describes the interfaces that exist on the 1071 device. Associated with each interface is a set of 1072 capabilities. The capability set is given a unique name that 1073 identifies the interface type. These capabilities are used 1074 by the PDP to determine policy information to be associated 1075 with interfaces of this type." 1077 ::= { frwkDeviceCapClasses 1 } 1079 frwkIfCapSetEntry OBJECT-TYPE 1080 SYNTAX FrwkIfCapSetEntry 1081 STATUS current 1082 DESCRIPTION 1083 "An instance of this class describes the characteristics 1084 of a type of an interface." 1086 PIB-INDEX { frwkIfCapSetPrid } 1087 UNIQUENESS { frwkIfCapSetName, 1088 frwkIfCapSetCapability } 1090 ::= { frwkIfCapSetTable 1 } 1092 FrwkIfCapSetEntry ::= SEQUENCE { 1093 frwkIfCapSetPrid InstanceId, 1094 frwkIfCapSetName SnmpAdminString, 1095 frwkIfCapSetCapability Prid 1096 } 1098 frwkIfCapSetPrid OBJECT-TYPE 1099 SYNTAX InstanceId 1100 STATUS current 1101 DESCRIPTION 1102 "An arbitrary integer index that uniquely identifies a 1103 instance of the class." 1105 ::= { frwkIfCapSetEntry 1 } 1107 Framework Policy Information Base September 2000 1109 frwkIfCapSetName OBJECT-TYPE 1110 SYNTAX SnmpAdminString 1111 STATUS current 1112 DESCRIPTION 1113 "The name for the capability set. The capability set name 1114 is the unique identifier of an interface type." 1116 ::= { frwkIfCapSetEntry 2 } 1118 frwkIfCapSetCapability OBJECT-TYPE 1119 SYNTAX Prid 1120 STATUS current 1121 DESCRIPTION 1122 "The complete PRC OID and instance identifier specifying the 1123 capability PRC instance for the interface." 1125 ::= { frwkIfCapSetEntry 3 } 1127 -- 1128 -- Interface Capabilities Set Name and Role Combination Table 1129 -- 1131 frwkIfCapSetRoleComboTable OBJECT-TYPE 1132 SYNTAX SEQUENCE OF FrwkIfCapSetRoleComboEntry 1133 PIB-ACCESS notify,4 1134 STATUS current 1135 DESCRIPTION 1136 "Policy for an interface may depend not only on the 1137 capability set of an interface but also on its roles. This 1138 table specifies all the tuples currently on the device." 1141 ::= { frwkDeviceCapClasses 2 } 1143 frwkIfCapSetRoleComboEntry OBJECT-TYPE 1144 SYNTAX FrwkIfCapSetRoleComboEntry 1145 STATUS current 1146 DESCRIPTION 1147 "An instance of this class describes a combination of an 1148 interface capability set name and a role combination." 1150 PIB-INDEX { frwkIfCapSetRoleComboPrid } 1151 UNIQUENESS { frwkIfCapSetRoleComboName, 1152 frwkIfCapSetRoleComboRoles } 1154 ::= { frwkIfCapSetRoleComboTable 1 } 1156 Framework Policy Information Base September 2000 1158 FrwkIfCapSetRoleComboEntry ::= SEQUENCE { 1159 frwkIfCapSetRoleComboPrid InstanceId, 1160 frwkIfCapSetRoleComboName SnmpAdminString, 1161 frwkIfCapSetRoleComboRoles RoleCombination 1162 } 1164 frwkIfCapSetRoleComboPrid OBJECT-TYPE 1165 SYNTAX InstanceId 1166 STATUS current 1167 DESCRIPTION 1168 "An arbitrary integer index that uniquely identifies a 1169 instance of the class." 1171 ::= { frwkIfCapSetRoleComboEntry 1 } 1173 frwkIfCapSetRoleComboName OBJECT-TYPE 1174 SYNTAX SnmpAdminString 1175 STATUS current 1176 DESCRIPTION 1177 "The name of the interface capability set. This name must 1178 exist in frwkIfCapSetTable." 1180 ::= { frwkIfCapSetRoleComboEntry 2 } 1182 frwkIfCapSetRoleComboRoles OBJECT-TYPE 1183 SYNTAX RoleCombination 1184 STATUS current 1185 DESCRIPTION 1186 "A role combination. The PEP requires policy for interfaces 1187 with this role combination and of capability set name 1188 specified by frwkIfCapSetRoleComboName" 1190 ::= { frwkIfCapSetRoleComboEntry 3 } 1192 Framework Policy Information Base September 2000 1194 -- 1195 -- The Classification classes group 1196 -- 1198 frwkClassifierClasses 1199 OBJECT IDENTIFIER ::= { frameworkPib 3 } 1201 -- 1202 -- The Base Filter Table 1203 -- 1205 frwkBaseFilterTable OBJECT-TYPE 1206 SYNTAX SEQUENCE OF FrwkBaseFilterEntry 1207 PIB-ACCESS install,3 1208 STATUS current 1209 DESCRIPTION 1210 "The Base Filter class. A packet has to match all 1211 fields in an Filter. Wildcards may be specified for those 1212 fields that are not relevant." 1214 ::= { frwkClassifierClasses 1 } 1216 frwkBaseFilterEntry OBJECT-TYPE 1217 SYNTAX FrwkBaseFilterEntry 1218 STATUS current 1219 DESCRIPTION 1220 "An instance of the frwkBaseFilter class." 1222 PIB-INDEX { frwkBaseFilterPrid } 1224 ::= { frwkBaseFilterTable 1 } 1226 FrwkBaseFilterEntry ::= SEQUENCE { 1227 frwkBaseFilterPrid InstanceId, 1228 frwkBaseFilterPermit TruthValue 1229 } 1231 frwkBaseFilterPrid OBJECT-TYPE 1232 SYNTAX InstanceId 1233 STATUS current 1234 DESCRIPTION 1235 "An integer index to uniquely identify this Filter among all 1236 the Filters." 1238 ::= { frwkBaseFilterEntry 1 } 1240 Framework Policy Information Base September 2000 1242 frwkBaseFilterPermit OBJECT-TYPE 1243 SYNTAX TruthValue 1244 STATUS current 1245 DESCRIPTION 1246 "If the packet matches this filter and the value of this 1247 attribute is true, then the matching process terminates 1248 and the action associated with this filter (indirectly 1249 through the filter group) is applied to the packet. If the 1250 value of this attribute is false, then no more filters in 1251 the filter group are compared to this packet and matching 1252 continues with the first filter of the next filter group." 1254 ::= { frwkBaseFilterEntry 2 } 1256 -- 1257 -- The IP Filter Table 1258 -- 1260 frwkIpFilterTable OBJECT-TYPE 1261 SYNTAX SEQUENCE OF FrwkIpFilterEntry 1262 PIB-ACCESS install, 13 1263 STATUS current 1264 DESCRIPTION 1265 "Filter definitions. A packet has to match all fields in a 1266 filter. Wildcards may be specified for those fields that 1267 are not relevant." 1269 INSTALL-ERRORS { 1270 invalidDstL4PortData(1), 1271 invalidSrcL4PortData(2) 1272 } 1273 ::= { frwkClassifierClasses 2 } 1275 frwkIpFilterEntry OBJECT-TYPE 1276 SYNTAX FrwkIpFilterEntry 1277 STATUS current 1278 DESCRIPTION 1279 "An instance of the frwkIpFilter class." 1281 EXTENDS { frwkBaseFilterEntry } 1282 UNIQUENESS { frwkIpFilterDstAddr, 1283 frwkIpFilterDstAddrMask, 1284 frwkIpFilterSrcAddr, 1285 frwkIpFilterSrcAddrMask, 1286 frwkIpFilterDscp, 1287 frwkIpFilterProtocol, 1288 frwkIpFilterDstL4PortMin, 1289 frwkIpFilterDstL4PortMax, 1290 frwkIpFilterSrcL4PortMin, 1291 frwkIpFilterSrcL4PortMax } 1293 ::= { frwkIpFilterTable 1 } 1295 Framework Policy Information Base September 2000 1297 FrwkIpFilterEntry ::= SEQUENCE { 1298 frwkIpFilterDstAddrType InetAddressType, 1299 frwkIpFilterDstAddr InetAddress, 1300 frwkIpFilterDstAddrMask Unsigned32, 1301 frwkIpFilterSrcAddrType InetAddressType, 1302 frwkIpFilterSrcAddr InetAddress, 1303 frwkIpFilterSrcAddrMask Unsigned32, 1304 frwkIpFilterDscp Integer32, 1305 frwkIpFilterProtocol INTEGER, 1306 frwkIpFilterDstL4PortMin INTEGER, 1307 frwkIpFilterDstL4PortMax INTEGER, 1308 frwkIpFilterSrcL4PortMin INTEGER, 1309 frwkIpFilterSrcL4PortMax INTEGER 1310 } 1312 frwkIpFilterDstAddrType OBJECT-TYPE 1314 SYNTAX InetAddressType 1315 STATUS current 1316 DESCRIPTION 1317 "The address type enumeration value to specify the type of 1318 the packet's destination IP address." 1320 ::= { frwkIpFilterEntry 1 } 1322 frwkIpFilterDstAddr OBJECT-TYPE 1324 SYNTAX InetAddress 1325 STATUS current 1326 DESCRIPTION 1327 "The IP address to match against the packet's destination IP 1328 address." 1330 ::= { frwkIpFilterEntry 2 } 1332 frwkIpFilterDstAddrMask OBJECT-TYPE 1333 SYNTAX Unsigned32 1334 STATUS current 1335 DESCRIPTION 1336 "The length of a mask for the matching of the destination 1337 IP address. Masks are constructed by setting bits in 1338 sequence from the most-significant bit downwards for 1339 frwkIpFilterDstAddrMask bits length. All other bits in the 1340 mask, up to the number needed to fill the length of the 1341 address frwkIpFilterDstAddr are cleared to zero. A zero bit 1342 in the mask then means that the corresponding bit in the 1343 address always matches." 1345 ::= { frwkIpFilterEntry 3 } 1347 Framework Policy Information Base September 2000 1349 frwkIpFilterSrcAddrType OBJECT-TYPE 1351 SYNTAX InetAddressType 1352 STATUS current 1353 DESCRIPTION 1354 "The address type enumeration value to specify the type of 1355 the packet's source IP address." 1357 ::= { frwkIpFilterEntry 4 } 1359 frwkIpFilterSrcAddr OBJECT-TYPE 1360 SYNTAX InetAddress 1361 STATUS current 1362 DESCRIPTION 1363 "The IP address to match against the packet's source IP 1364 address." 1366 ::= { frwkIpFilterEntry 5 } 1368 frwkIpFilterSrcAddrMask OBJECT-TYPE 1369 SYNTAX Unsigned32 1370 STATUS current 1371 DESCRIPTION 1372 "The length of a mask for the matching of the source IP 1373 address. Masks are constructed by setting bits in sequence 1374 from the most-significant bit downwards for 1375 frwkIpFilterSrcAddrMask bits length. All other bits in the 1376 mask, up to the number needed to fill the length of the 1377 address frwkIpFilterSrcAddr are cleared to zero. A zero bit 1378 in the mask then means that the corresponding bit in the 1379 address always matches." 1381 ::= { frwkIpFilterEntry 6 } 1383 frwkIpFilterDscp OBJECT-TYPE 1384 SYNTAX Integer32 (-1 | 0..63) 1385 STATUS current 1386 DESCRIPTION 1387 "The value that the DSCP in the packet can have and 1388 match this filter. A value of -1 indicates that a specific 1389 DSCP value has not been defined and thus all DSCP values 1390 are considered a match." 1392 ::= { frwkIpFilterEntry 7 } 1394 Framework Policy Information Base September 2000 1396 frwkIpFilterProtocol OBJECT-TYPE 1397 SYNTAX INTEGER (0..255) 1398 STATUS current 1399 DESCRIPTION 1400 "The IP protocol to match against the packet's protocol. 1401 A value of zero means match all." 1403 ::= { frwkIpFilterEntry 8 } 1405 frwkIpFilterDstL4PortMin OBJECT-TYPE 1406 SYNTAX INTEGER (0..65535) 1407 STATUS current 1408 DESCRIPTION 1409 "The minimum value that the packet's layer 4 destination 1410 port number can have and match this filter." 1412 ::= { frwkIpFilterEntry 9 } 1414 frwkIpFilterDstL4PortMax OBJECT-TYPE 1415 SYNTAX INTEGER (0..65535) 1416 STATUS current 1417 DESCRIPTION 1418 "The maximum value that the packet's layer 4 destination 1419 port number can have and match this filter. This value must 1420 be equal to or greater that the value specified for this 1421 filter in frwkIpFilterDstL4PortMin." 1423 ::= { frwkIpFilterEntry 10 } 1425 frwkIpFilterSrcL4PortMin OBJECT-TYPE 1426 SYNTAX INTEGER (0..65535) 1427 STATUS current 1428 DESCRIPTION 1429 "The minimum value that the packet's layer 4 source port 1430 number can have and match this filter." 1432 ::= { frwkIpFilterEntry 11 } 1434 frwkIpFilterSrcL4PortMax OBJECT-TYPE 1435 SYNTAX INTEGER (0..65535) 1436 STATUS current 1437 DESCRIPTION 1438 "The maximum value that the packet's layer 4 source port 1439 number can have and match this filter. This value must be 1440 equal to or greater that the value specified for this filter 1441 in frwkIpFilterSrcL4PortMin." 1443 ::= { frwkIpFilterEntry 12 } 1445 Framework Policy Information Base September 2000 1447 -- 1448 -- The IEEE 802 Filter Table 1449 -- 1451 -- The IEEE 802 Filter Table supports the specification of IEEE 1452 -- 802-based (e.g., 802.3) information that is used to perform 1453 -- traffic classification. 1454 -- 1456 frwk802FilterTable OBJECT-TYPE 1457 SYNTAX SEQUENCE OF Frwk802FilterEntry 1458 PIB-ACCESS install,9 1459 STATUS current 1460 DESCRIPTION 1461 "IEEE 802-based filter definitions. A class that contains 1462 attributes of IEEE 802 (e.g., 802.3) traffic that form 1463 filters that are used to perform traffic classification." 1465 ::= { frwkClassifierClasses 3 } 1467 frwk802FilterEntry OBJECT-TYPE 1468 SYNTAX Frwk802FilterEntry 1469 STATUS current 1470 DESCRIPTION 1471 "IEEE 802-based filter definitions. An entry specifies 1472 (potentially) several distinct matching components. Each 1473 component is tested against the data in a frame 1474 individually. An overall match occurs when all of the 1475 individual components match the data they are compared 1476 against in the frame being processed. A failure of any 1477 one test causes the overall match to fail. 1479 Wildcards may be specified for those fields that are not 1480 relevant." 1482 EXTENDS { frwkBaseFilterEntry } 1483 UNIQUENESS { frwk802FilterDstAddr, 1484 frwk802FilterDstAddrMask, 1485 frwk802FilterSrcAddr, 1486 frwk802FilterSrcAddrMask, 1487 frwk802FilterVlanId, 1488 frwk802FilterVlanTagRequired, 1489 frwk802FilterEtherType, 1490 frwk802FilterUserPriority } 1492 ::= { frwk802FilterTable 1 } 1494 Framework Policy Information Base September 2000 1496 Frwk802FilterEntry ::= SEQUENCE { 1497 frwk802FilterDstAddr PhysAddress, 1498 frwk802FilterDstAddrMask PhysAddress, 1499 frwk802FilterSrcAddr PhysAddress, 1500 frwk802FilterSrcAddrMask PhysAddress, 1501 frwk802FilterVlanId Integer32, 1502 frwk802FilterVlanTagRequired INTEGER, 1503 frwk802FilterEtherType Integer32, 1504 frwk802FilterUserPriority BITS 1505 } 1507 frwk802FilterDstAddr OBJECT-TYPE 1508 SYNTAX PhysAddress 1509 STATUS current 1511 DESCRIPTION 1512 "The 802 address against which the 802 DA of incoming 1513 traffic streams will be compared. Frames whose 802 DA 1514 matches the physical address specified by this object, 1515 taking into account address wildcarding as specified by the 1516 frwk802FilterDstAddrMask object, are potentially subject to 1517 the processing guidelines that are associated with this 1518 entry through the related action class." 1520 ::= { frwk802FilterEntry 1 } 1522 frwk802FilterDstAddrMask OBJECT-TYPE 1523 SYNTAX PhysAddress 1524 STATUS current 1525 DESCRIPTION 1526 "This object specifies the bits in a 802 destination address 1527 that should be considered when performing a 802 DA 1528 comparison against the address specified in the 1529 frwk802FilterDstAddr object. 1531 The value of this object represents a mask that is logically 1532 and'ed with the 802 DA in received frames to derive the 1533 value to be compared against the frwk802FilterDstAddr 1534 address. A zero bit in the mask thus means that the 1535 corresponding bit in the address always matches. The 1536 frwk802FilterDstAddr value must also be masked using this 1537 value prior to any comparisons. 1539 The length of this object in octets must equal the length in 1540 octets of the frwk802FilterDstAddr. Note that a mask with no 1541 bits set (i.e., all zeroes) effectively wildcards the 1542 frwk802FilterDstAddr object." 1544 ::= { frwk802FilterEntry 2 } 1546 Framework Policy Information Base September 2000 1548 frwk802FilterSrcAddr OBJECT-TYPE 1549 SYNTAX PhysAddress 1550 STATUS current 1551 DESCRIPTION 1552 "The 802 MAC address against which the 802 MAC SA of 1553 incoming traffic streams will be compared. Frames whose 802 1554 MAC SA matches the physical address specified by this 1555 object, taking into account address wildcarding as specified 1556 by the frwk802FilterSrcAddrMask object, are potentially 1557 subject to the processing guidelines that are associated 1558 with this entry through the related action class." 1560 ::= { frwk802FilterEntry 3 } 1562 frwk802FilterSrcAddrMask OBJECT-TYPE 1563 SYNTAX PhysAddress 1564 STATUS current 1565 DESCRIPTION 1566 "This object specifies the bits in a 802 MAC source address 1567 that should be considered when performing a 802 MAC SA 1568 comparison against the address specified in the 1569 frwk802FilterSrcAddr object. 1571 The value of this object represents a mask that is logically 1572 and'ed with the 802 MAC SA in received frames to derive the 1573 value to be compared against the frwk802FilterSrcAddr 1574 address. A zero bit in the mask thus means that the 1575 corresponding bit in the address always matches. The 1576 frwk802FilterSrcAddr value must also be masked using this 1577 value prior to any comparisons. 1579 The length of this object in octets must equal the length in 1580 octets of the frwk802FilterSrcAddr. Note that a mask with no 1581 bits set (i.e., all zeroes) effectively wildcards the 1582 frwk802FilterSrcAddr object." 1584 ::= { frwk802FilterEntry 4 } 1586 frwk802FilterVlanId OBJECT-TYPE 1587 SYNTAX Integer32 (-1 | 1..4094) 1588 STATUS current 1589 DESCRIPTION 1590 "The VLAN ID (VID) that uniquely identifies a VLAN 1591 within the device. This VLAN may be known or unknown 1592 (i.e., traffic associated with this VID has not yet 1593 been seen by the device) at the time this entry 1594 is instantiated. 1596 Setting the frwk802FilterVlanId object to -1 indicates that 1597 VLAN data should not be considered during traffic 1598 classification." 1600 ::= { frwk802FilterEntry 5 } 1602 Framework Policy Information Base September 2000 1604 frwk802FilterVlanTagRequired OBJECT-TYPE 1605 SYNTAX INTEGER { 1606 taggedOnly(1), 1607 priorityTaggedPlus(2), 1608 untaggedOnly(3), 1609 ignoreTag(4) 1610 } 1611 STATUS current 1612 DESCRIPTION 1613 "This object indicates whether the presence of an 1614 IEEE 802.1Q VLAN tag in data link layer frames must 1615 be considered when determining if a given frame 1616 matches this 802 filter entry. 1618 A value of 'taggedOnly(1)' means that only frames 1619 containing a VLAN tag with a non-Null VID (i.e., a 1620 VID in the range 1..4094) will be considered a match. 1622 A value of 'priorityTaggedPlus(2)' means that only 1623 frames containing a VLAN tag, regardless of the value 1624 of the VID, will be considered a match. 1626 A value of 'untaggedOnly(3)' indicates that only 1627 untagged frames will match this filter component. 1629 The presence of a VLAN tag is not taken into 1630 consideration in terms of a match if the value is 1631 'ignoreTag(4)'." 1633 ::= { frwk802FilterEntry 6 } 1635 frwk802FilterEtherType OBJECT-TYPE 1636 SYNTAX Integer32 (-1 | 0..'ffff'h) 1637 STATUS current 1638 DESCRIPTION 1639 "This object specifies the value that will be compared 1640 against the value contained in the EtherType field of an 1641 IEEE 802 frame. Example settings would include 'IP' 1642 (0x0800), 'ARP' (0x0806) and 'IPX' (0x8137). 1644 Setting the frwk802FilterEtherTypeMin object to -1 indicates 1645 that EtherType data should not be considered during traffic 1646 classification. 1648 Note that the position of the EtherType field depends on 1649 the underlying frame format. For Ethernet-II encapsulation, 1650 the EtherType field follows the 802 MAC source address. For 1651 802.2 LLC/SNAP encapsulation, the EtherType value follows 1652 the Organization Code field in the 802.2 SNAP header. The 1653 value that is tested with regard to this filter component 1654 therefore depends on the data link layer frame format being 1656 Framework Policy Information Base September 2000 1658 used. If this 802 filter component is active when there is 1659 no EtherType field in a frame (e.g., 802.2 LLC), a match is 1660 implied." 1662 ::= { frwk802FilterEntry 7 } 1664 frwk802FilterUserPriority OBJECT-TYPE 1665 SYNTAX BITS { 1666 matchPriority0(0), 1667 matchPriority1(1), 1668 matchPriority2(2), 1669 matchPriority3(3), 1670 matchPriority4(4), 1671 matchPriority5(5), 1672 matchPriority6(6), 1673 matchPriority7(7) 1674 } 1675 STATUS current 1676 DESCRIPTION 1677 "The set of values, representing the potential range 1678 of user priority values, against which the value contained 1679 in the user priority field of a tagged 802.1 frame is 1680 compared. A test for equality is performed when determining 1681 if a match exists between the data in a data link layer 1682 frame and the value of this 802 filter component. Multiple 1683 values may be set at one time such that potentially several 1684 different user priority values may match this 802 filter 1685 component. 1687 Setting all of the bits that are associated with this 1688 object causes all user priority values to match this 1689 attribute. This essentially makes any comparisons 1690 with regard to user priority values unnecessary. Untagged 1691 frames are treated as an implicit match." 1693 ::= { frwk802FilterEntry 8 } 1695 -- 1696 -- The Filter Group Definition Table 1697 -- 1699 frwkFilterGroupDefnTable OBJECT-TYPE 1700 SYNTAX SEQUENCE OF FrwkFilterGroupDefnEntry 1701 PIB-ACCESS install,5 1702 STATUS current 1703 DESCRIPTION 1704 "A class that defines Filter Groups. Each Group being an 1705 ordered list of filters. Each instance of this class 1706 identifies one filter of a group and the precedence order of 1707 that filter with respect to other filters in the same 1708 group." 1710 Framework Policy Information Base September 2000 1712 INSTALL-ERRORS { 1713 priPrecedenceConflict(1) -- precedence conflict detected 1714 } 1716 ::= { frwkClassifierClasses 4 } 1718 frwkFilterGroupDefnEntry OBJECT-TYPE 1719 SYNTAX FrwkFilterGroupDefnEntry 1720 STATUS current 1721 DESCRIPTION 1722 "An instance of the frwkFilterGroupDefn class." 1724 PIB-INDEX { frwkFilterGroupDefnPrid } 1725 UNIQUENESS { frwkFilterGroupDefnId, 1726 frwkFilterGroupDefnFilterId, 1727 frwkFilterGroupDefnFilterPrecedence } 1729 ::= { frwkFilterGroupDefnTable 1 } 1731 FrwkFilterGroupDefnEntry ::= SEQUENCE { 1732 frwkFilterGroupDefnPrid InstanceId, 1733 frwkFilterGroupDefnId TagId, 1734 frwkFilterGroupDefnFilterId ReferenceId, 1735 frwkFilterGroupDefnFilterPrecedence Unsigned32 1736 } 1738 frwkFilterGroupDefnPrid OBJECT-TYPE 1739 SYNTAX InstanceId 1740 STATUS current 1741 DESCRIPTION 1742 "Unique index of this provisioning instance." 1744 ::= { frwkFilterGroupDefnEntry 1 } 1746 frwkFilterGroupDefnId OBJECT-TYPE 1747 SYNTAX TagId 1748 STATUS current 1749 DESCRIPTION 1750 "An ID for this Filter Group. There will be one instance of 1751 the class frwkFilterGroupDefn with this ID for each 1752 instance of the Base filter class in the Filter Group per 1753 role combination. 1755 Note that this identifier is used in instances of the 1756 Class that associate a Filter Group with an interface 1757 set and specific actions. An active Filter Group-Target 1758 association prohibits the deletion of all of the 1759 frwkFilterGroupDefn instances with a given 1761 Framework Policy Information Base September 2000 1763 frwkFilterGroupDefnId (i.e., at least one entry for the 1764 specific frwkFilterGroupDefnId must be present in this 1765 table) until the Filter Group-Target association is 1766 terminated." 1768 ::= { frwkFilterGroupDefnEntry 2 } 1770 frwkFilterGroupDefnFilterId OBJECT-TYPE 1771 SYNTAX ReferenceId 1772 PIB-REFERENCES { frwkBaseFilterEntry } 1773 STATUS current 1774 DESCRIPTION 1775 "This attribute specifies the filter in the 1776 frwkBaseFilterTable that is in the Filter Group specified by 1777 frwkFilterGroupDefnId at the position specified by the 1778 FilterPrecedence attribute. 1780 Attempting to specify an unknown class instance will result 1781 in an appropriate error indication being returned to the 1782 entity that is attempting to install the conflicting entry. 1783 For example, a 'priUnknown(2)' error indication is returned 1784 to the policy server in this situation." 1786 ::= { frwkFilterGroupDefnEntry 3 } 1788 frwkFilterGroupDefnFilterPrecedence OBJECT-TYPE 1789 SYNTAX Unsigned32 1790 STATUS current 1791 DESCRIPTION 1792 "The precedence order of this filter. The precedence order 1793 determines the position of this filter in the Filter Group. 1794 A filter with a given precedence order is positioned in the 1795 Filter group before one with a higher-valued 1796 precedence order. 1798 Precedence values within a group must be unique otherwise 1799 instance installation will be prohibited and an error 1800 value will be returned." 1802 ::= { frwkFilterGroupDefnEntry 4 } 1804 Framework Policy Information Base September 2000 1806 -- 1807 -- Conformance Section 1808 -- 1810 frwkBasePibConformance 1811 OBJECT IDENTIFIER ::= { frameworkPib 4 } 1813 frwkBasePibCompliances 1814 OBJECT IDENTIFIER ::= { frwkBasePibConformance 1 } 1816 frwkBasePibGroups 1817 OBJECT IDENTIFIER ::= { frwkBasePibConformance 2 } 1819 frwkBasePibCompliance MODULE-COMPLIANCE 1820 STATUS current 1821 DESCRIPTION 1822 "Describes the requirements for conformance to the 1823 Framework PIB." 1825 MODULE -- this module 1826 MANDATORY-GROUPS { frwkPrcSupportGroup, 1827 frwkPibIncarnationGroup, 1828 frwkDeviceIdGroup, 1829 frwkCompLimitsGroup, 1830 frwkIfCapSetGroup, 1831 frwkIfCapSetRoleComboGroup } 1833 OBJECT frwkPibIncarnationLongevity 1834 PIB-MIN-ACCESS notify 1835 DESCRIPTION "Install support is not required." 1837 OBJECT frwkPibIncarnationTtl 1838 PIB-MIN-ACCESS notify 1839 DESCRIPTION "Install support is not required." 1841 OBJECT frwkPibIncarnationActive 1842 PIB-MIN-ACCESS notify 1843 DESCRIPTION "Install support is not required." 1845 GROUP frwkBaseFilterGroup 1846 DESCRIPTION 1847 "The frwkBaseFilterGroup is mandatory if filtering 1848 based on traffic components is supported." 1850 GROUP frwkIpFilterGroup 1851 DESCRIPTION 1852 "The frwkIpFilterGroup is mandatory if filtering 1853 based on IP traffic components is supported." 1855 Framework Policy Information Base September 2000 1857 GROUP frwk802FilterGroup 1858 DESCRIPTION 1859 "The frwk802FilterGroup is mandatory if filtering 1860 based on 802 traffic criteria is supported." 1862 GROUP frwkFilterGroupDefnGroup 1863 DESCRIPTION 1864 "The frwkFilterGroupDefnGroup is mandatory if 1865 filtering based on IP or 802 traffic components is 1866 supported." 1868 ::= { frwkBasePibCompliances 1 } 1870 frwkPrcSupportGroup OBJECT-GROUP 1871 OBJECTS { 1872 frwkPrcSupportSupportedPrc, 1873 frwkPrcSupportSupportedAttrs, 1874 frwkPrcSupportMaxPris 1875 } 1876 STATUS current 1877 DESCRIPTION 1878 "Objects from the frwkPrcSupportTable." 1880 ::= { frwkBasePibGroups 1 } 1882 frwkPibIncarnationGroup OBJECT-GROUP 1883 OBJECTS { 1884 frwkPibIncarnationName, 1885 frwkPibIncarnationId, 1886 frwkPibIncarnationLongevity, 1887 frwkPibIncarnationTtl, 1888 frwkPibIncarnationActive 1889 } 1890 STATUS current 1891 DESCRIPTION 1892 "Objects from the frwkDevicePibIncarnationTable." 1894 ::= { frwkBasePibGroups 2 } 1896 frwkDeviceIdGroup OBJECT-GROUP 1897 OBJECTS { 1898 frwkDeviceIdDescr, 1899 frwkDeviceIdMaxMsg, 1900 frwkDeviceIdMaxContexts } 1901 STATUS current 1902 DESCRIPTION 1903 "Objects from the frwkDeviceIdTable." 1905 ::= { frwkBasePibGroups 3 } 1907 Framework Policy Information Base September 2000 1909 frwkCompLimitsGroup OBJECT-GROUP 1910 OBJECTS { 1911 frwkCompLimitsComponent, 1912 frwkCompLimitsTypeGlobal, 1913 frwkCompLimitsType, 1914 frwkCompLimitsGuidance, 1915 frwkCompLimitsSubType } 1916 STATUS current 1917 DESCRIPTION 1918 "Objects from the frwkCompLimitsTable." 1920 ::= { frwkBasePibGroups 4 } 1922 frwkIfCapSetGroup OBJECT-GROUP 1923 OBJECTS { 1924 frwkIfCapSetName, 1925 frwkIfCapSetCapability 1926 } 1927 STATUS current 1928 DESCRIPTION 1929 "Objects from the frwkIfCapSetTable." 1931 ::= { frwkBasePibGroups 5 } 1933 frwkIfCapSetRoleComboGroup OBJECT-GROUP 1934 OBJECTS { 1935 frwkIfCapSetRoleComboName, 1936 frwkIfCapSetRoleComboRoles 1937 } 1938 STATUS current 1939 DESCRIPTION 1940 "Objects from the frwkIfCapSetRoleComboTable." 1942 ::= { frwkBasePibGroups 6 } 1944 frwkBaseFilterGroup OBJECT-GROUP 1945 OBJECTS { 1946 frwkBaseFilterPermit 1947 } 1948 STATUS current 1949 DESCRIPTION 1950 "Objects from the frwkBaseFilterTable." 1952 ::= { frwkBasePibGroups 7 } 1954 Framework Policy Information Base September 2000 1956 frwkIpFilterGroup OBJECT-GROUP 1957 OBJECTS { 1958 frwkIpFilterDstAddrType, 1959 frwkIpFilterDstAddr, 1960 frwkIpFilterDstAddrMask, 1961 frwkIpFilterSrcAddrType, 1962 frwkIpFilterSrcAddr, 1963 frwkIpFilterSrcAddrMask, 1964 frwkIpFilterDscp, 1965 frwkIpFilterProtocol, 1966 frwkIpFilterDstL4PortMin, 1967 frwkIpFilterDstL4PortMax, 1968 frwkIpFilterSrcL4PortMin, 1969 frwkIpFilterSrcL4PortMax 1970 } 1971 STATUS current 1972 DESCRIPTION 1973 "Objects from the frwkIpFilterTable." 1975 ::= { frwkBasePibGroups 8 } 1977 frwk802FilterGroup OBJECT-GROUP 1978 OBJECTS { 1979 frwk802FilterDstAddr, 1980 frwk802FilterDstAddrMask, 1981 frwk802FilterSrcAddr, 1982 frwk802FilterSrcAddrMask, 1983 frwk802FilterVlanId, 1984 frwk802FilterVlanTagRequired, 1985 frwk802FilterEtherType, 1986 frwk802FilterUserPriority 1987 } 1988 STATUS current 1989 DESCRIPTION 1990 "Objects from the frwk802FilterTable." 1992 ::= { frwkBasePibGroups 9 } 1994 frwkFilterGroupDefnGroup OBJECT-GROUP 1995 OBJECTS { 1996 frwkFilterGroupDefnId, 1997 frwkFilterGroupDefnFilterId, 1998 frwkFilterGroupDefnFilterPrecedence 1999 } 2000 STATUS current 2001 DESCRIPTION 2002 "Objects from the frwkFilterGroupDefnTable." 2004 ::= { frwkBasePibGroups 10 } 2006 END 2008 Framework Policy Information Base September 2000 2010 6. Security Considerations 2012 It is clear that this PIB is used for configuration using [COPS-PR], 2013 and anything that can be configured can be misconfigured, with 2014 potentially disastrous effect. At this writing, no security holes 2015 have been identified beyond those that the COPS base protocol 2016 security is itself intended to address. These relate primarily to 2017 controlled access to sensitive information and the ability to 2018 configure a device - or which might result from operator error, 2019 which is beyond the scope of any security architecture. 2021 There are a number of provisioning classes defined in this PIB that 2022 have a PIB-ACCESS clause of install (read-create). Such objects may 2023 be considered sensitive or vulnerable in some network environments. 2024 The support for "Install" decisions sent over [COPS-PR] in a non- 2025 secure environment without proper protection can have a negative 2026 effect on network operations. There are a number of provisioning 2027 classes in this PIB that may contain information that may be 2028 sensitive from a business perspective, in that they may represent a 2029 customer's service contract or the filters that the service provider 2030 chooses to apply to a customer's ingress or egress traffic. There 2031 are no PRCs that are sensitive in their own right, such as passwords 2032 or monetary amounts. It may be important to control even 2033 "Notify"(read-only) access to these PRCs and possibly to even 2034 encrypt the values of these PRIs when sending them over the network 2035 via COPS-PR. Even if the network itself is secure (for example by 2036 using IPSec), there is no control as to who on the secure network is 2037 allowed to "Install/Notify" (read/change/create/delete) the PRIs in 2038 this PIB. It is recommended that the implementers consider the 2039 security features as provided by the COPS base protocol. 2041 It is then a customer/user responsibility to ensure that the PEP/PDP 2042 giving access to an instance of this PIB, is properly configured to 2043 give access to the PRIs only to those principals (users) that have 2044 legitimate rights to indeed "Install" or "Notify" (change/create/ 2045 delete) them. The use of IPSEC between the PDP and the PEP, as 2046 described in [COPS], provides the necessary protection against 2047 security threats. 2049 7. Author Information and Acknowledgments 2051 Michael Fine 2052 Cisco Systems, Inc. 2053 170 West Tasman Drive 2054 San Jose, CA 95134-1706 USA 2055 Phone: +1 408 527 8218 2056 Email: mfine@cisco.com 2058 Framework Policy Information Base September 2000 2060 Keith McCloghrie 2061 Cisco Systems, Inc. 2062 170 West Tasman Drive 2063 San Jose, CA 95134-1706 USA 2064 Phone: +1 408 526 5260 2065 Email: kzm@cisco.com 2067 John Seligson 2068 Nortel Networks, Inc. 2069 4401 Great America Parkway 2070 Santa Clara, CA 95054 USA 2071 Phone: +1 408 495 2992 2072 Email: jseligso@nortelnetworks.com 2074 Kwok Ho Chan 2075 Nortel Networks, Inc. 2076 600 Technology Park Drive 2077 Billerica, MA 01821 USA 2078 Phone: +1 978 288 8175 2079 Email: khchan@nortelnetworks.com 2081 Scott Hahn 2082 Intel Corp. 2083 2111 NE 25th Avenue 2084 Hillsboro, OR 97124 USA 2085 Phone: +1 503 264 8231 2086 Email: scott.hahn@intel.com 2088 Ravi Sahita 2089 Intel Corp. 2090 2111 NE 25th Avenue 2091 Hillsboro, OR 97124 USA 2092 Phone: +1 503 712 1554 2093 Email: ravi.sahita@intel.com 2095 Andrew Smith 2096 Fax: +1 415 345 1827 2097 Email: ah_smith@pacbell.net 2099 Francis Reichmeyer 2100 PFN, Inc. 2101 University Park at MIT 2102 26 Landsdowne Street 2103 Cambridge, MA 02139 2104 Phone: +1 617 494 9980 2105 Email: franr@pfn.com 2107 Special thanks to Carol Bell and David Durham for their many 2108 significant comments. 2110 Framework Policy Information Base September 2000 2112 8. References 2114 [COPS] 2115 Boyle, J., Cohen, R., Durham, D., Herzog, S., Rajan, R., and 2116 A. Sastry, "The COPS (Common Open Policy Service) Protocol" 2117 RFC 2748, January 2000. 2119 [COPS-PR] 2120 K. Chan, D. Durham, S. Gai, S. Herzog, K. McCloghrie, 2121 F. Reichmeyer, J. Seligson, A. Smith, R. Yavatkar, "COPS Usage 2122 for Policy Provisioning," draft-ietf-rap-pr-04.txt, 2123 August 2000. 2125 [SPPI] 2126 K. McCloghrie, et.al., "Structure of Policy Provisioning 2127 Information," draft-ietf-rap-sppi-02.txt, September 2000. 2129 [RAP-FRAMEWORK] 2130 R. Yavatkar, D. Pendarakis, "A Framework for Policy-based 2131 Admission Control", RFC 2753, January 2000. 2133 [SNMP-SMI] 2134 K. McCloghrie, D. Perkins, J. Schoenwaelder, J. Case, M. Rose 2135 and S. Waldbusser, "Structure of Management Information 2136 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 2138 9. Full Copyright 2140 Copyright (C) The Internet Society (2000). All Rights Reserved. This 2141 document and translations of it may be copied and furnished to 2142 others, and derivative works that comment on or otherwise explain it 2143 or assist in its implementation may be prepared, copied, published 2144 and distributed, in whole or in part, without restriction of any 2145 kind, provided that the above copyright notice and this paragraph 2146 are included on all such copies and derivative works. However, this 2147 document itself may not be modified in any way, such as by removing 2148 the copyright notice or references to the Internet Society or other 2149 Internet organizations, except as needed for the purpose of 2150 developing Internet standards in which case the procedures for 2151 copyrights defined in the Internet Standards process must be 2152 followed, or as required to translate it into languages other than 2153 English. 2155 The limited permissions granted above are perpetual and will not be 2156 revoked by the Internet Society or its successors or assigns. 2158 This document and the information contained herein is provided on an 2159 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2160 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2161 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2162 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2163 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2165 Framework Policy Information Base September 2000 2167 Table of Contents 2169 Status of this Memo...............................................1 2170 1. Glossary.......................................................2 2171 2. Introduction...................................................2 2172 3. General PIB Concepts...........................................2 2173 3.1. Roles........................................................2 2174 3.1.1. An Example.................................................4 2175 3.2. Multiple PIB Instances.......................................5 2176 3.3. Reporting of Device Capabilities.............................6 2177 3.4. Reporting of Device Limitations..............................6 2178 4. Summary of the Framework PIB...................................6 2179 5. The Framework PIB Module.......................................9 2180 7. Author Information and Acknowledgments........................41 2181 8. References....................................................43 2182 9. Full Copyright................................................43