idnits 2.17.1 draft-ietf-rap-frameworkpib-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: ---------------------------------------------------------------------------- ** 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 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 244: '... instance MUST ensure that the attri...' RFC 2119 keyword, line 658: '... active instance MUST become inactive ...' RFC 2119 keyword, line 660: '... MUST be set to false."...' 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 (July 14, 2000) is 8687 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 1956, but no explicit reference was found in the text == Outdated reference: A later version (-05) exists of draft-ietf-rap-pr-03 ** 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-01 ** Downref: Normative reference to an Historic draft: draft-ietf-rap-sppi (ref. 'SPPI') -- Possible downref: Normative reference to a draft: ref. 'POLICY' ** Downref: Normative reference to an Informational RFC: RFC 2753 (ref. 'RAP-FRAMEWORK') Summary: 14 errors (**), 0 flaws (~~), 4 warnings (==), 3 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 January 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 IPHighway 16 July 14, 2000 18 Framework Policy Information Base 20 draft-ietf-rap-frameworkpib-01.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 1. Glossary 42 PRC Policy Rule Class. A type of policy data. 43 PRI Policy Rule Instance. An instance of a PRC. 44 PIB Policy Information Base. The database of policy information. 45 PDP Policy Decision Point. See [RAP-FRAMEWORK]. 46 PEP Policy Enforcement Point. See [RAP-FRAMEWORK]. 47 PRID Policy Rule Instance Identifier. Uniquely identifies an 48 instance of a PRC. 50 2. Introduction 52 [SPPI] describes a structure for specifying policy information that 53 can then be transmitted to a network device for the purpose of 54 configuring policy at that device. The model underlying this 55 structure is one of well-defined policy rule classes and instances 56 of these classes residing in a virtual information store called the 57 Policy Information Base (PIB). 59 One way to provision policy is by means of the COPS protocol [COPS] 60 with the extensions for provisioning [COPS-PR]. This protocol 61 supports multiple clients, each of which may provision policy for a 62 specific policy domain such as QoS, virtual private networks, or 63 security. 65 As described in [COPS-PR], each client supports a non-overlapping 66 and independent set of PIB modules. However, some policy rule 67 classes are common to all subject categories (client-types) and need 68 to be present in each. This document presents a set of PRCs that 69 are common to all clients that provision policy using COPS for 70 Provisioning. 72 3. General PIB Concepts 74 3.1. Roles 76 The policy to apply to an interface may depend on many factors such 77 as immutable characteristics of the interface (e.g., ethernet or 78 frame relay), the status of the interface (e.g., half or full 79 duplex), or user configuration (e.g., branch office or headquarters 80 interface). Rather than specifying policies explicitly for each 81 interface of all devices in the network, policies are specified in 82 terms of interface functionality. 84 To describe these functionalities of an interface we use the concept 85 of "roles". A role is simply a string that is associated with an 86 interface. A given interface may have any number of roles 87 simultaneously. Policy rule classes have an attribute called a 88 "role-combination" which is a lexicographically ordered set of 89 roles. Instances of a given policy rule class are applied to an 90 interface if and only if the set of roles in the role combination 91 matches the set of the roles of the interface. 93 Thus, roles provide a way to bind policy to interfaces without 94 having to explicitly identify interfaces in a consistent manner 95 across all network devices. (The SNMP experience with ifIndex has 96 proved this to be a difficult task.) That is, roles provide a level 97 of indirection to the application of a set of policies to specific 98 interfaces. Furthermore, if the same policy is being applied to 99 several interfaces, that policy need be pushed to the device only 100 once, rather than once per interface, as long as the interfaces are 101 configured with the same role combination. 103 We point out that, in the event that the administrator needs to have 104 unique policy for each interface, this can be achieved by 105 configuring each interface with a unique role. 107 The PEP reports all its role combinations to the PDP in the initial 108 COPS request (REQ) message and in subsequent request messages 109 generated in response to COPS state synchronization (SSQ) requests 110 and local configuration changes. 112 The comparing of roles (or role combinations) is case sensitive. 114 By convention, when formatting the role-combination for exchange 115 within a protocol message, within a PIB/MIB object's value, or as a 116 printed value, the set is formatted in lexicographical order of the 117 role's ASCII values; that is, the role that is first is formatted 118 first. For example, "a+b" and "b+a" are NOT different role- 119 combinations; rather, they are different formatting of the same 120 role-combination, and hence for this example: 121 - "a+b" is the valid formatting of that role-combination, 122 - "b+a" is an invalid formatting of that role-combination. 124 The role-combination of interfaces to which no roles have been 125 assigned is known as the "null" role-combination. (Note the 126 deliberate use of lower-case letters for "null" so that it avoids 127 confusion with the ASCII NULL character that has a value of zero but 128 a length of one.) 130 In an "install" or an "install-notify" class, the wildcard role- 131 combination "*" can be used. In addition to providing for interface- 132 specific roles, it also allows for other optimizations in reducing 133 the number of role-combinations for which a policy has to be 134 specified. For example: 136 Suppose we have three interfaces: 138 Roles A, B and R1 are assigned to interface I1 139 Roles A, B and R2 are assigned to interface I2 140 Roles A, B and R3 are assigned to interface I3 142 Then, a PRI of the qosIfDscpAssignTable class which has the values: 144 qosIfDscpAssignPrid = 1 145 qosIfDscpAssignRoles = "*+A+B" 146 qosIfDscpAssignName = "4queues" 147 qosIfDscpAssignDscpMap = 1 149 will apply to all three interfaces, because "*" matches with R1, R2 150 and R3. 152 Formally, 153 - The wildcard role is denoted by "*", 154 - The "*" role is not allowed to be defined as part of the role- 155 combination of an interface as notified by the PEP to the PDP; it 156 is only allowed in policies installed/deleted via COPS-PR from 157 the PDP to the PEP. 158 - For a policy to apply to an interface when the policy's role- 159 combination is "*+a+b", then the interface's role-combination: 160 - Must include "a" and "b", and 161 - Can include zero or more other roles. 162 - The wildcard character "*" is listed before the other roles as 163 "*" is lexicographically before "a"; however, the wildcard matches 164 any zero or more roles, irrespective of lexicographical order. 165 For example: "*+b+e+g" would match "a+b+c+e+f+g" 167 The concept and usage of roles in this document is consistent with 168 that specified in [POLICY]. Roles are currently under discussion in 169 the IETF's Policy WG; as and when that discussion reaches a 170 conclusion, this PIB will be updated in accordance with that 171 conclusion. 173 3.1.1. An Example 175 The functioning of roles might be best understood by an example. 176 Suppose I have a device with three interfaces, with roles as 177 follows: 179 IF1: "finance" 180 IF2: "finance" 181 IF3: "manager" 183 Suppose, I also have a PDP with two policies: 185 P1: Packets from finance department (role "finance") get DSCP 5 186 P2: Packets from managers (role "manager") get DSCP 6 188 To obtain policy, the PEP reports to the PDP that it has some 189 interfaces with role combination "finance" and some with role 190 combination "manager". In response, the PDP downloads policy P1 191 associated with role combination "finance" and downloads a second 192 policy P2 associated with role combination "manager". 194 Now suppose the finance person attached to IF2 is promoted to 195 manager and so the system administrator adds the role "manager" to 196 IF2. The PEP now reports to the PDP that it has three role 197 combinations: some interfaces with role combination "finance", some 198 with role combination "manager" and some with role combination 199 "finance+manager". In response, the PDP downloads an additional 200 third policy associated with the new role combination 201 "finance+manager". 203 How the PDP determines the policy for this new role combination is 204 entirely the responsibility of the PDP. It could do so 205 algorithmically or by rule. For example, there might be a rule that 206 specifies that manager policy takes preference over department 207 policy. Or there might be a third policy installed in the PDP as 208 follows: 210 P3: Packets from finance managers (role "finance" and role 211 "manager") get DSCP 7 213 The point here is that the PDP is required to determine what policy 214 applies to this new role combination and to download a third policy 215 to the PEP for the role combination "finance+manager" even if that 216 policy is the same as one already downloaded. The PEP is not 217 required (or allowed) to construct policy for new role combinations 218 from existing policy. 220 3.2. Multiple PIB Instances 222 [COPS-PR] supports multiple, disjoint, independent instances of the 223 PIB to represent multiple instances of configured policy. The 224 intent is to allow for the pre-provisioning of policy that can then 225 be made active by a single, short decision from the PDP. 227 A COPS context can be defined as an independent COPS request state 228 for a particular subject category (client-type). 230 With the COPS-PR protocol, each of these states are identified by a 231 unique client handle. The creation and deletion of these PIB 232 instances is controlled by the PDP as described in [COPS-PR]. 234 Although many PIB instances may be configured on a device (the 235 maximum number of these instances being determined by the device 236 itself) only one of them can be active at any given time, the active 237 one being selected by the PDP. To facilitate this selection, the 238 Framework PIB supports an attribute to make a PIB instance the 239 active one and, similarly, to report the active PIB instance to the 240 PDP in a COPS request message. This attribute is in the Incarnation 241 Table described below. 243 Setting the attribute FrwkPibIncarnationActive to 'true' in one PIB 244 instance MUST ensure that the attribute is 'false' in all other 245 contexts. 247 3.3. Reporting of Device Capabilities 249 Each network device providing policy-based services has its own 250 inherent capabilities. These capabilities can be hardware specific, 251 e.g., an ethernet interface supporting input classification, or can 252 be statically configured, e.g., supported queuing disciplines. 253 These capabilities are communicated to the PDP when initial policy 254 is requested by the PEP. Knowing device capabilities, the PDP can 255 send the policy rule instances (PRIs) relevant to the specific 256 device, rather than sending the entire PIB. 258 The PIB indicates which capabilities the PEP must report to the PDP 259 by means of the PIB-ACCESS clause as described in [SPPI]. 261 3.4. Reporting of Device Limitations 263 To facilitate efficient policy installation, it is important to 264 understand a device's limitations in relation to the advertised 265 device capabilities. Limitations may be class-based, e.g., an 266 "install" class is supported as a "notify" or only a limited number 267 of class instances may be created, or attribute-based. Attribute 268 limitations, such as supporting a restricted set of enumerations or 269 requiring related attributes to have certain values, detail 270 implementation limitations at a fine level of granularity. 272 A PDP can avoid certain installation issues in a proactive fashion 273 by taking into account a device's limitations prior to policy 274 installation rather than in a reactive mode during installation. As 275 with device capabilities, device limitations are communicated to the 276 PDP when initial policy is requested. 278 Reported device limitations may be accompanied by guidance values 279 that can be used by a PDP to determine acceptable values for the 280 identified attributes. 282 4. Summary of the Framework PIB 284 The Framework PIB comprises of three groups: 286 1. Base PIB classes Group 288 This contains PRCs intended to describe the classes supported 289 by the PEP, limitations and its current configuration. 291 PRC Support Table 293 As the technology evolves, we expect devices to be enhanced 294 with new PIBs, existing PIBs to add new PRCs and existing PRCs 295 to be augmented or extended with new attributes. Also, it is 296 likely that some existing PRCs or individual attributes of PRCs 297 will be deprecated. The PRC Support Table describes the PRCs 298 that the device supports as well as the individual attributes 299 of each PRC. Using this information the PDP can potentially 300 tailor the policy to more closely match the capabilities of the 301 device. The PRC Support Table instances are specific to the 302 particular Subject Category (Client-Type). That is, the PRC 303 Support Table for Subject Category 'A' will not include 304 instances for classes supported by the Subject Category 'B'. 306 PIB Incarnation Table 308 This table contains exactly one row (corresponding to one PRI) 309 per context. It identifies the PDP that was the last to 310 download policy into the device and also contains an identifier 311 to identify the version of the policy currently downloaded. 312 This identifier, both its syntax and value, is meaningful only 313 to the PDPs. It is intended to be a mechanism whereby a PDP, 314 on connecting to a PEP, can easily identify a known incarnation 315 of policy. The incarnation PRC also includes an attribute to 316 indicate which context is the active one at the present time. 318 Attribute Limitations Table 320 Some devices may not be able to implement the full range of 321 values for all attributes. In principle, each PRC supports a 322 set of errors that the PEP can report to the PDP in the event 323 that the specified policy is not implementable. There are two 324 problems with this: it may be preferable for the PDP to be 325 informed of the device limitations before actually attempting 326 to install policy, and while the error can indicate that a 327 particular attribute value is unacceptable to the PEP, this 328 does not help the PDP ascertain which values would be 329 acceptable. To alleviate these limitations, the PEP can report 330 some limitations of attribute values in the Attribute 331 Limitations Table. 333 Device Identification Table 335 This class contains a single policy rule instance that contains 336 device-specific information that is used to facilitate 337 efficient policy installation by a PDP. The instance of this 338 class is reported to the PDP in a COPS request message so that 339 the PDP can take into account certain device characteristics 340 during policy installation. 342 2. Device Capabilities group 344 This group contains the PRCs that contain the types of interfaces 345 of the device and the Role Combinations assigned to them. 347 Interface Capabilities Set Table 349 The interface types the PEP supports are described by rows in 350 this table (frwkIfCapSetTable). Each row, or instance of this 351 class, describes the characteristics of an interface type. The 352 PEP notifies the PDP of these interface types and then the PDP 353 configures the interfaces, per role combination. 355 Interface Capability and Role Combo Table 357 The Interface Cap Set Table describes the types of interfaces 358 the PEP supports by their capabilities. Configuration is done 359 in terms of these interface types and the role combinations 360 assigned to them; The PDP does not deal with individual 361 interfaces on the device. Each row of this class is a 362 two-tuple. 364 3. Classifier group 366 This group contains the IP and IEEE 802 Classifier elements. The 367 set of tables consist of a Base Filter table that is extended to 368 form the IP Filter table and the 802 Filter table. The Filter 369 Group table forms sets of filters. 371 5. The Framework PIB Module 373 FRAMEWORK-PIB PIB-DEFINITIONS ::= BEGIN 375 IMPORTS 376 Unsigned32, Integer32, MODULE-IDENTITY, 377 MODULE-COMPLIANCE, OBJECT-TYPE 378 FROM COPS-PR-SPPI 379 PolicyInstanceId, PolicyReferenceId, Prid, 380 PolicyTagId 381 FROM COPS-PR-SPPI-TC 382 InetAddress 383 FROM INET-ADDRESS-MIB 384 TruthValue, TEXTUAL-CONVENTION, PhysAddress 385 FROM SNMPv2-TC 386 Role, RoleCombination 387 FROM POLICY-DEVICE-AUX-MIB 388 SnmpAdminString 389 FROM SNMP-FRAMEWORK-MIB 390 OBJECT-GROUP 391 FROM SNMPv2-CONF; 393 frameworkPib MODULE-IDENTITY 394 SUBJECT-CATEGORY { all } 395 LAST-UPDATED "200007141200Z" 396 ORGANIZATION "IETF RAP WG" 397 CONTACT-INFO " 398 Michael Fine 399 Cisco Systems, Inc. 400 170 West Tasman Drive 401 San Jose, CA 95134-1706 USA 402 Phone: +1 408 527 8218 403 Email: mfine@cisco.com 405 Keith McCloghrie 406 Cisco Systems, Inc. 407 170 West Tasman Drive, 408 San Jose, CA 95134-1706 USA 409 Phone: +1 408 526 5260 410 Email: kzm@cisco.com 412 John Seligson 413 Nortel Networks, Inc. 414 4401 Great America Parkway 415 Santa Clara, CA 95054 USA 416 Phone: +1 408 495 2992 417 Email: jseligso@nortelnetworks.com" 418 DESCRIPTION 419 "A PIB module containing the base set of policy 420 rule classes that are required for support of 421 all policies." 423 ::= { tbd } 425 -- 426 -- The root OID for PRCs in the Framework PIB 427 -- 429 frwkBasePibClasses 430 OBJECT IDENTIFIER ::= { frameworkPib 1 } 432 -- 433 -- Textual Conventions 434 -- 436 -- 437 -- PRC Support Table 438 -- 440 frwkPrcSupportTable OBJECT-TYPE 441 SYNTAX SEQUENCE OF FrwkPrcSupportEntry 442 PIB-ACCESS notify,5 443 STATUS current 444 DESCRIPTION 445 "Each instance of this class specifies a PRC that the device 446 supports and a bit string to indicate the attributes of the 447 class that are supported. These PRIs are sent to the PDP to 448 indicate to the PDP which PRCs, and which attributes of 449 these PRCs, the device supports. This table can also be 450 downloaded by a network manager when static configuration is 451 used. 453 All install and install-notify PRCs supported by the device 454 must be represented in this table. Notify PRCs may be 455 represented for informational purposes." 457 ::= { frwkBasePibClasses 1 } 459 frwkPrcSupportEntry OBJECT-TYPE 460 SYNTAX FrwkPrcSupportEntry 461 STATUS current 462 DESCRIPTION 463 "An instance of the frwkPrcSupport class that identifies a 464 specific PRC and associated attributes as supported 465 by the device." 467 INDEX { frwkPrcSupportPrid } 468 UNIQUENESS { frwkPrcSupportSupportedPrc } 470 ::= { frwkPrcSupportTable 1 } 472 FrwkPrcSupportEntry ::= SEQUENCE { 473 frwkPrcSupportPrid PolicyInstanceId, 474 frwkPrcSupportSupportedPrc OBJECT IDENTIFIER, 475 frwkPrcSupportSupportedAttrs OCTET STRING, 476 frwkPrcSupportMaxPris Unsigned32 477 } 479 frwkPrcSupportPrid OBJECT-TYPE 480 SYNTAX PolicyInstanceId 481 STATUS current 482 DESCRIPTION 483 "An arbitrary integer index that uniquely identifies an 484 instance of the frwkPrcSupport class." 486 ::= { frwkPrcSupportEntry 1 } 488 frwkPrcSupportSupportedPrc OBJECT-TYPE 489 SYNTAX OBJECT IDENTIFIER 490 STATUS current 491 DESCRIPTION 492 "The object identifier of a supported PRC. There may not 493 be more than one instance of the frwkPrcSupport class with 494 the same value of frwkPrcSupportSupportedPrc." 496 ::= { frwkPrcSupportEntry 2 } 498 frwkPrcSupportSupportedAttrs OBJECT-TYPE 499 SYNTAX OCTET STRING 500 STATUS current 501 DESCRIPTION 502 "A bit string representing the supported attributes of the 503 class that is identified by the frwkPrcSupportSupportedPrc 504 object. 506 Each bit of this bit mask corresponds to a class attribute, 507 with the most significant bit of the i-th octet of this 508 octet string corresponding to the (8*i - 7)-th attribute, 509 and the least significant bit of the i-th octet 510 corresponding to the (8*i)-th class attribute. Each bit of 511 this bit mask specifies whether or not the corresponding 512 class attribute is currently supported, with a '1' 513 indicating support and a '0' indicating no support. If the 514 value of this bit mask is N bits long and there are more 515 than N class attributes then the bit mask is logically 516 extended with 0's to the required length." 518 ::= { frwkPrcSupportEntry 3 } 520 frwkPrcSupportMaxPris OBJECT-TYPE 521 SYNTAX Unsigned32 522 STATUS current 523 DESCRIPTION 524 "A non-negative value indicating the maximum number of 525 policy rule instances that can be installed in the 526 identified policy rule class. Note that actual number of 527 PRIs that can be installed in a PRC at any given time may be 528 less than this value based on the current operational state 529 (e.g.,resources currently consumed) of the device." 531 ::= { frwkPrcSupportEntry 4 } 533 -- 534 -- PIB Incarnation Table 535 -- 537 frwkPibIncarnationTable OBJECT-TYPE 538 SYNTAX SEQUENCE OF FrwkPibIncarnationEntry 539 PIB-ACCESS install-notify,7 540 STATUS current 541 DESCRIPTION 542 "This class contains a single policy rule instance per 543 installed context that identifies the current incarnation 544 of the PIB and the PDP or network manager that installed 545 this incarnation. The instance of this class is reported to 546 the PDP in the REQ message so that the PDP can (attempt to) 547 ascertain the current state of the PIB and the active 548 context. A network manager may use the instance to 549 determine the state of the device with regard to existing 550 NMS interactions." 552 ::= { frwkBasePibClasses 2 } 554 frwkPibIncarnationEntry OBJECT-TYPE 555 SYNTAX FrwkPibIncarnationEntry 556 STATUS current 557 DESCRIPTION 558 "An instance of the frwkPibIncarnation class. Only 559 one instance of this policy class is ever instantiated. 560 per context" 562 INDEX { frwkPibIncarnationPrid } 563 UNIQUENESS { frwkPibIncarnationName } 565 ::= { frwkPibIncarnationTable 1 } 567 FrwkPibIncarnationEntry ::= SEQUENCE { 568 frwkPibIncarnationPrid PolicyInstanceId, 569 frwkPibIncarnationName SnmpAdminString, 570 frwkPibIncarnationId OCTET STRING, 571 frwkPibIncarnationLongevity INTEGER, 572 frwkPibIncarnationTtl Unsigned32, 573 frwkPibIncarnationActive TruthValue 574 } 576 frwkPibIncarnationPrid OBJECT-TYPE 577 SYNTAX PolicyInstanceId 578 STATUS current 579 DESCRIPTION 580 "An index to uniquely identify an instance of this 581 policy class." 583 ::= { frwkPibIncarnationEntry 1 } 585 frwkPibIncarnationName OBJECT-TYPE 586 SYNTAX SnmpAdminString 587 STATUS current 588 DESCRIPTION 589 "The name of the PDP that installed the current incarnation 590 of the PIB into the device. By default, it is the zero 591 length string." 593 ::= { frwkPibIncarnationEntry 2 } 595 frwkPibIncarnationId OBJECT-TYPE 596 SYNTAX OCTET STRING 597 STATUS current 598 DESCRIPTION 599 "An ID to identify the current incarnation. It has meaning 600 to the PDP/manager that installed the PIB and perhaps its 601 standby PDPs/managers. By default, it is the zero-length 602 string." 604 ::= { frwkPibIncarnationEntry 3 } 606 frwkPibIncarnationLongevity OBJECT-TYPE 607 SYNTAX INTEGER { 608 expireNever(1), 609 expireImmediate(2), 610 expireOnTimeout(3) 611 } 612 STATUS current 613 DESCRIPTION 614 "This attribute controls what the PEP does with the 615 downloaded policy on a Client Close message or a loss of 616 connection to the PDP. 618 If set to expireNever, the PEP continues to operate with the 619 installed policy indefinitely. If set to expireImmediate, 620 the PEP immediately expires the policy obtained from the PDP 621 and installs policy from local configuration. If set to 622 expireOnTimeout, the PEP continues to operate with the 623 policy installed by the PDP for a period of time specified 624 by frwkPibIncarnationTtl. After this time (and it has not 625 reconnected to the original or new PDP) the PEP expires this 626 policy and reverts to local configuration. 628 For all cases, it is the responsibility of the PDP to check 629 the incarnation and download new policy, if necessary, on a 630 reconnect. 632 Policy enforcement timing only applies to policies that have 633 been installed dynamically (e.g., by a PDP via COPS)." 635 ::= { frwkPibIncarnationEntry 4 } 637 frwkPibIncarnationTtl OBJECT-TYPE 638 SYNTAX Unsigned32 639 STATUS current 640 DESCRIPTION 641 "The number of seconds after a Client Close or TCP timeout 642 for which the PEP continues to enforce the policy in the 643 PIB. 644 After this interval, the PIB is considered expired and the 645 device no longer enforces the policy installed in the PIB. 647 This attribute is only meaningful if 648 frwkPibIncarnationLongevity is set to expireOnTimeout." 650 ::= { frwkPibIncarnationEntry 5 } 652 frwkPibIncarnationActive OBJECT-TYPE 653 SYNTAX TruthValue 654 STATUS current 655 DESCRIPTION 656 "If this attribute is set to TRUE, then the PIB instance 657 to which this PRI belongs becomes the active PIB instance. 658 The previous active instance MUST become inactive and the 659 frwkPibIncarnationActive attribute in that PIB instance 660 MUST be set to false." 662 ::= { frwkPibIncarnationEntry 6 } 664 -- 665 -- Device Identification Table 666 -- 668 -- This table supports the ability to export general 669 -- purpose device information to facilitate efficient 670 -- communication between the device and a PDP 672 frwkDeviceIdTable OBJECT-TYPE 673 SYNTAX SEQUENCE OF FrwkDeviceIdEntry 674 PIB-ACCESS notify,5 675 STATUS current 676 DESCRIPTION 677 "This class contains a single policy rule instance that 678 contains device-specific information that is used to 679 facilitate efficient policy installation by a PDP. The 680 instance of this class is reported to the PDP in a COPS 681 request message so that the PDP can take into account 682 certain device characteristics during policy installation." 684 ::= { frwkBasePibClasses 3 } 686 frwkDeviceIdEntry OBJECT-TYPE 687 SYNTAX FrwkDeviceIdEntry 688 STATUS current 689 DESCRIPTION 690 "An instance of the frwkDeviceId class. Only one instance of 691 this policy class is ever instantiated." 693 INDEX { frwkDeviceIdPrid } 694 UNIQUENESS { frwkDeviceIdDescr } 696 ::= { frwkDeviceIdTable 1 } 698 FrwkDeviceIdEntry ::= SEQUENCE { 699 frwkDeviceIdPrid PolicyInstanceId, 700 frwkDeviceIdDescr SnmpAdminString, 701 frwkDeviceIdMaxMsg Unsigned32, 702 frwkDeviceIdMaxContexts Unsigned32 703 } 705 frwkDeviceIdPrid OBJECT-TYPE 706 SYNTAX PolicyInstanceId 707 STATUS current 708 DESCRIPTION 709 "An index to uniquely identify an instance of this 710 policy class." 712 ::= { frwkDeviceIdEntry 1 } 714 frwkDeviceIdDescr OBJECT-TYPE 715 SYNTAX SnmpAdminString (SIZE(0..255)) 716 STATUS current 717 DESCRIPTION 718 "A textual description of the PEP. This value should include 719 the name and version identification of the PEP's hardware 720 and software." 722 ::= { frwkDeviceIdEntry 2 } 724 frwkDeviceIdMaxMsg OBJECT-TYPE 725 SYNTAX Unsigned32 726 STATUS current 727 DESCRIPTION 728 "The maximum message size, in octets, that the device 729 is capable of processing. Received messages with a 730 size in excess of this value must cause the PEP to return an 731 error to the PDP containing the global error code 732 'maxMsgSizeExceeded'." 734 ::= { frwkDeviceIdEntry 3 } 736 frwkDeviceIdMaxContexts OBJECT-TYPE 737 SYNTAX Unsigned32 738 STATUS current 739 DESCRIPTION 740 "The maximum number of unique contexts supported by 741 the device." 743 ::= { frwkDeviceIdEntry 4 } 745 -- 746 -- Component Limitations Table 747 -- 749 -- This table supports the ability to export information 750 -- detailing policy class/attribute implementation limitations 751 -- to the policy management system. 753 frwkCompLimitsTable OBJECT-TYPE 754 SYNTAX SEQUENCE OF FrwkCompLimitsEntry 755 PIB-ACCESS notify,6 756 STATUS current 757 DESCRIPTION 758 "Each instance of this class identifies a policy class or 759 attribute and a limitation related to the implementation of 760 the class/attribute in the device. Additional information 761 providing guidance related to the limitation may also be 762 present. These PRIs are sent to the PDP to indicate which 763 PRCs or PRC attributes the device supports in a restricted 764 manner." 766 ::= { frwkBasePibClasses 4 } 768 frwkCompLimitsEntry OBJECT-TYPE 769 SYNTAX FrwkCompLimitsEntry 770 STATUS current 771 DESCRIPTION 772 "An instance of the frwkCompLimits class that identifies 773 a PRC or PRC attribute and a limitation related to the PRC 774 or PRC attribute implementation supported by the device. 775 All PRIs of this class represent errors that would be 776 returned in relation to the identified component for policy 777 installation requests that don't abide by the restrictions 778 indicated by the limitation type (error code) and, possibly, 779 a provided guidance value." 781 INDEX { frwkCompLimitsPrid } 782 UNIQUENESS { frwkCompLimitsComponent, 783 frwkCompLimitsType, 784 frwkCompLimitsSubType, 785 frwkCompLimitsGuidance } 787 ::= { frwkCompLimitsTable 1 } 789 FrwkCompLimitsEntry ::= SEQUENCE { 790 frwkCompLimitsPrid PolicyInstanceId, 791 frwkCompLimitsComponent OBJECT IDENTIFIER, 792 frwkCompLimitsType Integer32, 793 frwkCompLimitsSubType INTEGER, 794 frwkCompLimitsGuidance OCTET STRING 795 } 796 frwkCompLimitsPrid OBJECT-TYPE 797 SYNTAX PolicyInstanceId 798 STATUS current 799 DESCRIPTION 800 "An arbitrary integer index that uniquely identifies an 801 instance of the frwkCompLimits class." 803 ::= { frwkCompLimitsEntry 1 } 805 frwkCompLimitsComponent OBJECT-TYPE 806 SYNTAX OBJECT IDENTIFIER 807 STATUS current 808 DESCRIPTION 809 "The object identifier of a PRC or PRC attribute that 810 is supported in some limited fashion with regard to it's 811 definition in the associated PIB module. The same PRC or 812 PRC attribute identifier may appear in the table several 813 times, once for each implementation limitation 814 acknowledged by the device. " 816 ::= { frwkCompLimitsEntry 2 } 818 frwkCompLimitsType OBJECT-TYPE 819 SYNTAX Integer32 820 STATUS current 821 DESCRIPTION 822 "A value describing an implementation limitation for the 823 device related to the PRC or PRC attribute identified by 824 the frwkCompLimitsComponent data in this class instance. 825 Values for this object are derived from the defined 826 error values associated with the PRC of the identified 827 attribute or the PRC itself. All genericPrc and specificPrc 828 (defined in a PRC INSTALL-ERRORS clause) error codes 829 represent valid limitation type values. The enumeration 830 values for generic Class-Specific errors are listed in 831 [COPS-PR]. 833 For example, an implementation of the frwkIpFilter class may 834 be limited in several ways, such as address mask, protocol 835 and Layer 4 port options. These limitations could be 836 exported using this table with the following instances: 838 Component Type 839 -------------------------------------------------- 840 'frwkIpFilterDstAddrMask' 'attrValueSupLimited' 841 'frwkIpFilterSrcAddrMask' 'attrValueSupLimited' 842 'frwkIpFilterProtocol' 'attrValueSupLimited' 843 'frwkIpFilterProtocol' 'attrValueSupLimited' 844 'frwkIpFilterDstL4PortMin' 'invalidDstL4PortData' 845 'frwkIpFilterDstL4PortMax' 'invalidDstL4PortData' 846 'frwkBaseFilterPermit' 'attrEnumSupLimited' 847 The above entries describe a number of limitations that 848 may be in effect for the frwkIpFilter class on a given 849 device. The limitations include restrictions on acceptable 850 values for certain attributes and indications of the 851 relationship between related attributes. 853 Also, an implementation of a PRC may be limited in the ways 854 it can be accessed. For instance: 855 Component Type 856 -------------------------------------------------- 857 'DscpMapEntry' 'priNotifyOnly' 859 If the errors defined in the INSTALL-ERRORS section are not 860 generic Class-Specific errors (in the example, 861 'invalidDstL4PortData') then the Error code sent should be 862 'priSpecificError'[COPS-PR] and the Sub-Error code should 863 contain the enumeration value from the INSTALL-ERRORS 864 section for the PRC (in the example, the enumeration value 865 for 'invalidDstL4PortData') [SPPI]." 867 ::= { frwkCompLimitsEntry 3 } 869 frwkCompLimitsSubType OBJECT-TYPE 870 SYNTAX INTEGER { 871 none(1), 872 lengthMin(2), 873 lengthMax(3), 874 rangeMin(4), 875 rangeMax(5), 876 enumMin(6), 877 enumMax(7), 878 enumOnly(8), 879 valueOnly(9), 880 extendsOid(10) 881 } 882 STATUS current 883 DESCRIPTION 884 "This object indicates the type of guidance related 885 to the noted limitation (as indicated by the 886 frwkCompLimitsType attribute) that is provided 887 in the frwkCompLimitsGuidance attribute. 889 A value of 'none(1)' means that no additional 890 guidance is provided for the noted limitation type. 892 A value of 'lengthMin(2)' means that the guidance 893 attribute provides data related to the minimum 894 acceptable length for the value of the identified 895 component. A corresponding class instance 896 specifying the 'lengthMax(3)' value is required 897 in conjunction with this sub-type. 899 A value of 'lengthMax(3)' means that the guidance 900 attribute provides data related to the maximum 901 acceptable length for the value of the identified 902 component. A corresponding class instance 903 specifying the 'lengthMin(2)' value is required 904 in conjunction with this sub-type. 906 A value of 'rangeMin(4)' means that the guidance 907 attribute provides data related to the lower bound 908 of the range for the value of the identified 909 component. A corresponding class instance 910 specifying the 'rangeMax(5)' value is required 911 in conjunction with this sub-type. 913 A value of 'rangeMax(5)' means that the guidance 914 attribute provides data related to the upper bound 915 of the range for the value of the identified 916 component. A corresponding class instance 917 specifying the 'rangeMin(4)' value is required 918 in conjunction with this sub-type. 920 A value of 'enumMin(6)' means that the guidance 921 attribute provides data related to the lowest 922 enumeration acceptable for the value of the 923 identified component. A corresponding 924 class instance specifying the 'enumMax(7)' 925 value is required in conjunction with this sub-type. 927 A value of 'enumMin(7)' means that the guidance 928 attribute provides data related to the largest 929 enumeration acceptable for the value of the 930 identified component. A corresponding 931 class instance specifying the 'enumMin(6)' 932 value is required in conjunction with this sub-type. 934 A value of 'enumOnly(8)' means that the guidance 935 attribute provides data related to a single 936 enumeration acceptable for the value of the 937 identified component. 939 A value of 'valueOnly(9)' means that the guidance 940 attribute provides data related to a single 941 value that is acceptable for the identified 942 component. 944 A value of 'extendsOid(10)' means that the guidance 945 attribute provides data related to a PRC that 946 AUGMENTS or EXTENDS the identified policy class." 948 ::= { frwkCompLimitsEntry 4 } 950 frwkCompLimitsGuidance OBJECT-TYPE 951 SYNTAX OCTET STRING (SIZE(0..255)) 952 STATUS current 953 DESCRIPTION 954 "A value used to convey additional information related 955 to the implementation limitation noted by the 956 frwkCompLimitsType and frwkCompLimitsSubType 957 attribute. The value of this attribute must be 958 interpreted in the context of the frwkCompLimitsType and 959 frwkCompLimitsSubType values. Note that a guidance 960 value will not necessarily be provided for all exported 961 limitations. If a guidance value is not provided, the 962 value must be a zero-length string. 964 The format of the guidance value, if one is present as 965 indicated by the frwkCompLimitsSubType attribute, 966 is described by the following table. Note that the 967 type of guidance value is dictated by the type of the 968 component whose limitation is being exported. 970 Base Type Length Value 971 --------- ------ ----- 972 INTEGER 32-bit value 973 OCTET STRING 1 byte octets of data 974 OID 1 byte 32-bit OID components." 976 ::= { frwkCompLimitsEntry 5 } 978 -- 979 -- The device interface capabilities and role combo classes group 980 -- 982 frwkDeviceCapClasses 983 OBJECT IDENTIFIER ::= { frameworkPib 2 } 985 -- 986 -- Interface Capability Set Table 987 -- 989 frwkIfCapSetTable OBJECT-TYPE 990 SYNTAX SEQUENCE OF FrwkIfCapSetEntry 991 PIB-ACCESS notify,4 992 STATUS current 993 DESCRIPTION 994 "Interface type definitions. This class describes the types 995 of interfaces that exist on the device. An interface type is 996 defined by its name. Associated with each interface type is 997 a set of capabilities. These capabilities are used by the 998 PDP to determine policy information to be associated with 999 interfaces of this type." 1001 ::= { frwkDeviceCapClasses 1 } 1003 frwkIfCapSetEntry OBJECT-TYPE 1004 SYNTAX FrwkIfCapSetEntry 1005 STATUS current 1006 DESCRIPTION 1007 "An instance of this class describes the characteristics 1008 of a type of an interface." 1010 INDEX { frwkIfCapSetPrid } 1011 UNIQUENESS { frwkIfCapSetName, 1012 frwkIfCapSetCapability } 1014 ::= { frwkIfCapSetTable 1 } 1016 FrwkIfCapSetEntry ::= SEQUENCE { 1017 frwkIfCapSetPrid PolicyInstanceId, 1018 frwkIfCapSetName SnmpAdminString, 1019 frwkIfCapSetCapability Prid 1020 } 1022 frwkIfCapSetPrid OBJECT-TYPE 1023 SYNTAX PolicyInstanceId 1024 STATUS current 1025 DESCRIPTION 1026 "An arbitrary integer index that uniquely identifies a 1027 instance of the class." 1029 ::= { frwkIfCapSetEntry 1 } 1031 frwkIfCapSetName OBJECT-TYPE 1032 SYNTAX SnmpAdminString 1033 STATUS current 1034 DESCRIPTION 1035 "The name for the capability set. The capability set name 1036 is the unique identifier of an interface type." 1038 ::= { frwkIfCapSetEntry 2 } 1040 frwkIfCapSetCapability OBJECT-TYPE 1041 SYNTAX Prid 1042 STATUS current 1043 DESCRIPTION 1044 "The complete OID specifying the PRC and the instance of the 1045 PRC containing a set of capabilities of the interface." 1047 ::= { frwkIfCapSetEntry 3 } 1049 -- 1050 -- Interface Capabilities Set Name and Role Combination Table 1051 -- 1053 frwkIfCapSetRoleComboTable OBJECT-TYPE 1054 SYNTAX SEQUENCE OF FrwkIfCapSetRoleComboEntry 1055 PIB-ACCESS notify,4 1056 STATUS current 1057 DESCRIPTION 1058 "Policy for an interface may depend not only on the type 1059 of interface but also on its roles. This table specifies 1060 all the tuples currently 1061 on the device." 1063 ::= { frwkDeviceCapClasses 2 } 1065 frwkIfCapSetRoleComboEntry OBJECT-TYPE 1066 SYNTAX FrwkIfCapSetRoleComboEntry 1067 STATUS current 1068 DESCRIPTION 1069 "An instance of this class describes a combination of an 1070 interface type and a role combination." 1072 INDEX { frwkIfCapSetRoleComboPrid } 1073 UNIQUENESS { frwkIfCapSetRoleComboName, 1074 frwkIfCapSetRoleComboRoles } 1076 ::= { frwkIfCapSetRoleComboTable 1 } 1078 FrwkIfCapSetRoleComboEntry ::= SEQUENCE { 1079 frwkIfCapSetRoleComboPrid PolicyInstanceId, 1080 frwkIfCapSetRoleComboName SnmpAdminString, 1081 frwkIfCapSetRoleComboRoles RoleCombination 1082 } 1084 frwkIfCapSetRoleComboPrid OBJECT-TYPE 1085 SYNTAX PolicyInstanceId 1086 STATUS current 1087 DESCRIPTION 1088 "An arbitrary integer index that uniquely identifies a 1089 instance of the class." 1091 ::= { frwkIfCapSetRoleComboEntry 1 } 1093 frwkIfCapSetRoleComboName OBJECT-TYPE 1094 SYNTAX SnmpAdminString 1095 STATUS current 1096 DESCRIPTION 1097 "The name of the interface type. This name must exist in 1098 frwkIfCapSetTable." 1100 ::= { frwkIfCapSetRoleComboEntry 2 } 1102 frwkIfCapSetRoleComboRoles OBJECT-TYPE 1103 SYNTAX RoleCombination 1104 STATUS current 1105 DESCRIPTION 1106 "A role combination. The PEP requires policy for interfaces 1107 with this role combination and of type 1108 frwkIfCapSetRoleComboName" 1110 ::= { frwkIfCapSetRoleComboEntry 3 } 1112 -- 1113 -- The Classification classes group 1114 -- 1116 frwkClassifierClasses 1117 OBJECT IDENTIFIER ::= { frameworkPib 3 } 1119 -- 1120 -- The Base Filter Table 1121 -- 1123 frwkBaseFilterTable OBJECT-TYPE 1124 SYNTAX SEQUENCE OF FrwkBaseFilterEntry 1125 PIB-ACCESS install,3 1126 STATUS current 1127 DESCRIPTION 1128 "The Base Filter class. A packet has to match all 1129 fields in an Filter. Wildcards may be specified for those 1130 fields that are not relevant." 1132 ::= { frwkClassifierClasses 1 } 1134 frwkBaseFilterEntry OBJECT-TYPE 1135 SYNTAX FrwkBaseFilterEntry 1136 STATUS current 1137 DESCRIPTION 1138 "An instance of the frwkBaseFilter class." 1140 INDEX { frwkBaseFilterPrid } 1142 ::= { frwkBaseFilterTable 1 } 1144 FrwkBaseFilterEntry ::= SEQUENCE { 1145 frwkBaseFilterPrid PolicyInstanceId, 1146 frwkBaseFilterPermit TruthValue 1147 } 1149 frwkBaseFilterPrid OBJECT-TYPE 1150 SYNTAX PolicyInstanceId 1151 STATUS current 1152 DESCRIPTION 1153 "An integer index to uniquely identify this Filter among all 1154 the Filters." 1156 ::= { frwkBaseFilterEntry 1 } 1158 frwkBaseFilterPermit OBJECT-TYPE 1159 SYNTAX TruthValue 1160 STATUS current 1161 DESCRIPTION 1162 "If the packet matches this filter and the value of this 1163 attribute is true, then the matching process terminates 1164 and the action associated with this filter (indirectly 1165 through the filter group) is applied to the packet. If the 1166 value of this attribute is false, then no more filters in 1167 the filter group are compared to this packet and matching 1168 continues with the first filter of the next filter group." 1170 ::= { frwkBaseFilterEntry 2 } 1172 -- 1173 -- The IP Filter Table 1174 -- 1176 frwkIpFilterTable OBJECT-TYPE 1177 SYNTAX SEQUENCE OF FrwkIpFilterEntry 1178 PIB-ACCESS install,11 1179 STATUS current 1180 DESCRIPTION 1181 "Filter definitions. A packet has to match all fields in a 1182 filter. Wildcards may be specified for those fields that 1183 are not relevant." 1185 INSTALL-ERRORS { 1186 invalidDstL4PortData(1), 1187 invalidSrcL4PortData(2) 1188 } 1189 ::= { frwkClassifierClasses 2 } 1191 frwkIpFilterEntry OBJECT-TYPE 1192 SYNTAX FrwkIpFilterEntry 1193 STATUS current 1194 DESCRIPTION 1195 "An instance of the frwkIpFilter class." 1197 EXTENDS { frwkBaseFilterEntry } 1198 UNIQUENESS { frwkIpFilterDstAddr, 1199 frwkIpFilterDstAddrMask, 1200 frwkIpFilterSrcAddr, 1201 frwkIpFilterSrcAddrMask, 1202 frwkIpFilterDscp, 1203 frwkIpFilterProtocol, 1204 frwkIpFilterDstL4PortMin, 1205 frwkIpFilterDstL4PortMax, 1206 frwkIpFilterSrcL4PortMin, 1207 frwkIpFilterSrcL4PortMax } 1209 ::= { frwkIpFilterTable 1 } 1211 FrwkIpFilterEntry ::= SEQUENCE { 1212 frwkIpFilterDstAddr InetAddress, 1213 frwkIpFilterDstAddrMask InetAddress, 1214 frwkIpFilterSrcAddr InetAddress, 1215 frwkIpFilterSrcAddrMask InetAddress, 1216 frwkIpFilterDscp Integer32, 1217 frwkIpFilterProtocol INTEGER, 1218 frwkIpFilterDstL4PortMin INTEGER, 1219 frwkIpFilterDstL4PortMax INTEGER, 1220 frwkIpFilterSrcL4PortMin INTEGER, 1221 frwkIpFilterSrcL4PortMax INTEGER 1222 } 1224 frwkIpFilterDstAddr OBJECT-TYPE 1226 SYNTAX InetAddress 1227 STATUS current 1228 DESCRIPTION 1229 "The IP address to match against the packet's destination IP 1230 address." 1232 ::= { frwkIpFilterEntry 1 } 1234 frwkIpFilterDstAddrMask OBJECT-TYPE 1235 SYNTAX InetAddress 1236 STATUS current 1237 DESCRIPTION 1238 "A mask for the matching of the destination IP address. 1239 A zero bit in the mask means that the corresponding bit in 1240 the address always matches." 1242 ::= { frwkIpFilterEntry 2 } 1244 frwkIpFilterSrcAddr OBJECT-TYPE 1245 SYNTAX InetAddress 1246 STATUS current 1247 DESCRIPTION 1248 "The IP address to match against the packet's source IP 1249 address." 1251 ::= { frwkIpFilterEntry 3 } 1253 frwkIpFilterSrcAddrMask OBJECT-TYPE 1254 SYNTAX InetAddress 1255 STATUS current 1256 DESCRIPTION 1257 "A mask for the matching of the source IP address." 1259 ::= { frwkIpFilterEntry 4 } 1261 frwkIpFilterDscp OBJECT-TYPE 1262 SYNTAX Integer32 (-1 | 0..63) 1263 STATUS current 1264 DESCRIPTION 1265 "The value that the DSCP in the packet can have and 1266 match this filter. A value of -1 indicates that a specific 1267 DSCP value has not been defined and thus all DSCP values 1268 are considered a match." 1270 ::= { frwkIpFilterEntry 5 } 1272 frwkIpFilterProtocol OBJECT-TYPE 1273 SYNTAX INTEGER (0..255) 1274 STATUS current 1275 DESCRIPTION 1276 "The IP protocol to match against the packet's protocol. 1277 A value of zero means match all." 1279 ::= { frwkIpFilterEntry 6 } 1281 frwkIpFilterDstL4PortMin OBJECT-TYPE 1282 SYNTAX INTEGER (0..65535) 1283 STATUS current 1284 DESCRIPTION 1285 "The minimum value that the packet's layer 4 destination 1286 port number can have and match this filter." 1288 ::= { frwkIpFilterEntry 7 } 1290 frwkIpFilterDstL4PortMax OBJECT-TYPE 1291 SYNTAX INTEGER (0..65535) 1292 STATUS current 1293 DESCRIPTION 1294 "The maximum value that the packet's layer 4 destination 1295 port number can have and match this filter. This value must 1296 be equal to or greater that the value specified for this 1297 filter in frwkIpFilterDstL4PortMin." 1299 ::= { frwkIpFilterEntry 8 } 1301 frwkIpFilterSrcL4PortMin OBJECT-TYPE 1302 SYNTAX INTEGER (0..65535) 1303 STATUS current 1304 DESCRIPTION 1305 "The minimum value that the packet's layer 4 source port 1306 number can have and match this filter." 1308 ::= { frwkIpFilterEntry 9 } 1310 frwkIpFilterSrcL4PortMax OBJECT-TYPE 1311 SYNTAX INTEGER (0..65535) 1312 STATUS current 1313 DESCRIPTION 1314 "The maximum value that the packet's layer 4 source port 1315 number can have and match this filter. This value must be 1316 equal to or greater that the value specified for this filter 1317 in frwkIpFilterSrcL4PortMin." 1319 ::= { frwkIpFilterEntry 10 } 1321 -- 1322 -- The IEEE 802 Filter Table 1323 -- 1325 -- The IEEE 802 Filter Table supports the specification of IEEE 1326 -- 802-based (e.g., 802.3) information that is used to perform 1327 -- traffic classification. 1328 -- 1330 frwk802FilterTable OBJECT-TYPE 1331 SYNTAX SEQUENCE OF Frwk802FilterEntry 1332 PIB-ACCESS install,9 1333 STATUS current 1334 DESCRIPTION 1335 "IEEE 802-based filter definitions. A class that contains 1336 attributes of IEEE 802 (e.g., 802.3) traffic that form 1337 filters that are used to perform traffic classification." 1339 ::= { frwkClassifierClasses 3 } 1341 frwk802FilterEntry OBJECT-TYPE 1342 SYNTAX Frwk802FilterEntry 1343 STATUS current 1344 DESCRIPTION 1345 "IEEE 802-based filter definitions. An entry specifies 1346 (potentially) several distinct matching components. Each 1347 component is tested against the data in a frame 1348 individually. An overall match occurs when all of the 1349 individual components match the data they are compared 1350 against in the frame being processed. A failure of any 1351 one test causes the overall match to fail. 1353 Wildcards may be specified for those fields that are not 1354 relevant." 1356 EXTENDS { frwkBaseFilterEntry } 1357 UNIQUENESS { frwk802FilterDstAddr, 1358 frwk802FilterDstAddrMask, 1359 frwk802FilterSrcAddr, 1360 frwk802FilterSrcAddrMask, 1361 frwk802FilterVlanId, 1362 frwk802FilterVlanTagRequired, 1363 frwk802FilterEtherType, 1364 frwk802FilterUserPriority } 1366 ::= { frwk802FilterTable 1 } 1368 Frwk802FilterEntry ::= SEQUENCE { 1369 frwk802FilterDstAddr PhysAddress, 1370 frwk802FilterDstAddrMask PhysAddress, 1371 frwk802FilterSrcAddr PhysAddress, 1372 frwk802FilterSrcAddrMask PhysAddress, 1373 frwk802FilterVlanId Integer32, 1374 frwk802FilterVlanTagRequired INTEGER, 1375 frwk802FilterEtherType Integer32, 1376 frwk802FilterUserPriority BITS 1377 } 1379 frwk802FilterDstAddr OBJECT-TYPE 1380 SYNTAX PhysAddress 1381 STATUS current 1383 DESCRIPTION 1384 "The 802 address against which the 802 DA of incoming 1385 traffic streams will be compared. Frames whose 802 DA 1386 matches the physical address specified by this object, 1387 taking into account address wildcarding as specified by the 1388 frwk802FilterDstAddrMask object, are potentially subject to 1389 the processing guidelines that are associated with this 1390 entry through the related action class." 1392 ::= { frwk802FilterEntry 1 } 1394 frwk802FilterDstAddrMask OBJECT-TYPE 1395 SYNTAX PhysAddress 1396 STATUS current 1397 DESCRIPTION 1398 "This object specifies the bits in a 802 destination address 1399 that should be considered when performing a 802 DA 1400 comparison against the address specified in the 1401 frwk802FilterDstAddr object. 1403 The value of this object represents a mask that is logically 1404 and'ed with the 802 DA in received frames to derive the 1405 value to be compared against the frwk802FilterDstAddr 1406 address. A zero bit in the mask thus means that the 1407 corresponding bit in the address always matches. The 1408 frwk802FilterDstAddr value must also be masked using this 1409 value prior to any comparisons. 1411 The length of this object in octets must equal the length in 1412 octets of the frwk802FilterDstAddr. Note that a mask with no 1413 bits set (i.e., all zeroes) effectively wildcards the 1414 frwk802FilterDstAddr object." 1416 ::= { frwk802FilterEntry 2 } 1418 frwk802FilterSrcAddr OBJECT-TYPE 1419 SYNTAX PhysAddress 1420 STATUS current 1421 DESCRIPTION 1422 "The 802 MAC address against which the 802 MAC SA of 1423 incoming traffic streams will be compared. Frames whose 802 1424 MAC SA matches the physical address specified by this 1425 object, taking into account address wildcarding as specified 1426 by the frwk802FilterSrcAddrMask object, are potentially 1427 subject to the processing guidelines that are associated 1428 with this entry through the related action class." 1430 ::= { frwk802FilterEntry 3 } 1432 frwk802FilterSrcAddrMask OBJECT-TYPE 1433 SYNTAX PhysAddress 1434 STATUS current 1435 DESCRIPTION 1436 "This object specifies the bits in a 802 MAC source address 1437 that should be considered when performing a 802 MAC SA 1438 comparison against the address specified in the 1439 frwk802FilterSrcAddr object. 1441 The value of this object represents a mask that is logically 1442 and'ed with the 802 MAC SA in received frames to derive the 1443 value to be compared against the frwk802FilterSrcAddr 1444 address. A zero bit in the mask thus means that the 1445 corresponding bit in the address always matches. The 1446 frwk802FilterSrcAddr value must also be masked using this 1447 value prior to any comparisons. 1449 The length of this object in octets must equal the length in 1450 octets of the frwk802FilterSrcAddr. Note that a mask with no 1451 bits set (i.e., all zeroes) effectively wildcards the 1452 frwk802FilterSrcAddr object." 1454 ::= { frwk802FilterEntry 4 } 1456 frwk802FilterVlanId OBJECT-TYPE 1457 SYNTAX Integer32 (-1 | 1..4094) 1458 STATUS current 1459 DESCRIPTION 1460 "The VLAN ID (VID) that uniquely identifies a VLAN 1461 within the device. This VLAN may be known or unknown 1462 (i.e., traffic associated with this VID has not yet 1463 been seen by the device) at the time this entry 1464 is instantiated. 1466 Setting the frwk802FilterVlanId object to -1 indicates that 1467 VLAN data should not be considered during traffic 1468 classification." 1470 ::= { frwk802FilterEntry 5 } 1472 frwk802FilterVlanTagRequired OBJECT-TYPE 1473 SYNTAX INTEGER { 1474 taggedOnly(1), 1475 priorityTaggedPlus(2), 1476 untaggedOnly(3), 1477 ignoreTag(4) 1478 } 1479 STATUS current 1480 DESCRIPTION 1481 "This object indicates whether the presence of an 1482 IEEE 802.1Q VLAN tag in data link layer frames must 1483 be considered when determining if a given frame 1484 matches this 802 filter entry. 1486 A value of 'taggedOnly(1)' means that only frames 1487 containing a VLAN tag with a non-Null VID (i.e., a 1488 VID in the range 1..4094) will be considered a match. 1490 A value of 'priorityTaggedPlus(2)' means that only 1491 frames containing a VLAN tag, regardless of the value 1492 of the VID, will be considered a match. 1494 A value of 'untaggedOnly(3)' indicates that only 1495 untagged frames will match this filter component. 1497 The presence of a VLAN tag is not taken into 1498 consideration in terms of a match if the value is 1499 'ignoreTag(4)'." 1501 ::= { frwk802FilterEntry 6 } 1503 frwk802FilterEtherType OBJECT-TYPE 1504 SYNTAX Integer32 (-1 | 0..'ffff'h) 1505 STATUS current 1506 DESCRIPTION 1507 "This object specifies the value that will be compared 1508 against the value contained in the EtherType field of an 1509 IEEE 802 frame. Example settings would include 'IP' 1510 (0x0800), 'ARP' (0x0806) and 'IPX' (0x8137). 1512 Setting the frwk802FilterEtherTypeMin object to -1 indicates 1513 that EtherType data should not be considered during traffic 1514 classification. 1516 Note that the position of the EtherType field depends on 1517 the underlying frame format. For Ethernet-II encapsulation, 1518 the EtherType field follows the 802 MAC source address. For 1519 802.2 LLC/SNAP encapsulation, the EtherType value follows 1520 the Organization Code field in the 802.2 SNAP header. The 1521 value that is tested with regard to this filter component 1522 therefore depends on the data link layer frame format being 1523 used. If this 802 filter component is active when there is 1524 no EtherType field in a frame (e.g., 802.2 LLC), a match is 1525 implied." 1527 ::= { frwk802FilterEntry 7 } 1529 frwk802FilterUserPriority OBJECT-TYPE 1530 SYNTAX BITS { 1531 matchPriority0(0), 1532 matchPriority1(1), 1533 matchPriority2(2), 1534 matchPriority3(3), 1535 matchPriority4(4), 1536 matchPriority5(5), 1537 matchPriority6(6), 1538 matchPriority7(7) 1539 } 1540 STATUS current 1541 DESCRIPTION 1542 "The set of values, representing the potential range 1543 of user priority values, against which the value contained 1544 in the user priority field of a tagged 802.1 frame is 1545 compared. A test for equality is performed when determining 1546 if a match exists between the data in a data link layer 1547 frame and the value of this 802 filter component. Multiple 1548 values may be set at one time such that potentially several 1549 different user priority values may match this 802 filter 1550 component. 1552 Setting all of the bits that are associated with this 1553 object causes all user priority values to match this 1554 attribute. This essentially makes any comparisons 1555 with regard to user priority values unnecessary. Untagged 1556 frames are treated as an implicit match." 1558 ::= { frwk802FilterEntry 8 } 1560 -- 1561 -- The Filter Group Definition Table 1562 -- 1564 frwkFilterGroupDefnTable OBJECT-TYPE 1565 SYNTAX SEQUENCE OF FrwkFilterGroupDefnEntry 1566 PIB-ACCESS install,5 1567 STATUS current 1568 DESCRIPTION 1569 "A class that defines Filter Groups. Each Group being an 1570 ordered list of filters. Each instance of this class 1571 identifies one filter of a group and the precedence order of 1572 that filter with respect to other filters in the same 1573 group." 1575 INSTALL-ERRORS { 1576 priPrecedenceConflict(1) -- precedence conflict detected 1577 } 1579 ::= { frwkClassifierClasses 4 } 1581 frwkFilterGroupDefnEntry OBJECT-TYPE 1582 SYNTAX FrwkFilterGroupDefnEntry 1583 STATUS current 1584 DESCRIPTION 1585 "An instance of the frwkFilterGroupDefn class." 1587 INDEX { frwkFilterGroupDefnPrid } 1589 UNIQUENESS { frwkFilterGroupDefnId, 1590 frwkFilterGroupDefnFilterId } 1592 ::= { frwkFilterGroupDefnTable 1 } 1594 FrwkFilterGroupDefnEntry ::= SEQUENCE { 1595 frwkFilterGroupDefnPrid PolicyInstanceId, 1596 frwkFilterGroupDefnId PolicyTagId, 1597 frwkFilterGroupDefnFilterId PolicyReferenceId, 1598 frwkFilterGroupDefnFilterPrecedence Unsigned32 1599 } 1601 frwkFilterGroupDefnPrid OBJECT-TYPE 1602 SYNTAX PolicyInstanceId 1603 STATUS current 1604 DESCRIPTION 1605 "Unique index of this policy rule instance." 1607 ::= { frwkFilterGroupDefnEntry 1 } 1609 frwkFilterGroupDefnId OBJECT-TYPE 1610 SYNTAX PolicyTagId 1611 STATUS current 1612 DESCRIPTION 1613 "An ID for this Filter Group. There will be one instance of 1614 the class frwkFilterGroupDefn with this ID for each 1615 instance of the Base filter class in the Filter Group per 1616 role combination. 1618 Note that this identifier is used in instances of the 1619 Class that associate a Filter Group with an interface 1620 set and specific actions. An active Filter Group-Target 1621 association prohibits the deletion of all of the 1622 frwkFilterGroupDefn instances with a given 1623 frwkFilterGroupDefnId (i.e., at 1624 least one entry for the specific frwkFilterGroupDefnId 1625 must be present in this table) until the Filter Group-Target 1626 association is terminated." 1628 ::= { frwkFilterGroupDefnEntry 2 } 1630 frwkFilterGroupDefnFilterId OBJECT-TYPE 1631 SYNTAX PolicyReferenceId 1632 PIB-REFERENCES {frwkBaseFilterEntry} 1633 STATUS current 1634 DESCRIPTION 1635 "This attribute specifies the filter in the 1636 frwkBaseFilterTable that is in the Filter Group specified by 1637 frwkFilterGroupDefnId at the position specified by the 1638 FilterPrecedence attribute. 1640 Attempting to specify an unknown class instance will result 1641 in an appropriate error indication being returned to the 1642 entity that is attempting to install the conflicting entry. 1643 For example, a 'priUnknown(2)' error indication is returned 1644 to the policy server in this situation." 1646 ::= { frwkFilterGroupDefnEntry 3 } 1648 frwkFilterGroupDefnFilterPrecedence OBJECT-TYPE 1649 SYNTAX Unsigned32 1650 STATUS current 1651 DESCRIPTION 1652 "The precedence order of this filter. The precedence order 1653 determines the position of this filter in the Filter Group. 1654 A filter with a given precedence order is positioned in the 1655 Filter group before one with a higher-valued 1656 precedence order. 1658 Precedence values within a group must be unique otherwise 1659 instance installation will be prohibited and an error 1660 value will be returned." 1662 ::= { frwkFilterGroupDefnEntry 4 } 1664 -- 1665 -- Conformance Section 1666 -- 1668 frwkBasePibConformance 1669 OBJECT IDENTIFIER ::= { frameworkPib 4 } 1671 frwkBasePibCompliances 1672 OBJECT IDENTIFIER ::= { frwkBasePibConformance 1 } 1674 frwkBasePibGroups 1675 OBJECT IDENTIFIER ::= { frwkBasePibConformance 2 } 1677 frwkBasePibCompliance MODULE-COMPLIANCE 1678 STATUS current 1679 DESCRIPTION 1680 "Describes the requirements for conformance to the 1681 Framework PIB." 1683 MODULE -- this module 1684 MANDATORY-GROUPS { frwkPrcSupportGroup, 1685 frwkPibIncarnationGroup, 1686 frwkDeviceIdGroup, 1687 frwkCompLimitsGroup, 1688 frwkIfCapSetGroup, 1689 frwkIfCapSetRoleComboGroup } 1691 OBJECT frwkPibIncarnationLongevity 1692 PIB-MIN-ACCESS notify 1693 DESCRIPTION "Install support is not required." 1695 OBJECT frwkPibIncarnationTtl 1696 PIB-MIN-ACCESS notify 1697 DESCRIPTION "Install support is not required." 1699 OBJECT frwkPibIncarnationActive 1700 PIB-MIN-ACCESS notify 1701 DESCRIPTION "Install support is not required." 1703 GROUP frwkBaseFilterGroup 1704 DESCRIPTION 1705 "The frwkBaseFilterGroup is mandatory if filtering 1706 based on traffic components is supported." 1708 GROUP frwkIpFilterGroup 1709 DESCRIPTION 1710 "The frwkIpFilterGroup is mandatory if filtering 1711 based on IP traffic components is supported." 1713 GROUP frwk802FilterGroup 1714 DESCRIPTION 1715 "The frwk802FilterGroup is mandatory if filtering 1716 based on 802 traffic criteria is supported." 1718 GROUP frwkFilterGroupDefnGroup 1719 DESCRIPTION 1720 "The frwkFilterGroupDefnGroup is mandatory if 1721 filtering based on IP traffic components is 1722 supported." 1724 ::= { frwkBasePibCompliances 1 } 1726 frwkPrcSupportGroup OBJECT-GROUP 1727 OBJECTS { 1728 frwkPrcSupportSupportedPrc, 1729 frwkPrcSupportSupportedAttrs, 1730 frwkPrcSupportMaxPris 1731 } 1732 STATUS current 1733 DESCRIPTION 1734 "Objects from the frwkPrcSupportTable." 1736 ::= { frwkBasePibGroups 1 } 1738 frwkPibIncarnationGroup OBJECT-GROUP 1739 OBJECTS { 1740 frwkPibIncarnationName, 1741 frwkPibIncarnationId, 1742 frwkPibIncarnationLongevity, 1743 frwkPibIncarnationTtl, 1744 frwkPibIncarnationActive 1745 } 1746 STATUS current 1747 DESCRIPTION 1748 "Objects from the frwkDevicePibIncarnationTable." 1750 ::= { frwkBasePibGroups 2 } 1752 frwkDeviceIdGroup OBJECT-GROUP 1753 OBJECTS { 1754 frwkDeviceIdDescr, 1755 frwkDeviceIdMaxMsg, 1756 frwkDeviceIdMaxContexts } 1757 STATUS current 1758 DESCRIPTION 1759 "Objects from the frwkDeviceIdTable." 1761 ::= { frwkBasePibGroups 3 } 1763 frwkCompLimitsGroup OBJECT-GROUP 1764 OBJECTS { 1765 frwkCompLimitsComponent, 1766 frwkCompLimitsType, 1767 frwkCompLimitsGuidance, 1768 frwkCompLimitsSubType } 1769 STATUS current 1770 DESCRIPTION 1771 "Objects from the frwkCompLimitsTable." 1773 ::= { frwkBasePibGroups 4 } 1775 frwkIfCapSetGroup OBJECT-GROUP 1776 OBJECTS { 1777 frwkIfCapSetName, 1778 frwkIfCapSetCapability 1779 } 1780 STATUS current 1781 DESCRIPTION 1782 "Objects from the frwkIfCapSetTable." 1784 ::= { frwkBasePibGroups 5 } 1786 frwkIfCapSetRoleComboGroup OBJECT-GROUP 1787 OBJECTS { 1788 frwkIfCapSetRoleComboName, 1789 frwkIfCapSetRoleComboRoles 1790 } 1791 STATUS current 1792 DESCRIPTION 1793 "Objects from the frwkIfCapSetRoleComboTable." 1795 ::= { frwkBasePibGroups 6 } 1797 frwkBaseFilterGroup OBJECT-GROUP 1798 OBJECTS { 1799 frwkBaseFilterPermit 1800 } 1801 STATUS current 1802 DESCRIPTION 1803 "Objects from the frwkBaseFilterTable." 1805 ::= { frwkBasePibGroups 7 } 1807 frwkIpFilterGroup OBJECT-GROUP 1808 OBJECTS { 1809 frwkIpFilterDstAddr, 1810 frwkIpFilterDstAddrMask, 1811 frwkIpFilterSrcAddr, 1812 frwkIpFilterSrcAddrMask, 1813 frwkIpFilterDscp, 1814 frwkIpFilterProtocol, 1815 frwkIpFilterDstL4PortMin, 1816 frwkIpFilterDstL4PortMax, 1817 frwkIpFilterSrcL4PortMin, 1818 frwkIpFilterSrcL4PortMax 1819 } 1820 STATUS current 1821 DESCRIPTION 1822 "Objects from the frwkIpFilterTable." 1824 ::= { frwkBasePibGroups 8 } 1826 frwk802FilterGroup OBJECT-GROUP 1827 OBJECTS { 1828 frwk802FilterDstAddr, 1829 frwk802FilterDstAddrMask, 1830 frwk802FilterSrcAddr, 1831 frwk802FilterSrcAddrMask, 1832 frwk802FilterVlanId, 1833 frwk802FilterVlanTagRequired, 1834 frwk802FilterEtherType, 1835 frwk802FilterUserPriority 1836 } 1837 STATUS current 1838 DESCRIPTION 1839 "Objects from the frwk802FilterTable." 1841 ::= { frwkBasePibGroups 9 } 1843 frwkFilterGroupDefnGroup OBJECT-GROUP 1844 OBJECTS { 1845 frwkFilterGroupDefnId, 1846 frwkFilterGroupDefnFilterId, 1847 frwkFilterGroupDefnFilterPrecedence 1848 } 1849 STATUS current 1850 DESCRIPTION 1851 "Objects from the frwkFilterGroupDefnTable." 1853 ::= { frwkBasePibGroups 10 } 1855 END 1857 6. Security Considerations 1859 The information contained in a PIB when transported by the COPS 1860 protocol [COPS-PR] may be sensitive, and its function of 1861 provisioning a PEP requires that only authorized communication take 1862 place. The use of IPSEC between PDP and PEP, as described in 1863 [COPS], provides the necessary protection against these threats. 1865 7. Intellectual Property Considerations 1867 The IETF is being notified of intellectual property rights claimed 1868 in regard to some or all of the specification contained in this 1869 document. For more information consult the online list of claimed 1870 rights. 1872 8. Author Information and Acknowledgments 1874 Michael Fine 1875 Cisco Systems, Inc. 1876 170 West Tasman Drive 1877 San Jose, CA 95134-1706 USA 1878 Phone: +1 408 527 8218 1879 Email: mfine@cisco.com 1881 Keith McCloghrie 1882 Cisco Systems, Inc. 1883 170 West Tasman Drive 1884 San Jose, CA 95134-1706 USA 1885 Phone: +1 408 526 5260 1886 Email: kzm@cisco.com 1888 John Seligson 1889 Nortel Networks, Inc. 1890 4401 Great America Parkway 1891 Santa Clara, CA 95054 USA 1892 Phone: +1 408 495 2992 1893 Email: jseligso@nortelnetworks.com 1895 Kwok Ho Chan 1896 Nortel Networks, Inc. 1897 600 Technology Park Drive 1898 Billerica, MA 01821 USA 1899 Phone: +1 978 288 8175 1900 Email: khchan@nortelnetworks.com 1901 Scott Hahn 1902 Intel Corp. 1903 2111 NE 25th Avenue 1904 Hillsboro, OR 97124 USA 1905 Phone: +1 503 264 8231 1906 Email: scott.hahn@intel.com 1908 Ravi Sahita 1909 Intel Corp. 1910 2111 NE 25th Avenue 1911 Hillsboro, OR 97124 USA 1912 Phone: +1 503 712 1554 1913 Email: ravi.sahita@intel.com 1915 Andrew Smith 1916 Fax: +1 415 345 1827 1917 Email: ah_smith@pacbell.net 1919 Francis Reichmeyer 1920 IPHighway Inc. 1921 Parker Plaza, 16th Floor 1922 400 Kelby St. 1923 Fort-Lee, NJ 07024 1924 Phone: (201) 585-0800 1925 Email: FranR@iphighway.com 1927 Special thanks to Carol Bell and David Durham for their many 1928 significant comments. 1930 9. References 1932 [COPS] 1933 Boyle, J., Cohen, R., Durham, D., Herzog, S., Rajan, R., and 1934 A. Sastry, "The COPS (Common Open Policy Service) Protocol" 1935 RFC 2748, January 2000. 1937 [COPS-PR] 1938 K. Chan, D. Durham, S. Gai, S. Herzog, K. McCloghrie, 1939 F. Reichmeyer, J. Seligson, A. Smith, R. Yavatkar, "COPS Usage 1940 for Policy Provisioning," draft-ietf-rap-pr-03.txt, 1941 July 2000. 1943 [SPPI] 1944 K. McCloghrie, et.al., "Structure of Policy Provisioning 1945 Information," draft-ietf-rap-sppi-01.txt, July 2000. 1947 [POLICY] 1948 M. Stevens, W. Weiss H. Mahon, B. Moore, J. Strassner, 1949 G. Waters, A. Westerinen, J. Wheeler, "Policy Framework", 1950 draft-ietf-policy-framework-00.txt, September 1999. 1952 [RAP-FRAMEWORK] 1953 R. Yavatkar, D. Pendarakis, "A Framework for Policy-based 1954 Admission Control", RFC 2753, January 2000. 1956 [SNMP-SMI] 1957 K. McCloghrie, D. Perkins, J. Schoenwaelder, J. Case, M. Rose 1958 and S. Waldbusser, "Structure of Management Information 1959 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 1961 Table of Contents 1963 Status of this Memo...............................................1 1964 1. Glossary......................................................2 1965 2. Introduction..................................................2 1966 3. General PIB Concepts..........................................2 1967 3.1. Roles.......................................................2 1968 3.1.1. An Example................................................4 1969 3.2. Multiple PIB Instances......................................5 1970 3.3. Reporting of Device Capabilities............................6 1971 3.4. Reporting of Device Limitations.............................6 1972 4. Summary of the Framework PIB..................................6 1973 5. The Framework PIB Module......................................9 1974 6. Security Considerations......................................40 1975 7. Intellectual Property Considerations.........................40 1976 8. Author Information and Acknowledgments........................40 1977 9. References...................................................41