idnits 2.17.1 draft-ietf-rap-frameworkpib-08.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? == 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 Introduction section. ** The document seems to lack an Authors' Addresses Section. ** 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 170: '...ct, then the PEP MUST reject the insta...' RFC 2119 keyword, line 188: '...ters "+" and "*" MUST not be used in a...' RFC 2119 keyword, line 281: '... PDP, the PEP SHOULD send updated 'f...' RFC 2119 keyword, line 286: '...s were sent by the PDP, the PEP SHOULD...' RFC 2119 keyword, line 289: '... MUST do so after sending the succes...' (33 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1364 has weird spacing: '... The insta...' == Line 1695 has weird spacing: '...xLength attrV...' == Line 1696 has weird spacing: '...xLength attrV...' == Line 1697 has weird spacing: '...Limited range...' == Line 1698 has weird spacing: '...Limited range...' == (5 more instances...) == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Note that the characters "+" and "*" MUST not be used in an interface Role. The Framework Role PIB module in section 4 of this document contains the Role and RoleCombination Textual Conventions. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: An attribute with this syntax MUST not have the value 0.0 (zeroDotZero). If 0.0 is a valid value, the TEXTUAL CONVENTION AttrIdentifierOidOrZero must be used which makes such use explicit." SYNTAX OBJECT IDENTIFIER == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: As the technology evolves, we expect devices to be enhanced with new PIBs, existing PIBs to add new PRCs and existing PRCs to be augmented or extended with new attributes. Also, it is likely that some existing PRCs or individual attributes of PRCs will be deprecated. The PRC Support Table describes the PRCs that the device supports as well as the individual attributes of each PRC. Using this information the PDP can potentially tailor the policy to more closely match the capabilities of the device. The PRC Support Table instances are specific to the particular Subject Category (Client-Type). That is, the PRC Support Table for Subject Category 'A' will not include instances for classes supported by the Subject Category 'B'. Note that the COPS client-type [COPS] used for Framework PIB PRIs sent/received over COPS-PR MUST be the unique SUBJECT-CATEGORY number assigned for the area of policy being managed (e.g. QoS, Security etc). The PEP MUST ignore the attributes that it reports as not Supported in the decision from the PDP. The PEP SHOULD not send duplicate PRC support instances in a COPS Request and the PDP MUST ignore duplicate instances and MUST use the first instance received for a supported PRC in a COPS Request. -- 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 (May 30, 2002) is 8001 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 3339, but no explicit reference was found in the text == Unused Reference: 'SNMPFRWK' is defined on line 3353, but no explicit reference was found in the text == Unused Reference: 'RFC2279' is defined on line 3373, but no explicit reference was found in the text ** Downref: Normative reference to an Historic RFC: RFC 3084 (ref. 'COPS-PR') ** Downref: Normative reference to an Historic RFC: RFC 3159 (ref. 'SPPI') ** Obsolete normative reference: RFC 3291 (ref. 'INETADDR') (Obsoleted by RFC 4001) -- Possible downref: Non-RFC (?) normative reference: ref. '802' ** Obsolete normative reference: RFC 2571 (ref. 'SNMPFRWK') (Obsoleted by RFC 3411) ** Obsolete normative reference: RFC 2279 (Obsoleted by RFC 3629) Summary: 11 errors (**), 0 flaws (~~), 14 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft M. Fine 2 Expires November 30, 2002 Atheros Comm. 3 File: draft-ietf-rap-frameworkpib-08.txt K. McCloghrie 4 Cisco Systems 5 J. Seligson 6 K. Chan 7 Nortel Networks 8 R. Sahita, Ed. 9 S. Hahn 10 Intel Labs 11 A. Smith 12 Allegro Networks 13 F. Reichmeyer 14 PFN 16 May 30, 2002 18 Framework Policy Information Base 20 Status of this Memo 22 This document is an Internet-Draft and is in full conformance with 23 all provisions of Section 10 of RFC2026. Internet-Drafts are 24 working documents of the Internet Engineering Task Force (IETF), its 25 areas, and its working groups. Note that other groups may also 26 distribute working documents as Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six 29 months and may be updated, replaced, or obsoleted by other documents 30 at any time. It is inappropriate to use Internet-Drafts as 31 reference material or to cite them other than as ''work in 32 progress''. 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/1id-abstracts.html 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html 40 Framework Policy Information Base May 30, 2002 42 Abstract 44 Structure of Policy Provisioning Information (SPPI) describes a 45 structure for specifying policy information that can then be 46 transmitted to a network device for the purpose of configuring 47 policy at that device. The model underlying this structure is one 48 of well-defined PRovisioning Classes (PRCs) and instances of these 49 classes (PRIs) residing in a virtual information store called the 50 Policy Information Base (PIB). 52 One way to provision policy is by means of the Common Open Policy 53 Service (COPS) protocol with the extensions for provisioning. This 54 protocol supports multiple clients, each of which may provision 55 policy for a specific policy domain such as QoS, virtual private 56 networks, or security. 58 As described in COPS usage for Policy Provisioning (COPS-PR), each 59 client supports a non-overlapping and independent set of PIB 60 modules. However, some PRovisioning Classes are common to all 61 subject-categories (client-types) and need to be present in each. 62 This document defines a set of PRCs and textual conventions that are 63 common to all clients that provision policy using COPS for 64 Provisioning. 66 1. Glossary 68 PRC PRovisioning Class. A type of policy data. See [POLTERM]. 69 PRI PRovisioning Instance. An instance of a PRC. See [POLTERM]. 70 PIB Policy Information Base. The database of policy information. 71 See [POLTERM] 72 PDP Policy Decision Point. See [RAP-FRAMEWORK]. 73 PEP Policy Enforcement Point. See [RAP-FRAMEWORK]. 75 2. General PIB Concepts 77 2.1. Roles 79 The policy to apply to an interface may depend on many factors such 80 as immutable characteristics of the interface (e.g., Ethernet or 81 frame relay), the status of the interface (e.g., half or full 82 duplex), or user configuration (e.g., branch office or headquarters 83 interface). Rather than specifying policies explicitly for each 84 interface of all devices in the network, policies are specified in 85 terms of interface functionality. 87 To describe these functionalities of an interface we use the concept 88 of "Roles". A Role is simply a string that is associated with an 89 interface. A given interface may have any number of roles 90 simultaneously. Provisioning classes have an attribute called a 91 "RoleCombination" which is a lexicographically ordered set of roles. 92 Instances of a given PRovisioning Class are applied to an interface 93 if and only if the set of roles in the role combination matches the 94 set of the roles of the interface. 96 Framework Policy Information Base May 30, 2002 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. That is, roles provide a level of 101 indirection to the application of a set of policies to specific 102 interfaces. This separates the policy definition from device 103 implementation specific interface identification. Furthermore, if 104 the same policy is being applied to several interfaces, that policy 105 need be pushed to the device only once, rather than once per 106 interface, as long as the interfaces are configured with the same 107 role combination. 109 We point out that, in the event that the administrator needs to have 110 unique policy for each interface, this can be achieved by 111 configuring each interface with a unique role. 113 The PEP sends all its Capability Set Names, Role Combinations, 114 Policy Controlled Interfaces, and their relationships to the PDP in 115 the first COPS request (REQ) message for a handle and whenever any 116 updates or deletes occur. The PDP can install new instances or 117 change existing instances of these PRIs. This operation can also 118 occur in subsequent request messages generated in response to COPS 119 state synchronization (SSQ) requests and local configuration 120 changes. 122 The comparing of roles (or role combinations) is case sensitive. 124 By convention, when formatting the role-combination for exchange 125 within a protocol message, within a PIB object's value, or as a 126 printed value, the set is formatted in lexicographical order of the 127 role's ASCII values; that is, the role that is first is formatted 128 first. For example, "a+b" and "b+a" are NOT different role- 129 combinations; rather, they are different formatting of the same 130 role-combination, and hence for this example: 131 - "a+b" is the valid formatting of that role-combination, 132 - "b+a" is an invalid formatting of that role-combination. 134 The role-combination of interfaces to which no roles have been 135 assigned is known as the "null" role-combination. (Note the 136 deliberate use of lower-case letters for "null" so that it avoids 137 confusion with the ASCII NULL character that has a value of zero but 138 a length of one.) 140 In an "install" or an "install-notify" class, the wildcard role- 141 combination "*" can be used. In addition to providing for interface- 142 specific roles, it also allows for other optimizations in reducing 143 the number of role-combinations for which a policy has to be 144 specified. For example: 146 Suppose we have three interfaces: 148 Roles A, B and R1 are assigned to interface I1 149 Roles A, B and R2 are assigned to interface I2 151 Framework Policy Information Base May 30, 2002 153 Roles A, B and R3 are assigned to interface I3 155 Then, a PRI of a fictional IfDscpAssignTable that has the following 156 values for its attributes: 158 ifDscpAssignPrid = 1 159 ifDscpAssignRoles = "*+A+B" 160 ifDscpAssignName = "4queues" 161 ifDscpAssignDscpMap = 1 163 will apply to all three interfaces, because "*" matches with R1, R2 164 and R3. The policies can be assigned to an interface due to more 165 than one wild-carded role combo matching a given interface's role 166 combo string. The PDP should attempt to resolve conflicts between 167 policies before sending policies to the PEP. In the situation where 168 the PDP sends multiple policies to a PEP and they do conflict, 169 either because of an error by the PDP or because of a device- 170 specific conflict, then the PEP MUST reject the installation of the 171 conflicting policies and return an error. 173 Formally, 174 - The wildcard Role is denoted by "*", 175 - The "*" Role is not allowed to be defined as part of the role- 176 combination of an interface as notified by the PEP to the PDP; it 177 is only allowed in policies installed/deleted via COPS-PR from 178 the PDP to the PEP. 179 - For a policy to apply to an interface when the policy's role- 180 combination is "*+a+b", then the interface's role-combination: 181 - Must include "a" and "b", and 182 - Can include zero or more other roles. 183 - The wildcard character "*" is listed before the other roles as 184 "*" is lexicographically before "a"; however, the wildcard matches 185 any zero or more roles, irrespective of lexicographical order. 186 For example: "*+b+e+g" would match "a+b+c+e+f+g" 188 Note that the characters "+" and "*" MUST not be used in an 189 interface Role. The Framework Role PIB module in section 4 of this 190 document contains the Role and RoleCombination Textual Conventions. 192 2.1.1. An Example 194 The functioning of roles might be best understood by an example. 195 Suppose I have a device with three interfaces, with roles as 196 follows: 198 IF1: "finance" 199 IF2: "finance" 200 IF3: "manager" 202 Suppose, I also have a PDP with two policies: 204 P1: Packets from finance department (role "finance") get DSCP 5 205 P2: Packets from managers (role "manager") get DSCP 6 207 Framework Policy Information Base May 30, 2002 209 To obtain policy, the PEP reports to the PDP that it has some 210 interfaces with role combination "finance" and some with role 211 combination "manager". In response, the PDP downloads policy P1 212 associated with role combination "finance" and downloads a second 213 policy P2 associated with role combination "manager". 215 Now suppose the finance person attached to IF2 is promoted to 216 manager and so the system administrator adds the role "manager" to 217 IF2. The PEP now reports to the PDP that it has three role 218 combinations: some interfaces with role combination "finance", some 219 with role combination "manager" and some with role combination 220 "finance+manager". In response, the PDP downloads an additional 221 third policy associated with the new role combination 222 "finance+manager". 224 How the PDP determines the policy for this new role combination is 225 entirely the responsibility of the PDP. It could do so 226 algorithmically or by rule. For example, there might be a rule that 227 specifies that manager policy takes preference over department 228 policy. Or there might be a third policy installed in the PDP as 229 follows: 231 P3: Packets from finance managers (role "finance" and role 232 "manager") get DSCP 7 234 The point here is that the PDP is required to determine what policy 235 applies to this new role combination and to download a third policy 236 to the PEP for the role combination "finance+manager" even if that 237 policy is the same as one already downloaded. The PEP is not 238 required (or allowed) to construct policy for new role combinations 239 from existing policy. 241 2.2. Management of Role-Combinations from the PDP 243 The PEP notifies the PDP of the Role-Combination assigned to each 244 interface and capability set name in a COPS configuration request 245 (instances of the frwkIfRoleComboTable). The first request sent to 246 the PDP must be a 'full state' request. A 'full state' request for a 247 PEP includes notify and install-notify table PRIs for the PEP which 248 must be interpreted as the complete state of the PEP and must not be 249 interpreted as updates to any previous set of PRIs sent in a 250 previous message. Any previous PRIs from the PEP should be discarded 251 when a 'full state' request is received for the particular request 252 handle. A request is specified as a 'full state' request by setting 253 the frwkPibIncarnationFullState attribute in the frwkPibIncarnation 254 PRI sent in the request. 256 All existing frwkIfRoleCombo instances must be sent to the PDP in 257 the first configuration request for a request handle. If the Role- 258 Combinations are not assigned specific values, default ('null') 259 Role-Combinations must be sent to the PDP for all ifIndices active 260 on the PEP and updates must be sent every time the IfIndices are 261 updated. The PEP may notify the PDP of the Capability sets (if any) 262 via the frwkCapabilitySetTable. If the PEP does not need to notify 264 Framework Policy Information Base May 30, 2002 266 the PDP of capability sets, it must set the capability set name in 267 the frwkIfRoleComboTable instances to a zero length string. 269 In response to this configuration request, if applicable, the PDP 270 may send policies for the PEP in a solicited decision or must send a 271 null decision. The PEP must then send a solicited report message for 272 the decision. 274 At any later time, the PDP can update the Role-Combinations assigned 275 to a specific interface, identified by IfIndex, or for an aggregate, 276 identified by the capability set name, via an unsolicited decision 277 to the PEP on any open request handle. The PDP does this by sending 278 updated PRIs for the frwkIfRoleComboTable. 280 When the Interface Role Combination associations are updated by the 281 PDP, the PEP SHOULD send updated 'full state' requests for all open 282 contexts. A context is an instantiation of the PIB module(s) 283 namespace identified by a unique COPS handle for a particular COPS 284 client type. This is true even if the PEP's request state changes 285 due to an internal event or if the state is changed by the PDP. If 286 the role-combination updates were sent by the PDP, the PEP SHOULD 287 send these updated requests only if it can process the unsolicited 288 decision containing the frwkIfRoleCombo PRIs successfully and it 289 MUST do so after sending the success report for the unsolicited 290 decision. If the PEP failed to process the decision (i.e., the 291 frwkIfRoleCombo PRIs) it MUST only send a failure report to the PDP. 293 On the other hand, the PDP must not expect to receive the updated 294 requests with the revised role-combination information until after 295 it receives a success report for these updates from the PEP. If the 296 PDP does not receive updated requests on some request handles, the 297 PEP must not be sent decision updates for that frwkIfRoleCombo 298 updates, i.e., the PDP must have the previous request state that it 299 maintained for that request handle. 301 Note that, any unsolicited decisions received by the PEP in the time 302 period after it receives updates to its Role-Combination 303 associations and before receiving solicited decisions for the 304 updated requests it sent for all context handles, must be ignored 305 since they would contain outdated decisions sent by the PDP for the 306 old request information. 308 The PDP must respond to the updated requests by solicited decisions, 309 sending policies if applicable or null decisions. The PEP must 310 respond to these solicited decisions with solicited reports to 311 complete the transaction. 313 2.3. Updating a Request State 315 This section describes the messages exchanged between the PEP and 316 PDP when the PEP is updating a previously sent request for a 317 particular COPS handle. Note that a PEP can incrementally update a 318 request only if the frwkPibIncarnationFullState attribute is shown 320 Framework Policy Information Base May 30, 2002 322 to be supported via the supported PRC table. If this attribute is 323 not supported the PDP must treat all PEP requests as the full 324 request state. 326 2.3.1 Full Request State 328 When the PEP wants to send the entire request state to the PDP (for 329 example, in response to a Synchronize State Request from the PDP), 330 the PEP MUST send the incarnation instance with the 331 frwkPibIncarnationFullState attribute set to 'true'. 333 A PDP that receives an incarnation instance in the request message 334 with this attribute set to 'true', must clear the request 335 information it maintains for this request handle and re-install the 336 information received. 338 If this attribute is set to 'false' or if the incarnation instance 339 is missing in the request message, the request must be interpreted 340 as an incremental update to the previous request message. 342 2.3.2 Installing PRIs in a Request 344 If the PEP wants to install additional PRIs for a request handle, 345 the PEP MUST ensure that frwkPibIncarnationFullState attribute is 346 set to 'false' and the PEP MUST use new (unused in this context) 347 InstanceIds [SPPI] for these PRIs. 349 When a PDP receives instances with new InstanceIds for a request 350 with the frwkPibIncarnationFullState in the incarnation instance set 351 to 'false' or if the request has no incarnation information, it must 352 interpret these PRIs as an incremental update to the request state 353 and add them to the request state it maintains for this handle. 355 2.3.3 Updating PRIs in a Request 357 If the PEP wants to update previously installed PRIs for a request 358 handle, the PEP MUST ensure that frwkPibIncarnationFullState 359 attribute is set to 'false' for these PRIs. Note that the PEP must 360 send the same InstanceIds for the PRIs being updated. If the PEP 361 uses new InstanceIds, the PDP must interpret them as Install's 362 for this request state. 364 When a PDP receives a request with instances having InstanceIds that 365 exist in its state for that handle with the 366 frwkPibIncarnationFullState in the incarnation instance set to 367 'false' or if the request has no incarnation information, it must 368 interpret these PRIs as an update to the PRIs in the request state 369 it maintains for this handle. 371 2.3.4 Removing PRIs from a Request 373 If the PEP wants to remove previously installed PRIs for a request 374 handle, the PEP MUST ensure that frwkPibIncarnationFullState 375 attribute is set to 'false' and MUST send the PRI bindings with the 377 Framework Policy Information Base May 30, 2002 379 PRID set to the InstanceId of the PRI to be removed and the length 380 field in the EPD object header set to the header length only, 381 effectively setting the data length to zero. 383 Note that the PEP must send the same InstanceIds for the PRIs being 384 removed. If the PEP sends new InstanceIds and the length field in 385 the EPD object header is set to the header length only (implying the 386 data length is zero), the PEP is attempting to remove an 387 unknown/non-existent PRI. This SHOULD result in the PDP sending 388 error PRIs in the solicited decision (see section 2.3.6 for a 389 description of the frwkErrorTable). 391 If the PEP sends new InstanceIds and the length field in the EPD 392 object header is greater than the header length only (implying the 393 EPD object has some attributes encoded in it), the PDP will 394 interpret this as an install of the PRI if it can decode the EPD 395 successfully. 397 When a PDP receives a request with instances having InstanceIds that 398 exist in its state for that handle with the 399 frwkPibIncarnationFullState in the incarnation instance set to 400 'false' or if the request has no incarnation information, and the 401 length field in the EPD object header is set to the header length 402 only (implying the data length is zero), it must remove these PRIs 403 from the request state it maintains for this handle. 405 2.3.5 Removing EXTENDED, AUGMENTED PRIs 407 The PEP should remove the extended/augmented PRIs when it removes 408 the base PRIs in the same COPS message. See [SPPI] for description 409 of EXTENDED/AUGMENTED PRCs. A PDP that receives removes for a base 410 PRI must implicitly remove the extensions. 412 2.3.6 Error Handling in Request updates 414 If the PDP cannot process all the request installs/updates/removes 415 in the COPS request message successfully, it MUST rollback to its 416 previous request state and it MUST send a solicited decision to the 417 PEP that contains frwkErrorTable instances. These instances contain 418 an error code and a sub-code as defined in the [COPS-PR] CPERR 419 object. For example if the PEP tries to remove an instance that does 420 not exist, the 'priInstanceInvalid' error code must be sent to the 421 PEP in a frwkError PRI. The frwkError PRIs also contain the PRC and 422 the InstanceId of the error-causing PRI. The PEP may then examine 423 these error PRIs and resend the modified request. Note that, until 424 the PEP resends the request updates/removes it will have 425 configuration information for the last successful request state it 426 sent to the PDP. 428 2.4. Multiple PIB Instances 430 [COPS-PR] supports multiple, disjoint, independent instances of the 431 PIB to represent multiple instances of configured policy. The 433 Framework Policy Information Base May 30, 2002 435 intent is to allow for the pre-provisioning of policy that can then 436 be made active by a single, short decision from the PDP. 438 A COPS context can be defined as an independent COPS request state 439 for a particular subject category (client-type). A context may be an 440 outsourcing context or a configuration context. A configuration 441 context is an instance of the PIB triggered and controlled by the 442 PDP, which contains device setup information. This device 443 configuration information dictates the device behavior as specified 444 by the PDP. An outsourcing context on the other hand is a PIB 445 instance that is triggered from the PEP side and is a request to the 446 PDP for action. The action requested will be interpreted in the 447 domain of the client-type. Configuration contexts belong to a set of 448 configuration contexts for a specific client type - out of which one 449 configuration context may be active. However, multiple outsourcing 450 contexts can be active simultaneously. 452 With the COPS-PR protocol, each of these states is identified by a 453 unique client handle. The creation and deletion of these PIB 454 instances can be controlled by the PDP as described in [COPS-PR] or 455 can be triggered by an event by the PEP. A PEP must open at least 456 one "request-state" for configuration for a given subject-category 457 (client type). Additional "request-states" at the PEP may be 458 initiated by the PDP or asynchronously generated by the PEP for 459 outsourcing due to local events, which will be fully specified by 460 the PRID/EPD data carried in the request. 462 The frwkPibIncarnationInCtxtSet flag defines a set of contexts out 463 of which only one context can be active at any given time. This set 464 is called the 'configuration contexts' set. At the most one context 465 may be active from this 'configuration context' set at any given 466 time. Contexts that have the frwkPibIncarnationInCtxtSet attribute 467 set to 'true' belong to this set. Contexts that do not belong to 468 this set have the frwkPibIncarnationInCtxtSet set to 'false' and 469 belong to the set of 'outsourcing contexts'. Note that a PEP can 470 have these two sets of contexts only if the 471 frwkPibIncarnationInCtxtSet attribute is shown to be supported via 472 the supported PRC table. If the frwkPibIncarnationInCtxtSet is not 473 supported a PEP must treat all contexts as belonging to the set of 474 'configuration contexts' i.e., at the most one context can be active 475 at any given time. 477 Note that in the event that a PEP has an capability change such as a 478 card hot swap or any other change in its notify information that may 479 warrant a policy refresh, a subsequent complete or incremental 480 request must be issued to the PDP containing the new/updated 481 capabilities for all the configuration contexts. A request for re- 482 configuration is issued for all request state configuration 483 contexts, both for the active configuration context as well as any 484 inactive configuration contexts. This is to ensure that when an 485 inactive configuration context is activated, it has been pre- 486 configured with policies compatible with the PEP's current 487 capabilities. 489 Framework Policy Information Base May 30, 2002 491 Although many PIB instances may be configured on a device (the 492 maximum number of these instances being determined by the device 493 itself) only one of the contexts from the 'configuration contexts' 494 set can be active at any given time, the active one being selected 495 by the PDP. The Framework PIB supports the attribute 496 frwkPibIncarnationActive in the frwkPibIncarnationTable to allow the 497 PDP to denote the PIB instance as being active in a COPS decision 498 message, and similarly, to report the active state (active or not) 499 of the PIB instance to the PDP in a COPS request message. 501 When the PEP installs an attribute frwkPibIncarnationActive that is 502 'true' in one PIB instance which belongs to the 'configuration 503 contexts' set, the PEP must ensure, re-setting the attribute if 504 necessary, that the frwkPibIncarnationActive attribute is 'false' 505 in all other installed contexts that belong to this set. To switch 506 contexts, the PDP should set the frwkPibIncarnationActive attribute 507 to 'true' in the context it wants to make the active context. The 508 PDP should set this attribute in a context to 'false' only if it 509 wants to send an inactive context to the PEP or deactivate the 510 active context on the PEP. If an active context is made inactive 511 without activating another context, the PEP must not have any 512 policies enforced from any configuration contexts installed. 514 2.5. Reporting and Configuring of Device Capabilities 516 Each network device providing policy-based services has its own 517 inherent capabilities. These capabilities can be hardware specific, 518 e.g., an Ethernet interface supporting input classification, or can 519 be statically configured, e.g., supported queuing disciplines. 520 These capabilities are organized into Capability Sets, with each 521 Capability Set given a unique name (frwkCapabilitySetName) and 522 associated with a set of Role Combinations. Each Role Combination 523 may in that way be associated with a set of interfaces. These 524 capabilities are communicated to the PDP when policy is requested by 525 the PEP. Knowing device capabilities, the PDP can send the PRIs 526 relevant to the specific device, rather than sending the entire PIB. 528 Specific capability PRCs may be defined in other PIBs. These 529 capability instances are grouped via the frwkCapabilitySetTable. If 530 the PEP wishes to send capability information to the PDP, the PIB 531 must indicate which capabilities the PEP may send to the PDP by 532 means of the 'notify' PIB-ACCESS clause as described in [SPPI]. If a 533 PIB does not have any capabilities to communicate to the PDP, it 534 must not send any instances for the frwkCapabilitySetTable. If in 535 this case the frwkIfRoleCombo table is used to communicate role 536 combinations assigned to interfaces (via IfIndex), the 537 frwkRoleComboCapSetName attribute in the frwkIfRoleComboTable 538 instances must be set to a zero length string. 540 2.6. Reporting of Device Limitations 542 To facilitate efficient policy installation, it is important to 543 understand a device's limitations in relation to the advertised 544 device capabilities. Limitations may be class-based, e.g., an 546 Framework Policy Information Base May 30, 2002 548 "install" class is supported as a "notify" or only a limited number 549 of class instances may be created, or attribute-based. Attribute 550 limitations, such as supporting a restricted set of enumerations or 551 requiring related attributes to have certain values, detail 552 implementation limitations at a fine level of granularity. 554 A PDP can avoid certain installation issues in a proactive fashion 555 by taking into account a device's limitations prior to policy 556 installation rather than in a reactive mode during installation. As 557 with device capabilities, device limitations are communicated to the 558 PDP when policy is requested. 560 Reported device limitations may be accompanied by guidance values 561 that can be used by a PDP to determine acceptable values for the 562 identified attributes. 564 Framework Policy Information Base May 30, 2002 566 3. The Framework TC PIB module 568 FRAMEWORK-TC-PIB PIB-DEFINITIONS ::= BEGIN 570 IMPORTS MODULE-IDENTITY, TEXTUAL-CONVENTION, pib FROM COPS-PR-SPPI; 572 frwkTcPib MODULE-IDENTITY 573 SUBJECT-CATEGORIES { all } 574 LAST-UPDATED "200205300000Z" 575 ORGANIZATION "IETF RAP WG" 576 CONTACT-INFO "Keith McCloghrie 577 Cisco Systems, Inc. 578 170 West Tasman Drive, 579 San Jose, CA 95134-1706 USA 580 Phone: +1 408 526 5260 581 Email: kzm@cisco.com 583 John Seligson 584 Nortel Networks, Inc. 585 4401 Great America Parkway 586 Santa Clara, CA 95054 USA 587 Phone: +1 408 495 2992 588 Email: jseligso@nortelnetworks.com 590 Ravi Sahita 591 Intel Labs. 592 2111 NE 25th Ave. 593 Hillsboro, OR 97124 USA 594 Phone: +1 503 712 1554 595 Email: ravi.sahita@intel.com 597 RAP WG Mailing list: rap@ops.ietf.org " 598 DESCRIPTION 599 "The PIB module containing the Role and RoleCombination 600 Textual Conventions and other generic TCs." 601 REVISION "200205300000Z" 602 DESCRIPTION 603 "Initial version, published in RFC xxxx." 604 -- xxxx to be assigned by IANA 606 ::= { pib tbd } -- tbd to be assigned by IANA 608 Role ::= TEXTUAL-CONVENTION 609 STATUS current 610 DESCRIPTION 611 "A role represents a functionality characteristic or 612 capability of a resource to which policies are applied. 613 Examples of roles include Backbone_interface, 614 Frame_Relay_interface, BGP-capable-router, web-server, 615 firewall, etc. 616 The only valid character set is US-ASCII. Valid characters 617 are a-z, A-Z, 0-9, period, hyphen and underscore. A role 618 must always start with a letter (a-z or A-Z). A role must 619 not contain the US-ASCII characters '*' or '+' since they 621 Framework Policy Information Base May 30, 2002 623 have special meaning associated with them, explained in the 624 RoleCombination TEXTUAL CONVENTION." 625 SYNTAX OCTET STRING (SIZE (1..31)) 627 RoleCombination ::= TEXTUAL-CONVENTION 628 STATUS current 629 DESCRIPTION 630 "An octet string containing concatenated Roles. For the 631 format specification of roles, refer to the 'Role' TEXTUAL- 632 CONVENTION. A valid Role Combination must be formed by a set 633 of valid Roles, concatenated by the US-ASCII character '+', 634 where tThe roles are in lexicographic order from minimum to 635 maximum. For example, 'a+b' and 'b+a' are NOT different 636 role-combinations; rather, they are different formatting of 637 the same (one) role-combination. 639 Notice the roles within a role-combination are in 640 Lexicographic order from minimum to maximum, hence, we 641 declare: 642 'a+b' is the valid formatting of the role-combination, 643 'b+a' is an invalid formatting of the role-combination. 645 Notice the need of zero-length role-combination as the role- 646 combination of interfaces to which no roles have been 647 assigned. This role-combination is also known as the 'null' 648 role-combination. (Note the deliberate use of lower case 649 letters to avoid confusion with the US-ASCII NULL character 650 which has a value of zero but length of one.) 652 The US-ASCII character '*' is used to specify a wild carded 653 Role Combination. '*' must not be used to wildcard Roles. 654 Hence, we declare: 655 '*+a+b' is a valid wild carded Role Combination. 656 'eth*+a+b' is not a valid wild carded Role Combination. 658 Note that since Roles are lexicographically listed in a Role 659 Combination, the following is an invalid role combination, 660 since '*' is lexicographically before 'a': 'a+b+*'." 661 SYNTAX OCTET STRING (SIZE (0..255)) 663 PrcIdentifierOid ::= TEXTUAL-CONVENTION 664 STATUS current 665 DESCRIPTION 666 "An OID that identifies a PRC. The value MUST be an OID 667 assigned to a PRC's entry definition. The Entry definition 668 of a PRC has an OID value XxxTable.1 where XxxTable is the 669 OID assigned to the PRC table object. 671 An attribute with this syntax MUST specify a PRC, which is 672 defined in the PIB module(s) registered in the context of 673 the client-type used. 675 An attribute with this syntax cannot have the value 0.0 676 (zeroDotZero). If the attribute using this syntax can be set 678 Framework Policy Information Base May 30, 2002 680 to 0.0 use the PrcIdentifierOidOrZero TEXTUAL-CONVENTION 681 which makes such use explicit." 682 SYNTAX OBJECT IDENTIFIER 684 PrcIdentifierOidOrZero ::= TEXTUAL-CONVENTION 685 STATUS current 686 DESCRIPTION 687 "An OID that identifies a PRC or zeroDotZero (0.0). The 688 value MUST be an OID assigned to a PRC's entry definition or 689 0.0 (zeroDotZero). The Entry definition of a PRC has an OID 690 value XxxTable.1 where XxxTable is the OID assigned to the 691 PRC table object. 693 An attribute with this syntax can have the value 0.0 694 (zeroDotZero) to indicate that it currently does not 695 identify a PRC." 696 SYNTAX OBJECT IDENTIFIER 698 AttrIdentifier ::= TEXTUAL-CONVENTION 699 STATUS current 700 DESCRIPTION 701 "A Unsigned32 value that identifies an attribute in a PRC by 702 its sub-id. The sub-id is the OID assigned to this attribute 703 in the PRC definition. 705 A AttrIdentifier value is always interpreted within the 706 context of an attribute of type PrcIdentifierOid or 707 PrcIdentifierOidOrZero. The PrcIdentifierOid (or 708 PrcIdentifierOidOrZero) object which defines the context 709 must be registered immediately before the object which uses 710 the AttrIdentifier textual convention. If the context 711 defining attribute is of type PrcIdentifierOidOrZero and has 712 the value 0.0, then in that case this attribute value has no 713 meaning. 715 An attribute with this syntax MUST specify a sub-id which 716 MUST be defined in the PRC identified (if any) in the 717 PrcIdentifierOid (or PrcIdentifierOidOrZero) attribute. The 718 PrcIdentifierOid (orZero) and the AttrIdentifier attributes 719 together identify a particular attribute in a particular 720 PRC. 722 An attribute with this syntax cannot have the value 0 723 (zero). If the attribute using this syntax can be set 724 to 0 use the AttrIdentifierOrZero TEXTUAL-CONVENTION which 725 makes that explicit." 726 SYNTAX Unsigned32 (1..4294967295) 728 AttrIdentifierOrZero ::= TEXTUAL-CONVENTION 729 STATUS current 730 DESCRIPTION 731 "A Unsigned32 value that identifies an attribute in a PRC by 732 its sub-id or has the value 0 (zero). The sub-id if non- 733 zero, is the OID assigned to this attribute in the PRC 735 Framework Policy Information Base May 30, 2002 737 definition. 739 An AttrIdentifierOrZero value is always interpreted within 740 the context of an attribute of type PrcIdentifierOid or 741 PrcIdentifierOidOrZero. The PrcIdentifierOid (or 742 PrcIdentifierOidOrZero) object that defines the context must 743 be registered immediately before the object which uses the 744 AttrIdentifierOrZero textual convention. If the context 745 defining attribute is of type PrcIdentifierOidOrZero and has 746 the value 0.0, then in that case this attribute value has no 747 meaning. 749 An attribute with this syntax can have the value 0 (zero) to 750 indicate that it currently does not identify a PRC 751 attribute. If it has a non-zero value, the 752 PrcIdentifierOid (orZero) and the AttrIdentifierOrZero 753 attributes together identify a particular attribute in a 754 particular PRC." 755 SYNTAX Unsigned32 757 AttrIdentifierOid ::= TEXTUAL-CONVENTION 758 STATUS current 759 DESCRIPTION 760 "An OID that identifies an attribute in a PRC. The value 761 MUST be an OID assigned to a PRC's attribute definition. The 762 last sub-id is the sub-id of the attribute as it is 763 defined in the PRC entry definition. The prefix OID (after 764 dropping the last sub-id) is the OID assigned to the Entry 765 1.0 object of a defined PRC. The Entry definition 766 of a PRC has 767 an OID value XxxTable.1 where XxxTable is the OID assigned 768 to the PRC Table object. 770 An attribute with this syntax MUST not have the value 0.0 771 (zeroDotZero). If 0.0 is a valid value, the TEXTUAL 772 CONVENTION AttrIdentifierOidOrZero must be used which makes 773 such use explicit." 774 SYNTAX OBJECT IDENTIFIER 776 AttrIdentifierOidOrZero ::= TEXTUAL-CONVENTION 777 STATUS current 778 DESCRIPTION 779 "An OID that identifies an attribute in a PRC or has a value 780 0.0 (zeroDotZero). The value MUST be an OID assigned to a 781 PRC's attribute definition or the value 0.0. 783 If not 0.0, the last sub-id MUST be the sub-id of the 784 attribute as it is defined in the PRC Entry object 785 definition. The prefix OID (after dropping the last sub-id) 786 is the OID assigned to the Entry object of a defined PRC. 787 The Entry definition of a PRC has an OID value XxxTable.1 788 Where, XxxTable is the OID assigned to the PRC Table 789 object. 791 Framework Policy Information Base May 30, 2002 793 An attribute with this syntax can have the value 0.0 794 (zeroDotZero) to indicate that it currently does not 795 identify a PRC's attribute." 796 SYNTAX OBJECT IDENTIFIER 798 ClientType ::= TEXTUAL-CONVENTION 799 STATUS current 800 DESCRIPTION 801 "An Unsigned32 value that identifies a COPS Client-type. An 802 attribute with this syntax must be set to zero if it does 803 not specify a COPS client-type for the PRI." 804 REFERENCE "[COPS]." 805 SYNTAX Unsigned32 (0..65535) 807 ClientHandle ::= TEXTUAL-CONVENTION 808 STATUS current 809 DESCRIPTION 810 "An octet string that identifies a COPS Client handle. A 811 zero length value implies the attribute does not specify a 812 valid client handle." 813 REFERENCE "[COPS]." 814 SYNTAX OCTET STRING (SIZE(0..65535)) 816 END 818 Framework Policy Information Base May 30, 2002 820 4. Summary of the Framework PIB 822 The Framework PIB defines four groups of PRCs: 824 4.1. Base PIB classes Group 826 This contains PRCs intended to describe the PRCs supported 827 by the PEP, PRC and/or attribute limitations and its current 828 configuration. 830 PRC Support Table 832 As the technology evolves, we expect devices to be enhanced 833 with new PIBs, existing PIBs to add new PRCs and existing PRCs 834 to be augmented or extended with new attributes. Also, it is 835 likely that some existing PRCs or individual attributes of PRCs 836 will be deprecated. The PRC Support Table describes the PRCs 837 that the device supports as well as the individual attributes 838 of each PRC. Using this information the PDP can potentially 839 tailor the policy to more closely match the capabilities of the 840 device. The PRC Support Table instances are specific to the 841 particular Subject Category (Client-Type). That is, the PRC 842 Support Table for Subject Category 'A' will not include 843 instances for classes supported by the Subject Category 'B'. 844 Note that the COPS client-type [COPS] used for Framework PIB 845 PRIs sent/received over COPS-PR MUST be the unique SUBJECT- 846 CATEGORY number assigned for the area of policy being managed 847 (e.g. QoS, Security etc). 848 The PEP MUST ignore the attributes that it reports as not 849 Supported in the decision from the PDP. The PEP SHOULD not send 850 duplicate PRC support instances in a COPS Request and the PDP 851 MUST ignore duplicate instances and MUST use the first instance 852 received for a supported PRC in a COPS Request. 854 PIB Incarnation Table 856 This PRC contains exactly one row (corresponding to one PRI) 857 per context. It identifies the PDP that was the last to 858 download policy into the device and also contains an identifier 859 to identify the version of the policy currently downloaded. 860 This identifier, both its syntax and value, is meaningful only 861 to the PDPs. It is intended to be a mechanism whereby a PDP, 862 when accepting a connection from a PEP, can easily identify a 863 known incarnation of policy. This PRC defines a flag via which 864 the installed contexts are divided into a set of contexts 865 ('configuration contexts') out of which only one context is 866 active and a the remaining contexts form a set of 'outsourcing 867 contexts' which are all active. The incarnation PRC also 868 defines an attribute to indicate which configuration context is 869 the active one at the present time in the 'configuration 870 contexts' set. The incarnation instance is specific to the 871 particular Subject Category (Client-Type). 873 Framework Policy Information Base May 30, 2002 875 Component Limitations Table 877 Some devices may not be able to implement the full range of 878 values for all attributes. In principle, each PRC supports a 879 set of errors that the PEP can report to the PDP in the event 880 that the specified policy is not implementable. It may be 881 preferable for the PDP to be informed of the device limitations 882 before actually attempting to install policy, and while the 883 error can indicate that a particular attribute value is 884 unacceptable to the PEP, this does not help the PDP ascertain 885 which values would be acceptable. To alleviate these 886 limitations, the PEP can report some limitations of attribute 887 values and/or classes and possibly guidance values for the 888 attribute in the Component Limitations Table 890 Device Identification Table 892 This PRC contains a single PRI that contains device-specific 893 information that is used to facilitate efficient policy 894 installation by a PDP. The instance of this PRC is reported 895 to the PDP in a COPS request message so that the PDP can take 896 into account certain device characteristics during policy 897 installation. 899 4.2. Device Capabilities group 901 This group contains the PRCs that describe the characteristics of 902 interfaces of the device and the Role Combinations assigned to 903 them. 905 Capabilities Set Table 907 The capabilities the PEP supports are described by rows in 908 this PRC (frwkCapabilitySetTable). Each row, or instance of 909 this class, associates a unique capability name with a set of 910 capabilities that an entity on the PEP may support. The unique 911 name is used to form a set of capabilities that the name 912 represents. The capability references can specify instances in 913 relevant capability tables in any PIB. The PEP notifies the PDP 914 of these capability sets and then the PDP configures 915 the interfaces, per role combination. The unique name 916 (frwkCapabilitySetName) is not to be confused with the IfType 917 object in the Interfaces Group MIB [RFC2863]. 919 Interface and Role Combination Table 921 The Capabilities Set Table (explained above) describes the 922 entities on the PEP (for example, interfaces) by their 923 capabilities, by assigning the capability sets a unique name 924 (frwkCapabilitySetName). It is possible to tailor the behavior 925 of interfaces by assigning specific role-combinations to the 926 capability sets. This allows interfaces with the same 927 capability sets to be assigned different policies, based on the 928 current roles assigned to them. At the PDP, configuration is 930 Framework Policy Information Base May 30, 2002 932 done in terms of these interface capability set names and the 933 role-combinations assigned to them. Thus, each row of this 934 class is a tuple, that indicates the roles that have been 936 assigned to a particular capability set (as identified by 937 frwkRoleComboCapSetName) and to a particular interface. Note 938 that the uniqueness criteria for this PRC has all the 939 attributes, thus a frwkRoleComboCapSetName may have 940 multiple role-combinations that it is associated with. Via the 941 IfIndex, this PRC answers the questions of 'which interfaces 942 have a specific role combination?' and 'what role combination a 943 specific interface is a part of?'. 945 4.3. Classifier group 947 This group contains the IP, IEEE 802 and Internal Label 948 Classifier elements. The set of tables consist of a Base Filter 949 table that contains the Index InstanceId and the Negation flag 950 for the filter. This frwkBaseFilterTable is extended to form the 951 IP Filter table, the 802 Filter table [802] and the Internal 952 Label table. Filters may also be defined outside this document 953 and used to extend the Base Filter table. 955 The Extended classes do not have a separate Index value. 956 Instances of the extended classes have the same indices as their 957 base class instance. Inheritance is achieved using the EXTENDS 958 keyword as defined in [SPPI]. 960 4.4. Marker group 962 This group contains the 802 marker and internal label marker 963 PRCs. The 802 marker may be applied to mark 802 packets with the 964 required VLAN Id and/or priority value. The Internal Label marker 965 is applied to traffic in order to label it with a network device 966 specific label. Such a label is used to assist the 967 differentiation of an input flow after it has been aggregated 968 with other flows. The label is implementation specific and may 969 be used for other policy related functions like flow accounting 970 purposes and/or other data path treatments. 972 Framework Policy Information Base May 30, 2002 974 5. The Framework PIB Module 976 FRAMEWORK-PIB PIB-DEFINITIONS ::= BEGIN 978 IMPORTS 979 Unsigned32, Integer32, MODULE-IDENTITY, 980 MODULE-COMPLIANCE, OBJECT-TYPE, OBJECT-GROUP, pib 981 FROM COPS-PR-SPPI 982 InstanceId, Prid 983 FROM COPS-PR-SPPI-TC 984 RoleCombination, PrcIdentifierOid, AttrIdentifier, 985 ClientType, ClientHandle 986 FROM FRAMEWORK-TC-PIB 987 InetAddress, InetAddressType, 988 InetAddressPrefixLength, InetPortNumber 989 FROM INET-ADDRESS-MIB 990 InterfaceIndex 991 FROM IF-MIB 992 DscpOrAny 993 FROM DIFFSERV-DSCP-TC 994 TruthValue, PhysAddress 995 FROM SNMPv2-TC 996 SnmpAdminString 997 FROM SNMP-FRAMEWORK-MIB; 999 frameworkPib MODULE-IDENTITY 1000 SUBJECT-CATEGORIES { all } 1001 LAST-UPDATED "200205300000Z" 1002 ORGANIZATION "IETF RAP WG" 1003 CONTACT-INFO " 1004 Michael Fine 1005 Atheros Communications 1006 529 Almanor Ave 1007 Sunnyvale, CA 94085 USA 1008 Phone: +1 408 773 5324 1009 Email: mfine@atheros.com 1011 Keith McCloghrie 1012 Cisco Systems, Inc. 1013 170 West Tasman Drive, 1014 San Jose, CA 95134-1706 USA 1015 Phone: +1 408 526 5260 1016 Email: kzm@cisco.com 1018 John Seligson 1019 Nortel Networks, Inc. 1020 4401 Great America Parkway 1021 Santa Clara, CA 95054 USA 1022 Phone: +1 408 495 2992 1023 Email: jseligso@nortelnetworks.com 1025 Ravi Sahita 1026 Intel Labs. 1027 2111 NE 25th Ave. 1029 Framework Policy Information Base May 30, 2002 1031 Hillsboro, OR 97124 USA 1032 Phone: +1 503 712 1554 1033 Email: ravi.sahita@intel.com 1035 RAP WG Mailing list: rap@ops.ietf.org" 1037 DESCRIPTION 1038 "A PIB module containing the base set of PRCs that 1039 provide support for management of multiple PIB contexts, 1040 association of roles to device capabilities and other 1041 reusable PRCs. PEPs are required for to implement this 1042 PIB if the above features are desired. This PIB defines 1043 PRCs applicable to 'all' subject-categories." 1044 REVISION "200205300000Z" 1045 DESCRIPTION 1046 "Initial version, published in RFC xxxx." 1047 -- xxxx to be assigned by IANA 1049 ::= { pib tbd } -- tbd to be assigned by IANA 1051 -- 1052 -- The root OID for PRCs in the Framework PIB 1053 -- 1055 frwkBasePibClasses 1056 OBJECT IDENTIFIER ::= { frameworkPib 1 } 1058 -- 1059 -- PRC Support Table 1060 -- 1062 frwkPrcSupportTable OBJECT-TYPE 1063 SYNTAX SEQUENCE OF FrwkPrcSupportEntry 1064 PIB-ACCESS notify 1065 STATUS current 1066 DESCRIPTION 1067 "Each instance of this PRC specifies a PRC that the device 1068 supports and a bit string to indicate the attributes of the 1069 class that are supported. These PRIs are sent to the PDP to 1070 indicate to the PDP which PRCs, and which attributes of 1071 these PRCs, the device supports. 1073 All install and install-notify PRCs supported by the device 1074 must be represented in this PRC. Notify PRCs may be 1075 represented for informational purposes." 1077 ::= { frwkBasePibClasses 1 } 1079 frwkPrcSupportEntry OBJECT-TYPE 1080 SYNTAX FrwkPrcSupportEntry 1081 STATUS current 1083 Framework Policy Information Base May 30, 2002 1085 DESCRIPTION 1086 "An instance of the frwkPrcSupport class that identifies a 1087 specific PRC and associated attributes as supported 1088 by the device." 1090 PIB-INDEX { frwkPrcSupportPrid } 1091 UNIQUENESS { frwkPrcSupportSupportedPrc } 1093 ::= { frwkPrcSupportTable 1 } 1095 FrwkPrcSupportEntry ::= SEQUENCE { 1096 frwkPrcSupportPrid InstanceId, 1097 frwkPrcSupportSupportedPrc PrcIdentifierOid, 1098 frwkPrcSupportSupportedAttrs OCTET STRING 1099 } 1101 frwkPrcSupportPrid OBJECT-TYPE 1102 SYNTAX InstanceId 1103 STATUS current 1104 DESCRIPTION 1105 "An arbitrary integer index that uniquely identifies an 1106 instance of the frwkPrcSupport class." 1108 ::= { frwkPrcSupportEntry 1 } 1110 frwkPrcSupportSupportedPrc OBJECT-TYPE 1111 SYNTAX PrcIdentifierOid 1112 STATUS current 1113 DESCRIPTION 1114 "The object identifier of a supported PRC. The value is the 1115 OID of the Entry object of the PRC definition. The Entry 1116 Object definition of a PRC has an OID with value XxxTable.1 1117 Where, XxxTable is the OID assigned to the PRC Table 1118 Object definition. There may not be more than one instance 1119 of the frwkPrcSupport class with the same value of 1120 frwkPrcSupportSupportedPrc." 1122 ::= { frwkPrcSupportEntry 2 } 1124 frwkPrcSupportSupportedAttrs OBJECT-TYPE 1125 SYNTAX OCTET STRING 1126 STATUS current 1127 DESCRIPTION 1128 "A bit string representing the supported attributes of the 1129 class that is identified by the frwkPrcSupportSupportedPrc 1130 object. 1132 Each bit of this bit string corresponds to a class 1133 attribute, with the most significant bit of the i-th octet 1134 of this octet string corresponding to the (8*i - 7)-th 1135 attribute, and the least significant bit of the i-th octet 1137 Framework Policy Information Base May 30, 2002 1139 corresponding to the (8*i)-th class attribute. Each bit 1140 specifies whether or not the corresponding class attribute 1141 is currently supported, with a '1' indicating support and a 1142 '0' indicating no support. 1144 If the value of this bit string is N bits long and there are 1145 more than N class attributes then the bit string is 1146 logically extended with 0's to the required length. 1147 On the other hand, If the PDP receives a bit string of 1148 length N and there are less that N class attributes then the 1149 PDP should ignore the extra bits in the bit string, i.e., 1150 assume those attributes are unsupported." 1151 REFERENCE 1152 "[COPS-PR] Section 2.2.1." 1154 ::= { frwkPrcSupportEntry 3 } 1156 -- 1157 -- PIB Incarnation Table 1158 -- 1160 frwkPibIncarnationTable OBJECT-TYPE 1161 SYNTAX SEQUENCE OF FrwkPibIncarnationEntry 1162 PIB-ACCESS install-notify 1163 STATUS current 1164 DESCRIPTION 1165 "This PRC contains a single PRovisioning Instance per 1166 installed context that identifies the current incarnation 1167 of the PIB and the PDP or network manager that installed 1168 this incarnation. The instance of this PRC is reported to 1169 the PDP in the REQ message so that the PDP can (attempt to) 1170 ascertain the current state of the PIB. A network manager 1171 may use the instance to determine the state of the device." 1173 ::= { frwkBasePibClasses 2 } 1175 frwkPibIncarnationEntry OBJECT-TYPE 1176 SYNTAX FrwkPibIncarnationEntry 1177 STATUS current 1178 DESCRIPTION 1179 "An instance of the frwkPibIncarnation class. Only 1180 one instance of this PRC is ever instantiated per context" 1182 PIB-INDEX { frwkPibIncarnationPrid } 1184 ::= { frwkPibIncarnationTable 1 } 1186 FrwkPibIncarnationEntry ::= SEQUENCE { 1187 frwkPibIncarnationPrid InstanceId, 1188 frwkPibIncarnationName SnmpAdminString, 1189 frwkPibIncarnationId OCTET STRING, 1190 frwkPibIncarnationLongevity INTEGER, 1192 Framework Policy Information Base May 30, 2002 1194 frwkPibIncarnationTtl Unsigned32, 1195 frwkPibIncarnationInCtxtSet TruthValue, 1196 frwkPibIncarnationActive TruthValue, 1197 frwkPibIncarnationFullState TruthValue 1198 } 1200 frwkPibIncarnationPrid OBJECT-TYPE 1201 SYNTAX InstanceId 1202 STATUS current 1203 DESCRIPTION 1204 "An index to uniquely identify an instance of this PRC." 1206 ::= { frwkPibIncarnationEntry 1 } 1208 frwkPibIncarnationName OBJECT-TYPE 1209 SYNTAX SnmpAdminString (SIZE (0..255)) 1210 STATUS current 1211 DESCRIPTION 1212 "The name of the PDP that installed the current incarnation 1213 of the PIB into the device. By default, it is the zero 1214 length string." 1216 ::= { frwkPibIncarnationEntry 2 } 1218 frwkPibIncarnationId OBJECT-TYPE 1219 SYNTAX OCTET STRING (SIZE (0..255)) 1220 STATUS current 1221 DESCRIPTION 1222 "An ID to identify the current incarnation. It has meaning 1223 to the PDP/manager that installed the PIB and perhaps its 1224 standby PDPs/managers. By default, it is the zero-length 1225 string." 1227 ::= { frwkPibIncarnationEntry 3 } 1229 frwkPibIncarnationLongevity OBJECT-TYPE 1230 SYNTAX INTEGER { 1231 expireNever(1), 1232 expireImmediate(2), 1233 expireOnTimeout(3) 1234 } 1235 STATUS current 1236 DESCRIPTION 1237 "This attribute controls what the PEP does with the 1238 downloaded policy on a Client Close message or a loss of 1239 connection to the PDP. 1241 If set to expireNever, the PEP continues to operate with the 1242 installed policy indefinitely. If set to expireImmediate, 1243 the PEP immediately expires the policy obtained from the PDP 1244 and installs policy from local configuration. If set to 1245 expireOnTimeout, the PEP continues to operate with the 1246 policy installed by the PDP for a period of time specified 1248 Framework Policy Information Base May 30, 2002 1250 by frwkPibIncarnationTtl. After this time (and it has not 1251 reconnected to the original or new PDP) the PEP expires this 1252 policy and reverts to local configuration. 1254 For all cases, it is the responsibility of the PDP to check 1255 the incarnation and download new policy, if necessary, on a 1256 reconnect. On receiving a Remove-State for the active 1257 context, this attribute value MUST be ignored and the PEP 1258 should expire the policy in that active context immediately. 1259 Policy enforcement timing only applies to policies that have 1260 been installed dynamically (e.g., by a PDP via COPS)." 1261 REFERENCE 1262 "COPS Usage for Policy Provisioning. [COPS-PR]." 1264 ::= { frwkPibIncarnationEntry 4 } 1266 frwkPibIncarnationTtl OBJECT-TYPE 1267 SYNTAX Unsigned32 1268 UNITS "seconds" 1269 STATUS current 1270 DESCRIPTION 1271 "The number of seconds after a Client Close or TCP timeout 1272 for which the PEP continues to enforce the policy in the 1273 PIB. After this interval, the PIB is considered expired and 1274 the device no longer enforces the policy installed in the 1275 PIB. 1277 This attribute is only meaningful if 1278 frwkPibIncarnationLongevity is set to expireOnTimeout." 1280 ::= { frwkPibIncarnationEntry 5 } 1282 frwkPibIncarnationInCtxtSet OBJECT-TYPE 1283 SYNTAX TruthValue 1284 STATUS current 1285 DESCRIPTION 1286 "When the PDP installs a PRI with this flag set to 'true' it 1287 implies this context belongs to the set of contexts out of 1288 which at the most one context can be active at a given time. 1289 If this attribute is set to 'false' this context is one of 1290 the outsourcing (simultaneous active) contexts on the PEP. 1292 This attribute is 'true' for all contexts belong to the set 1293 of configuration contexts. Within the configuration context 1294 set, one context can be active identified by the 1295 frwkPibIncarnationActive attribute." 1296 REFERENCE 1297 "TruthValue TC [SNMPv2TC]." 1298 ::= { frwkPibIncarnationEntry 6 } 1300 frwkPibIncarnationActive OBJECT-TYPE 1301 SYNTAX TruthValue 1303 Framework Policy Information Base May 30, 2002 1305 STATUS current 1306 DESCRIPTION 1307 "When the PDP installs a PRI on the PEP with this attribute 1308 set to 'true' and if this context belongs to the 1309 'configuration contexts' set, i.e., the 1310 frwkPibIncarnationInCtxtSet is set to 'true', then the PIB 1311 instance to which this PRI belongs must become the active 1312 PIB instance. In this case, the previous active instance 1313 from this set MUST become inactive and the 1314 frwkPibIncarnationActive attribute in that PIB instance MUST 1315 be set to 'false'. 1317 When the PDP installs an attribute frwkPibIncarnationActive 1318 on the PEP that is 'true' in one PIB instance and if the 1319 context belongs to the 'configuration contexts' set, the PEP 1320 must ensure, re-setting the attribute if necessary, that the 1321 frwkPibIncarnationActive attribute is 'false' in all other 1322 contexts which belong to the 'configuration contexts' set." 1324 ::= { frwkPibIncarnationEntry 7 } 1326 frwkPibIncarnationFullState OBJECT-TYPE 1327 SYNTAX TruthValue 1328 STATUS current 1329 DESCRIPTION 1330 "This attribute is interpreted only when sent in a COPS 1331 request message from the PEP to the PDP. It does not have 1332 any meaning when sent from the PDP to the PEP. 1334 If this attribute is set to 'true' by the PEP, then the 1335 request that the PEP sends to the PDP must be interpreted as 1336 the complete configuration request for the PEP. The PDP must 1337 in this case refresh the request information for the 1338 handle that the request containing this PRI was received on. 1339 If this attribute is set to 'false', then the 1340 request PRIs sent in the request must be interpreted as 1341 updates to the previous request PRIs sent using that handle. 1342 See section 3.3 for details on updating request state 1343 information." 1344 REFERENCE 1345 "RFC xxxx Section 2.3" 1347 ::= { frwkPibIncarnationEntry 8 } 1349 -- 1350 -- Device Identification Table 1351 -- 1353 frwkDeviceIdTable OBJECT-TYPE 1354 SYNTAX SEQUENCE OF FrwkDeviceIdEntry 1355 PIB-ACCESS notify 1356 STATUS current 1358 Framework Policy Information Base May 30, 2002 1360 DESCRIPTION 1361 "This PRC contains a single PRovisioning Instance that 1362 contains general purpose device-specific information that is 1363 used to facilitate efficient policy communication by a PDP. 1364 The instance of this PRC is reported to the PDP in a COPS 1365 request message so that the PDP can take into account 1366 certain device characteristics during policy installation." 1368 ::= { frwkBasePibClasses 3 } 1370 frwkDeviceIdEntry OBJECT-TYPE 1371 SYNTAX FrwkDeviceIdEntry 1372 STATUS current 1373 DESCRIPTION 1374 "An instance of the frwkDeviceId class. Only one instance of 1375 this PRC is ever instantiated." 1377 PIB-INDEX { frwkDeviceIdPrid } 1379 ::= { frwkDeviceIdTable 1 } 1381 FrwkDeviceIdEntry ::= SEQUENCE { 1382 frwkDeviceIdPrid InstanceId, 1383 frwkDeviceIdDescr SnmpAdminString, 1384 frwkDeviceIdMaxMsg Unsigned32, 1385 frwkDeviceIdMaxContexts Unsigned32 1386 } 1388 frwkDeviceIdPrid OBJECT-TYPE 1389 SYNTAX InstanceId 1390 STATUS current 1391 DESCRIPTION 1392 "An index to uniquely identify an instance of this PRC." 1394 ::= { frwkDeviceIdEntry 1 } 1396 frwkDeviceIdDescr OBJECT-TYPE 1397 SYNTAX SnmpAdminString (SIZE (1..255)) 1398 STATUS current 1399 DESCRIPTION 1400 "A textual description of the PEP. This value should include 1401 the name and version identification of the PEP's hardware 1402 and software." 1404 ::= { frwkDeviceIdEntry 2 } 1406 frwkDeviceIdMaxMsg OBJECT-TYPE 1407 SYNTAX Unsigned32 (64..4294967295) 1408 UNITS "octets" 1410 Framework Policy Information Base May 30, 2002 1412 STATUS current 1413 DESCRIPTION 1414 "The maximum COPS-PR message size, in octets, that the 1415 device is capable of processing. Received messages with a 1416 size in excess of this value must cause the PEP to return an 1417 error to the PDP containing the global error code 1418 'maxMsgSizeExceeded'. This is an additional error-avoidance 1419 mechanism to allow the administrator to know the maximum 1420 message size supported so that they have the ability to 1421 control the message size of messages sent to the device. 1422 This attribute must have a non-zero value. The device should 1423 send the MAX value for Unsigned32 for this attribute if it 1424 not defined." 1425 DEFVAL { 4294967295 } 1427 ::= { frwkDeviceIdEntry 3 } 1429 frwkDeviceIdMaxContexts OBJECT-TYPE 1430 SYNTAX Unsigned32 (1..4294967295) 1431 UNITS "contexts" 1432 STATUS current 1433 DESCRIPTION 1434 "The maximum number of unique contexts supported by 1435 the device. This is an additional error-avoidance mechanism 1436 to allow the administrators to have the ability to know the 1437 maximum number of contexts supported so that they can 1438 control the number of configuration contexts they install on 1439 the device. This attribute must have a non-zero value. The 1440 device should send the MAX value for Unsigned32 for this 1441 attribute if it not defined." 1442 DEFVAL { 4294967295 } 1444 ::= { frwkDeviceIdEntry 4 } 1446 -- 1447 -- Component Limitations Table 1448 -- 1450 frwkCompLimitsTable OBJECT-TYPE 1451 SYNTAX SEQUENCE OF FrwkCompLimitsEntry 1452 PIB-ACCESS notify 1453 STATUS current 1454 DESCRIPTION 1455 "This PRC supports the ability to export information 1456 detailing PRC/attribute implementation limitations to the 1457 policy management system. Instances of this PRC apply only 1458 for PRCs with access type 'install' or 'install-notify'. 1460 Each instance of this PRC identifies a PRovisioning Class 1461 or attribute and a limitation related to the implementation 1462 of the class/attribute in the device. Additional information 1463 providing guidance related to the limitation may also be 1465 Framework Policy Information Base May 30, 2002 1467 present. These PRIs are sent to the PDP to indicate which 1468 PRCs or PRC attributes the device supports in a restricted 1469 manner." 1471 ::= { frwkBasePibClasses 4 } 1473 frwkCompLimitsEntry OBJECT-TYPE 1474 SYNTAX FrwkCompLimitsEntry 1475 STATUS current 1476 DESCRIPTION 1477 "An instance of the frwkCompLimits class that identifies 1478 a PRC or PRC attribute and a limitation related to the PRC 1479 or PRC attribute implementation supported by the device. 1480 COPS-PR lists the error codes that MUST be returned (if 1481 applicable)for policy installation that don't abide by the 1482 restrictions indicated by the limitations exported. [SPPI] 1483 defines an INSTALL-ERRORS clause that allows PIB designers 1484 to define PRC specific error codes that can be returned for 1485 policy installation. This allows efficient debugging of PIB 1486 implementations." 1487 REFERENCE 1488 "COPS Usage for Policy Provisioning. [COPS-PR]." 1490 PIB-INDEX { frwkCompLimitsPrid } 1491 UNIQUENESS { frwkCompLimitsComponent, 1492 frwkCompLimitsAttrPos, 1493 frwkCompLimitsNegation, 1494 frwkCompLimitsType, 1495 frwkCompLimitsSubType, 1496 frwkCompLimitsGuidance } 1498 ::= { frwkCompLimitsTable 1 } 1500 FrwkCompLimitsEntry ::= SEQUENCE { 1501 frwkCompLimitsPrid InstanceId, 1502 frwkCompLimitsComponent PrcIdentifierOid, 1503 frwkCompLimitsAttrPos AttrIdentifier, 1504 frwkCompLimitsNegation TruthValue, 1505 frwkCompLimitsType INTEGER, 1506 frwkCompLimitsSubType INTEGER, 1507 frwkCompLimitsGuidance OCTET STRING 1508 } 1510 frwkCompLimitsPrid OBJECT-TYPE 1511 SYNTAX InstanceId 1512 STATUS current 1513 DESCRIPTION 1514 "An arbitrary integer index that uniquely identifies an 1515 instance of the frwkCompLimits class." 1517 ::= { frwkCompLimitsEntry 1 } 1519 frwkCompLimitsComponent OBJECT-TYPE 1521 Framework Policy Information Base May 30, 2002 1523 SYNTAX PrcIdentifierOid 1524 STATUS current 1525 DESCRIPTION 1526 "The value is the OID of a PRC (the table entry) which is 1527 supported in some limited fashion or contains an attribute 1528 that is supported in some limited fashion with regard to 1529 it's definition in the associated PIB module. The same OID 1530 may appear in the table several times, once for each 1531 implementation limitation acknowledged by the device." 1533 ::= { frwkCompLimitsEntry 2 } 1535 frwkCompLimitsAttrPos OBJECT-TYPE 1536 SYNTAX AttrIdentifier 1537 STATUS current 1538 DESCRIPTION 1539 "The relative position of the attribute within the PRC 1540 specified by the frwkCompLimitsComponent. A value of 1 would 1541 represent the first columnar object in the PRC and a value 1542 of N would represent the Nth columnar object in the PRC. A 1543 value of zero (0) indicates that the limit applies to the 1544 PRC itself and not to a specific attribute." 1546 ::= { frwkCompLimitsEntry 3 } 1548 frwkCompLimitsNegation OBJECT-TYPE 1549 SYNTAX TruthValue 1550 STATUS current 1551 DESCRIPTION 1552 "A boolean value ,if 'true', negates the component limit 1553 exported." 1555 ::= { frwkCompLimitsEntry 4 } 1557 frwkCompLimitsType OBJECT-TYPE 1558 SYNTAX INTEGER { 1559 priSpaceLimited(1), 1560 attrValueSupLimited(2), 1561 attrEnumSupLimited(3), 1562 attrLengthLimited(4), 1563 prcLimitedNotify(5) 1564 } 1565 STATUS current 1566 DESCRIPTION 1567 "A value describing an implementation limitation for the 1568 device related to the PRC or PRC attribute identified by 1569 the frwkCompLimitsComponent and the frwkCompLimitsAttrPos 1570 attributes. 1572 Values for this object are one of the following: 1574 Framework Policy Information Base May 30, 2002 1576 priSpaceLimited(1) - No more instances than that specified 1577 by the guidance value may be installed in the given class. 1578 The component identified MUST be a valid PRC. The SubType 1579 used MUST be valueOnly(9). 1581 attrValueSupLimited(2) - Limited values are acceptable for 1582 the identified component. The component identified MUST be a 1583 valid PRC attribute. The guidance OCTET STRING will be 1584 decoded according to the attribute type. 1586 attrEnumSupLimited(3) - Limited enumeration values are legal 1587 for the identified component. The attribute identified MUST 1588 be a valid enum type. 1590 attrLengthLimited(4) - The length of the specified 1591 value for the identified component is limited. The component 1592 identified MUST be a valid PRC attribute of base-type OCTET 1593 STRING. 1595 prcLimitedNotify (5) - The component is currently limited 1596 for use by request or report messages prohibiting decision 1597 installation. The component identified must be a valid PRC." 1599 ::= { frwkCompLimitsEntry 5 } 1601 frwkCompLimitsSubType OBJECT-TYPE 1602 SYNTAX INTEGER { 1603 none(1), 1604 lengthMin(2), 1605 lengthMax(3), 1606 rangeMin(4), 1607 rangeMax(5), 1608 enumMin(6), 1609 enumMax(7), 1610 enumOnly(8), 1611 valueOnly(9), 1612 bitMask(10) 1613 } 1614 STATUS current 1615 DESCRIPTION 1616 "This object indicates the type of guidance related 1617 to the noted limitation (as indicated by the 1618 frwkCompLimitsType attribute) that is provided 1619 in the frwkCompLimitsGuidance attribute. 1621 A value of 'none(1)' means that no additional 1622 guidance is provided for the noted limitation type. 1624 A value of 'lengthMin(2)' means that the guidance 1625 attribute provides data related to the minimum 1626 acceptable length for the value of the identified 1627 component. A corresponding class instance 1628 specifying the 'lengthMax(3)' value is required 1630 Framework Policy Information Base May 30, 2002 1632 in conjunction with this sub-type. 1634 A value of 'lengthMax(3)' means that the guidance 1635 attribute provides data related to the maximum 1636 acceptable length for the value of the identified 1637 component. A corresponding class instance 1638 specifying the 'lengthMin(2)' value is required 1639 in conjunction with this sub-type. 1641 A value of 'rangeMin(4)' means that the guidance 1642 attribute provides data related to the lower bound 1643 of the range for the value of the identified 1644 component. A corresponding class instance 1645 specifying the 'rangeMax(5)' value is required 1646 in conjunction with this sub-type. 1648 A value of 'rangeMax(5)' means that the guidance 1649 attribute provides data related to the upper bound 1650 of the range for the value of the identified 1651 component. A corresponding class instance 1652 specifying the 'rangeMin(4)' value is required 1653 in conjunction with this sub-type. 1655 A value of 'enumMin(6)' means that the guidance 1656 attribute provides data related to the lowest 1657 enumeration acceptable for the value of the 1658 identified component. A corresponding 1659 class instance specifying the 'enumMax(7)' 1660 value is required in conjunction with this sub-type. 1662 A value of 'enumMax(7)' means that the guidance 1663 attribute provides data related to the largest 1664 enumeration acceptable for the value of the 1665 identified component. A corresponding 1666 class instance specifying the 'enumMin(6)' 1667 value is required in conjunction with this sub-type. 1669 A value of 'enumOnly(8)' means that the guidance 1670 attribute provides data related to a single 1671 enumeration acceptable for the value of the 1672 identified component. 1674 A value of 'valueOnly(9)' means that the guidance 1675 attribute provides data related to a single 1676 value that is acceptable for the identified 1677 component. 1679 A value of 'bitMask(10)' means that the guidance 1680 attribute is a bit mask such that all the combinations of 1681 bits set in the bitmask are acceptable values for the 1682 identified component which should be an attribute of type 1683 'BITS'. 1685 For example, an implementation of the frwkIpFilter class may 1687 Framework Policy Information Base May 30, 2002 1689 be limited in several ways, such as address mask, protocol 1690 and Layer 4 port options. These limitations could be 1691 exported using this PRC with the following instances: 1693 Component Type Sub-Type Guidance 1694 ------------------------------------------------------------ 1695 DstPrefixLength attrValueSupLimited valueOnly 24 1696 SrcPrefixLength attrValueSupLimited valueOnly 24 1697 Protocol attrValueSupLimited rangeMin 10 1698 Protocol attrValueSupLimited rangeMax 20 1700 The above entries describe a number of limitations that 1701 may be in effect for the frwkIpFilter class on a given 1702 device. The limitations include restrictions on acceptable 1703 values for certain attributes. 1705 Also, an implementation of a PRC may be limited in the ways 1706 it can be accessed. For instance, for a fictitious PRC 1707 dscpMapEntry, which has a PIB-ACCESS of 'install-notify': 1709 Component Type SubType Guidance 1710 ------------------------------------------------------------ 1711 dscpMapEntry prcLimitedNotify none zero-length string." 1713 ::= { frwkCompLimitsEntry 6 } 1715 frwkCompLimitsGuidance OBJECT-TYPE 1716 SYNTAX OCTET STRING 1717 STATUS current 1718 DESCRIPTION 1719 "A value used to convey additional information related 1720 to the implementation limitation. Note that a guidance 1721 value will not necessarily be provided for all exported 1722 limitations. If a guidance value is not provided, the 1723 value must be a zero-length string. 1725 The format of the guidance value, if one is present as 1726 indicated by the frwkCompLimitsSubType attribute, 1727 is described by the following table. Note that the 1728 format of guidance value is dictated by the base-type of 1729 the component whose limitation is being exported, 1730 interpreted in the context of the frwkCompLimitsType and 1731 frwkCompLimitsSubType values. Any other restrictions 1732 (such as size/range/enumerated value) on the guidance 1733 value MUST be complied with according to the definition 1734 of the component for which guidance is being specified. 1736 Note that numbers are encoded in network byte order. 1738 Base Type Value 1739 --------- ----- 1740 Unsigned32/Integer32/INTEGER 32-bit value. 1741 Unsigned64/Integer64 64-bit Value. 1742 OCTET STRING octets of data. 1744 Framework Policy Information Base May 30, 2002 1746 OID 32-bit OID components. 1747 BITS Binary octets of length 1748 same as Component specified." 1750 ::= { frwkCompLimitsEntry 7 } 1752 -- 1753 -- Complete Reference specification table 1754 -- 1756 frwkReferenceTable OBJECT-TYPE 1757 SYNTAX SEQUENCE OF FrwkReferenceEntry 1758 PIB-ACCESS install-notify 1759 STATUS current 1760 DESCRIPTION 1761 "Each instance of this PRC specifies a reference to a PRI 1762 in a specific PIB context (handle) for a specific client- 1763 type. This table gives the PDP the ability to set up 1764 policies that span installed contexts and the PEP the 1765 ability to reference instances in another, perhaps 1766 configured context. The PEP must send a 1767 'attrReferenceUnknown' COPS-PR error to the PDP if it 1768 encounters an invalid reference. " 1769 REFERENCE "[COPS-PR] error codes section 4.5." 1771 ::= { frwkBasePibClasses 5 } 1773 frwkReferenceEntry OBJECT-TYPE 1774 SYNTAX FrwkReferenceEntry 1775 STATUS current 1776 DESCRIPTION 1777 "Entry specification for the frwkReferenceTable." 1779 PIB-INDEX { frwkReferencePrid } 1780 UNIQUENESS { } 1782 ::= { frwkReferenceTable 1 } 1784 FrwkReferenceEntry ::= SEQUENCE { 1785 frwkReferencePrid InstanceId, 1786 frwkReferenceClientType ClientType, 1787 frwkReferenceClientHandle ClientHandle, 1788 frwkReferenceInstance Prid 1789 } 1791 frwkReferencePrid OBJECT-TYPE 1792 SYNTAX InstanceId 1793 STATUS current 1795 Framework Policy Information Base May 30, 2002 1797 DESCRIPTION 1798 "An arbitrary integer index that uniquely identifies an 1799 instance of the frwkReference class." 1801 ::= { frwkReferenceEntry 1 } 1803 frwkReferenceClientType OBJECT-TYPE 1804 SYNTAX ClientType 1805 STATUS current 1806 DESCRIPTION 1807 "Is unused if set to zero else specifies a client-type for 1808 which the reference is to be interpreted. This non-zero 1809 client-type must be activated explicitly via a separate 1810 COPS client-open else this attribute is not valid." 1812 ::= { frwkReferenceEntry 2 } 1814 frwkReferenceClientHandle OBJECT-TYPE 1815 SYNTAX ClientHandle 1816 STATUS current 1817 DESCRIPTION 1818 "Must be set to specify a valid client-handle in the scope 1819 of the client-type specified." 1821 ::= { frwkReferenceEntry 3 } 1823 frwkReferenceInstance OBJECT-TYPE 1824 SYNTAX Prid 1825 STATUS current 1826 DESCRIPTION 1827 "References a PRI in the context identified by 1828 frwkReferenceClientHandle for client-type identified by 1829 frwkReferenceClientType." 1831 ::= { frwkReferenceEntry 4 } 1833 -- 1834 -- Error specification table 1835 -- 1837 frwkErrorTable OBJECT-TYPE 1838 SYNTAX SEQUENCE OF FrwkErrorEntry 1839 PIB-ACCESS install 1840 STATUS current 1841 DESCRIPTION 1842 "Each instance of this PRC specifies a class specific 1843 error object. Instances of this PRC are transient, i.e., 1844 instances received in a COPS decision message must not to be 1845 maintained by the PEP in its copy of the PIB instances. This 1847 Framework Policy Information Base May 30, 2002 1849 PRC allows a PDP to send error information to the PEP if the 1850 PDP cannot process updates to a Request successfully." 1852 ::= { frwkBasePibClasses 6 } 1854 frwkErrorEntry OBJECT-TYPE 1855 SYNTAX FrwkErrorEntry 1856 STATUS current 1857 DESCRIPTION 1858 "Entry specification for the frwkErrorTable." 1860 PIB-INDEX { frwkErrorPrid } 1861 UNIQUENESS { 1862 frwkErrorCode, 1863 frwkErrorSubCode, 1864 frwkErrorPrc, 1865 frwkErrorInstance 1866 } 1868 ::= { frwkErrorTable 1 } 1870 FrwkErrorEntry ::= SEQUENCE { 1871 frwkErrorPrid InstanceId, 1872 frwkErrorCode Unsigned32, 1873 frwkErrorSubCode Unsigned32, 1874 frwkErrorPrc PrcIdentifierOid, 1875 frwkErrorInstance InstanceId 1876 } 1878 frwkErrorPrid OBJECT-TYPE 1879 SYNTAX InstanceId 1880 STATUS current 1881 DESCRIPTION 1882 "An arbitrary integer index that uniquely identifies an 1883 instance of the frwkError class." 1885 ::= { frwkErrorEntry 1 } 1887 frwkErrorCode OBJECT-TYPE 1888 SYNTAX Unsigned32 (0..65535) 1889 STATUS current 1890 DESCRIPTION 1891 "Error code defined in COPS-PR CPERR object." 1892 REFERENCE 1893 "COPS Usage for Policy Provisioning. [COPS-PR]." 1895 ::= { frwkErrorEntry 2 } 1897 frwkErrorSubCode OBJECT-TYPE 1898 SYNTAX Unsigned32 (0..65535) 1900 Framework Policy Information Base May 30, 2002 1902 STATUS current 1903 DESCRIPTION 1904 "The class-specific error object is used to communicate 1905 errors relating to specific PRCs." 1907 ::= { frwkErrorEntry 3 } 1909 frwkErrorPrc OBJECT-TYPE 1910 SYNTAX PrcIdentifierOid 1911 STATUS current 1912 DESCRIPTION 1913 "The PRC due to which the error specified by codes 1914 (frwkErrorCode , frwkErrorSubCode) occurred." 1916 ::= { frwkErrorEntry 4 } 1918 frwkErrorInstance OBJECT-TYPE 1919 SYNTAX InstanceId 1920 STATUS current 1921 DESCRIPTION 1922 "The PRI of the identified PRC (frwkErrorPrc) due to which 1923 the error specified by codes (frwkErrorCode , 1924 frwkErrorSubCode) occurred. Must be set to zero if unused." 1926 ::= { frwkErrorEntry 5 } 1928 -- 1929 -- The device capabilities and role combo classes group 1930 -- 1932 frwkDeviceCapClasses 1933 OBJECT IDENTIFIER ::= { frameworkPib 2 } 1935 -- 1936 -- Capability Set Table 1937 -- 1939 frwkCapabilitySetTable OBJECT-TYPE 1940 SYNTAX SEQUENCE OF FrwkCapabilitySetEntry 1941 PIB-ACCESS notify 1942 STATUS current 1943 DESCRIPTION 1944 "This PRC describes the capability sets that exist on the 1945 interfaces on the device. The capability set is given a 1946 unique name that identifies a set. These capability set 1947 names are used by the PDP to determine policy information to 1949 Framework Policy Information Base May 30, 2002 1951 be associated with interfaces that possess similar sets of 1952 capabilities." 1954 ::= { frwkDeviceCapClasses 1 } 1956 frwkCapabilitySetEntry OBJECT-TYPE 1957 SYNTAX FrwkCapabilitySetEntry 1958 STATUS current 1959 DESCRIPTION 1960 "An instance of this PRC describes a particular set of 1961 capabilities and associates a unique name with the set." 1963 PIB-INDEX { frwkCapabilitySetPrid } 1964 UNIQUENESS { frwkCapabilitySetName, 1965 frwkCapabilitySetCapability } 1967 ::= { frwkCapabilitySetTable 1 } 1969 FrwkCapabilitySetEntry ::= SEQUENCE { 1970 frwkCapabilitySetPrid InstanceId, 1971 frwkCapabilitySetName SnmpAdminString, 1972 frwkCapabilitySetCapability Prid 1973 } 1975 frwkCapabilitySetPrid OBJECT-TYPE 1976 SYNTAX InstanceId 1977 STATUS current 1978 DESCRIPTION 1979 "An arbitrary integer index that uniquely identifies a 1980 instance of the class." 1982 ::= { frwkCapabilitySetEntry 1 } 1984 frwkCapabilitySetName OBJECT-TYPE 1985 SYNTAX SnmpAdminString (SIZE (1..255)) 1986 STATUS current 1987 DESCRIPTION 1988 "The name for the capability set. This name is the unique 1989 identifier of a set of capabilities. This attribute must not 1990 be assigned a zero-length string." 1992 ::= { frwkCapabilitySetEntry 2 } 1994 frwkCapabilitySetCapability OBJECT-TYPE 1995 SYNTAX Prid 1996 STATUS current 1997 DESCRIPTION 1998 "The complete PRC OID and instance identifier specifying the 1999 capability PRC instance for the interface. This attribute 2000 references a specific instance of a capability table. The 2001 capability table whose instance is referenced must be 2003 Framework Policy Information Base May 30, 2002 2005 defined in the client type specific PIB that this PIB is 2006 used with. The referenced capability instance becomes a part 2007 of the set of capabilities associated with the specified 2008 frwkCapabilitySetName." 2010 ::= { frwkCapabilitySetEntry 3 } 2012 -- 2013 -- Interface and Role Combination Tables 2014 -- 2016 frwkRoleComboTable OBJECT-TYPE 2017 SYNTAX SEQUENCE OF FrwkRoleComboEntry 2018 PIB-ACCESS install-notify 2019 STATUS current 2020 DESCRIPTION 2021 "This is an abstract PRC that may be extended or referenced 2022 to enumerate the role combinations, capability set names 2023 assigned to any interface on a PEP. The identification of 2024 the interface is to be defined by its extensions or 2025 referencing PRCs." 2027 ::= { frwkDeviceCapClasses 2 } 2029 frwkRoleComboEntry OBJECT-TYPE 2030 SYNTAX FrwkRoleComboEntry 2031 STATUS current 2032 DESCRIPTION 2033 "An instance of this PRC describes one association of an 2034 interface to a role-combination and capability set name . 2035 Note that an interface can have multiple associations. This 2036 constraint is controlled by the extending or referencing 2037 PRC's uniqueness clause." 2039 PIB-INDEX { frwkRoleComboPrid } 2040 UNIQUENESS { } 2042 ::= { frwkRoleComboTable 1 } 2044 FrwkRoleComboEntry ::= SEQUENCE { 2045 frwkRoleComboPrid InstanceId, 2046 frwkRoleComboRoles RoleCombination, 2047 frwkRoleComboCapSetName SnmpAdminString 2048 } 2050 frwkRoleComboPrid OBJECT-TYPE 2051 SYNTAX InstanceId 2052 STATUS current 2054 Framework Policy Information Base May 30, 2002 2056 DESCRIPTION 2057 "An arbitrary integer index that uniquely identifies an 2058 instance of the class." 2060 ::= { frwkRoleComboEntry 1 } 2062 frwkRoleComboRoles OBJECT-TYPE 2063 SYNTAX RoleCombination 2064 STATUS current 2065 DESCRIPTION 2066 "The role combination assigned to a specific interface." 2068 ::= { frwkRoleComboEntry 2 } 2070 frwkRoleComboCapSetName OBJECT-TYPE 2071 SYNTAX SnmpAdminString (SIZE (0..255)) 2072 STATUS current 2073 DESCRIPTION 2074 "The name of the capability set associated with 2075 the Role Combination specified in frwkRoleComboRoles. If 2076 this is a zero length string it implies the PEP is not 2077 exporting any capability set information for this 2078 RoleCombination. The PDP must then use the RoleCombinations 2079 provided as the only means of assigning policies 2080 If a non-zero length string is specified, the name must 2081 exist in frwkCapabilitySetTable." 2083 ::= { frwkRoleComboEntry 3 } 2085 -- 2086 -- Interface, Role Combination association via IfIndex 2087 -- 2089 frwkIfRoleComboTable OBJECT-TYPE 2090 SYNTAX SEQUENCE OF FrwkIfRoleComboEntry 2091 PIB-ACCESS install-notify 2092 STATUS current 2093 DESCRIPTION 2094 "This PRC enumerates the interface to role combination and 2095 frwkRoleComboCapSetName mapping for all policy managed 2096 interfaces of a device. Policy for an interface depends not 2097 only on the capability set of an interface but also on its 2098 roles. This table specifies all the tuples 2100 currently on the device" 2102 ::= { frwkDeviceCapClasses 3 } 2104 frwkIfRoleComboEntry OBJECT-TYPE 2105 SYNTAX FrwkIfRoleComboEntry 2106 STATUS current 2108 Framework Policy Information Base May 30, 2002 2110 DESCRIPTION 2111 "An instance of this PRC describes the association of 2112 a interface to an capability set name and a role 2113 combination. 2114 Note that a capability set name can have multiple role 2115 combinations assigned to it, but an IfIndex can have only 2116 one role combination associated." 2118 EXTENDS { frwkRoleComboEntry } 2119 UNIQUENESS { frwkIfRoleComboIfIndex, 2120 frwkRoleComboCapSetName } 2122 ::= { frwkIfRoleComboTable 1 } 2124 FrwkIfRoleComboEntry ::= SEQUENCE { 2125 frwkIfRoleComboIfIndex InterfaceIndex 2126 } 2128 frwkIfRoleComboIfIndex OBJECT-TYPE 2129 SYNTAX InterfaceIndex 2130 STATUS current 2131 DESCRIPTION 2132 "The value of this attribute is the ifIndex which is 2133 associated with the specified RoleCombination and interface 2134 capability set name." 2136 ::= { frwkIfRoleComboEntry 1 } 2138 -- 2139 -- The Classification classes group 2140 -- 2142 frwkClassifierClasses 2143 OBJECT IDENTIFIER ::= { frameworkPib 3 } 2144 -- 2145 -- The Base Filter Table 2146 -- 2148 frwkBaseFilterTable OBJECT-TYPE 2149 SYNTAX SEQUENCE OF FrwkBaseFilterEntry 2150 PIB-ACCESS install 2151 STATUS current 2152 DESCRIPTION 2153 "The Base Filter class. A packet has to match all 2154 fields in an Filter. Wildcards may be specified for those 2155 fields that are not relevant." 2157 Framework Policy Information Base May 30, 2002 2159 ::= { frwkClassifierClasses 1 } 2161 frwkBaseFilterEntry OBJECT-TYPE 2162 SYNTAX FrwkBaseFilterEntry 2163 STATUS current 2164 DESCRIPTION 2165 "An instance of the frwkBaseFilter class." 2167 PIB-INDEX { frwkBaseFilterPrid } 2169 ::= { frwkBaseFilterTable 1 } 2171 FrwkBaseFilterEntry ::= SEQUENCE { 2172 frwkBaseFilterPrid InstanceId, 2173 frwkBaseFilterNegation TruthValue 2174 } 2176 frwkBaseFilterPrid OBJECT-TYPE 2177 SYNTAX InstanceId 2178 STATUS current 2179 DESCRIPTION 2180 "An integer index to uniquely identify this Filter among all 2181 the Filters." 2183 ::= { frwkBaseFilterEntry 1 } 2185 frwkBaseFilterNegation OBJECT-TYPE 2186 SYNTAX TruthValue 2187 STATUS current 2188 DESCRIPTION 2189 "This attribute behaves like a logical NOT for the filter. 2190 If the packet matches this filter and the value of this 2191 attribute is 'true', the action associated with this filter 2192 is not applied to the packet. If the value of this 2193 attribute is 'false', then the action is applied to the 2194 packet." 2196 ::= { frwkBaseFilterEntry 2 } 2198 -- 2199 -- The IP Filter Table 2200 -- 2202 frwkIpFilterTable OBJECT-TYPE 2203 SYNTAX SEQUENCE OF FrwkIpFilterEntry 2204 PIB-ACCESS install 2205 STATUS current 2206 DESCRIPTION 2207 "Filter definitions. A packet has to match all fields in a 2209 Framework Policy Information Base May 30, 2002 2211 filter. Wildcards may be specified for those fields that 2212 are not relevant." 2214 INSTALL-ERRORS { 2215 invalidDstL4PortData(1), 2216 invalidSrcL4PortData(2) 2217 } 2218 ::= { frwkClassifierClasses 2 } 2220 frwkIpFilterEntry OBJECT-TYPE 2221 SYNTAX FrwkIpFilterEntry 2222 STATUS current 2223 DESCRIPTION 2224 "An instance of the frwkIpFilter class." 2226 EXTENDS { frwkBaseFilterEntry } 2227 UNIQUENESS { frwkBaseFilterNegation, 2228 frwkIpFilterAddrType, 2229 frwkIpFilterDstAddr, 2230 frwkIpFilterDstPrefixLength, 2231 frwkIpFilterSrcAddr, 2232 frwkIpFilterSrcPrefixLength, 2233 frwkIpFilterDscp, 2234 frwkIpFilterFlowId, 2235 frwkIpFilterProtocol, 2236 frwkIpFilterDstL4PortMin, 2237 frwkIpFilterDstL4PortMax, 2238 frwkIpFilterSrcL4PortMin, 2239 frwkIpFilterSrcL4PortMax } 2241 ::= { frwkIpFilterTable 1 } 2243 FrwkIpFilterEntry ::= SEQUENCE { 2244 frwkIpFilterAddrType InetAddressType, 2245 frwkIpFilterDstAddr InetAddress, 2246 frwkIpFilterDstPrefixLength InetAddressPrefixLength, 2247 frwkIpFilterSrcAddr InetAddress, 2248 frwkIpFilterSrcPrefixLength InetAddressPrefixLength, 2249 frwkIpFilterDscp DscpOrAny, 2250 frwkIpFilterFlowId Unsigned32, 2251 frwkIpFilterProtocol Integer32, 2252 frwkIpFilterDstL4PortMin InetPortNumber, 2253 frwkIpFilterDstL4PortMax InetPortNumber, 2254 frwkIpFilterSrcL4PortMin InetPortNumber, 2255 frwkIpFilterSrcL4PortMax InetPortNumber 2256 } 2258 frwkIpFilterAddrType OBJECT-TYPE 2260 SYNTAX InetAddressType 2261 STATUS current 2262 DESCRIPTION 2264 Framework Policy Information Base May 30, 2002 2266 "The address type enumeration value to specify the type of 2267 the packet's IP address. 2269 While other types of addresses are defined in the 2270 InetAddressType textual convention, an IP filter can only 2271 use IPv4 and IPv6 addresses directly to classify traffic. 2272 All other InetAddressTypes require mapping to the 2273 corresponding Ipv4 or IPv6 address before being used to 2274 classify traffic. Therefore, this object as such is not 2275 limited to IPv4 and IPv6 addresses, i.e., it can be assigned 2276 any of the valid values defined in the InetAddressType TC, 2277 but the mapping of the address values to IPv4 or IPv6 2278 addresses for the address attributes (frwkIpFilterDstAddr 2279 and frwkIpFilterSrcAddr) must be done by the PEP." 2280 REFERENCE 2281 "Textual Conventions for Internet Network Addresses. 2282 [INETADDR]" 2284 ::= { frwkIpFilterEntry 1 } 2286 frwkIpFilterDstAddr OBJECT-TYPE 2288 SYNTAX InetAddress 2289 STATUS current 2290 DESCRIPTION 2291 "The IP address to match against the packet's 2292 destination IP address. If the address type is 'ipv4', 2293 'ipv6', 'ipv4z' or 'ipv6z' then, the attribute 2294 frwkIpFilterDstPrefixLength indicates the number of bits 2295 that are relevant. " 2296 REFERENCE 2297 "Textual Conventions for Internet Network Addresses. 2298 [INETADDR]" 2300 ::= { frwkIpFilterEntry 2 } 2302 frwkIpFilterDstPrefixLength OBJECT-TYPE 2303 SYNTAX InetAddressPrefixLength 2304 STATUS current 2305 DESCRIPTION 2306 "The length of a mask for the matching of the destination 2307 IP address. This attribute is interpreted only if the 2308 InetAddressType is 'ipv4', 'ipv4z', 'ipv6' or 'ipv6z'. 2309 Masks are constructed by setting bits in sequence from the 2310 most-significant bit downwards for 2311 frwkIpFilterDstPrefixLength bits length. All other bits in 2312 the mask, up to the number needed to fill the length of 2313 the address frwkIpFilterDstAddr are cleared to zero. A zero 2314 bit in the mask then means that the corresponding bit in 2315 the address always matches. 2317 In IPv4 addresses, a length of 0 indicates a match of any 2318 address; a length of 32 indicates a match of a single host 2320 Framework Policy Information Base May 30, 2002 2322 address, and a length between 0 and 32 indicates the use of 2323 a CIDR Prefix. IPv6 is similar, except that prefix lengths 2324 range from 0..128." 2325 REFERENCE 2326 "Textual Conventions for Internet Network Addresses. 2327 [INETADDR]" 2328 DEFVAL { 0 } 2330 ::= { frwkIpFilterEntry 3 } 2332 frwkIpFilterSrcAddr OBJECT-TYPE 2333 SYNTAX InetAddress 2334 STATUS current 2335 DESCRIPTION 2336 "The IP address to match against the packet's source IP 2337 address. If the address type is 'ipv4', 'ipv6', 'ipv4z' or 2338 'ipv6z' then, the attribute frwkIpFilterSrcPrefixLength 2339 indicates the number of bits that are relevant." 2340 REFERENCE 2341 "Textual Conventions for Internet Network Addresses. 2342 [INETADDR]" 2344 ::= { frwkIpFilterEntry 4 } 2346 frwkIpFilterSrcPrefixLength OBJECT-TYPE 2347 SYNTAX InetAddressPrefixLength 2348 UNITS "bits" 2349 STATUS current 2350 DESCRIPTION 2351 "The length of a mask for the matching of the source IP 2352 address. This attribute is interpreted only if the 2353 InetAddressType is 'ipv4', 'ipv4z', 'ipv6' or 'ipv6z'. 2354 Masks are constructed by setting bits in sequence from the 2355 most-significant bit downwards for 2356 frwkIpFilterSrcPrefixLength bits length. All other bits in 2357 the mask, up to the number needed to fill the length of 2358 the address frwkIpFilterSrcAddr are cleared to zero. A 2359 zero bit in the mask then means that the corresponding bit 2360 in the address always matches. 2362 In IPv4 addresses, a length of 0 indicates a match of any 2363 address; a length of 32 indicates a match of a single host 2364 address, and a length between 0 and 32 indicates the use of 2365 a CIDR Prefix. IPv6 is similar, except that prefix lengths 2366 range from 0..128." 2367 REFERENCE 2368 "Textual Conventions for Internet Network Addresses. 2369 [INETADDR]" 2370 DEFVAL { 0 } 2372 ::= { frwkIpFilterEntry 5 } 2374 Framework Policy Information Base May 30, 2002 2376 frwkIpFilterDscp OBJECT-TYPE 2377 SYNTAX DscpOrAny 2378 STATUS current 2379 DESCRIPTION 2380 "The value that the DSCP in the packet can have and 2381 match this filter. A value of -1 indicates that a specific 2382 DSCP value has not been defined and thus all DSCP values 2383 are considered a match." 2384 REFERENCE 2385 "[DS-MIB]." 2386 DEFVAL { -1 } 2388 ::= { frwkIpFilterEntry 6 } 2390 frwkIpFilterFlowId OBJECT-TYPE 2391 SYNTAX Unsigned32 (0..1048575) 2392 STATUS current 2393 DESCRIPTION 2394 "The flow identifier in an IPv6 header." 2395 ::= { frwkIpFilterEntry 7 } 2397 frwkIpFilterProtocol OBJECT-TYPE 2398 SYNTAX Integer32 (-1 | 0..255) 2399 STATUS current 2400 DESCRIPTION 2401 "The layer-4 protocol Id to match against the IPv4 protocol 2402 number or the IPv6 Next-Header number in the packet. A value 2403 of -1 means match all. Note the protocol number of 255 is 2404 reserved by IANA, and Next-Header number of 0 is used in 2405 IPv6." 2406 DEFVAL { -1 } 2408 ::= { frwkIpFilterEntry 8 } 2410 frwkIpFilterDstL4PortMin OBJECT-TYPE 2411 SYNTAX InetPortNumber 2412 STATUS current 2413 DESCRIPTION 2414 "The minimum value that the packet's layer 4 destination 2415 port number can have and match this filter. This value must 2416 be equal to or lesser that the value specified for this 2417 filter in frwkIpFilterDstL4PortMax. 2419 COPS-PR error code 'attrValueInvalid' must be returned if 2420 the frwkIpFilterDstL4PortMin is greater than 2421 frwkIpFilterDstL4PortMax" 2422 REFERENCE "[COPS-PR] error codes section 4.5." 2423 DEFVAL { 0 } 2425 ::= { frwkIpFilterEntry 9 } 2427 frwkIpFilterDstL4PortMax OBJECT-TYPE 2429 Framework Policy Information Base May 30, 2002 2431 SYNTAX InetPortNumber 2432 STATUS current 2433 DESCRIPTION 2434 "The maximum value that the packet's layer 4 destination 2435 port number can have and match this filter. This value must 2436 be equal to or greater that the value specified for this 2437 filter in frwkIpFilterDstL4PortMin. 2439 COPS-PR error code 'attrValueInvalid' must be returned if 2440 the frwkIpFilterDstL4PortMax is less than 2441 frwkIpFilterDstL4PortMin" 2442 REFERENCE "[COPS-PR] error codes section 4.5." 2443 DEFVAL { 65535 } 2445 ::= { frwkIpFilterEntry 10 } 2447 frwkIpFilterSrcL4PortMin OBJECT-TYPE 2448 SYNTAX InetPortNumber 2449 STATUS current 2450 DESCRIPTION 2451 "The minimum value that the packet's layer 4 source port 2452 number can have and match this filter. This value must 2453 be equal to or lesser that the value specified for this 2454 filter in frwkIpFilterSrcL4PortMax. 2456 COPS-PR error code 'attrValueInvalid' must be returned if 2457 the frwkIpFilterSrcL4PortMin is greated than 2458 frwkIpFilterSrcL4PortMax" 2459 REFERENCE "[COPS-PR] error codes section 4.5." 2460 DEFVAL { 0 } 2462 ::= { frwkIpFilterEntry 11 } 2464 frwkIpFilterSrcL4PortMax OBJECT-TYPE 2465 SYNTAX InetPortNumber 2466 STATUS current 2467 DESCRIPTION 2468 "The maximum value that the packet's layer 4 source port 2469 number can have and match this filter. This value must be 2470 equal to or greater that the value specified for this filter 2471 in frwkIpFilterSrcL4PortMin. 2473 COPS-PR error code 'attrValueInvalid' must be returned if 2474 the frwkIpFilterSrcL4PortMax is less than 2475 frwkIpFilterSrcL4PortMin" 2476 REFERENCE "[COPS-PR] error codes section 4.5." 2477 DEFVAL { 65535 } 2479 ::= { frwkIpFilterEntry 12 } 2481 Framework Policy Information Base May 30, 2002 2483 -- 2484 -- The IEEE 802 Filter Table 2485 -- 2487 frwk802FilterTable OBJECT-TYPE 2488 SYNTAX SEQUENCE OF Frwk802FilterEntry 2489 PIB-ACCESS install 2490 STATUS current 2491 DESCRIPTION 2492 "IEEE 802-based filter definitions. A class that contains 2493 attributes of IEEE 802 (e.g., 802.3) traffic that form 2494 filters that are used to perform traffic classification." 2495 REFERENCE 2496 "IEEE Standards for Local and Metropolitan Area Networks. 2497 [802]" 2498 ::= { frwkClassifierClasses 3 } 2500 frwk802FilterEntry OBJECT-TYPE 2501 SYNTAX Frwk802FilterEntry 2502 STATUS current 2503 DESCRIPTION 2504 "IEEE 802-based filter definitions. An entry specifies 2505 (potentially) several distinct matching components. Each 2506 component is tested against the data in a frame 2507 individually. An overall match occurs when all of the 2508 individual components match the data they are compared 2509 against in the frame being processed. A failure of any 2510 one test causes the overall match to fail. 2512 Wildcards may be specified for those fields that are not 2513 relevant." 2515 EXTENDS { frwkBaseFilterEntry } 2516 UNIQUENESS { frwkBaseFilterNegation, 2517 frwk802FilterDstAddr, 2518 frwk802FilterDstAddrMask, 2519 frwk802FilterSrcAddr, 2520 frwk802FilterSrcAddrMask, 2521 frwk802FilterVlanId, 2522 frwk802FilterVlanTagRequired, 2523 frwk802FilterEtherType, 2524 frwk802FilterUserPriority } 2526 ::= { frwk802FilterTable 1 } 2528 Frwk802FilterEntry ::= SEQUENCE { 2529 frwk802FilterDstAddr PhysAddress, 2530 frwk802FilterDstAddrMask PhysAddress, 2532 Framework Policy Information Base May 30, 2002 2534 frwk802FilterSrcAddr PhysAddress, 2535 frwk802FilterSrcAddrMask PhysAddress, 2536 frwk802FilterVlanId Integer32, 2537 frwk802FilterVlanTagRequired INTEGER, 2538 frwk802FilterEtherType Integer32, 2539 frwk802FilterUserPriority BITS 2540 } 2542 frwk802FilterDstAddr OBJECT-TYPE 2543 SYNTAX PhysAddress 2544 STATUS current 2546 DESCRIPTION 2547 "The 802 address against which the 802 DA of incoming 2548 traffic streams will be compared. Frames whose 802 DA 2549 matches the physical address specified by this object, 2550 taking into account address wildcarding as specified by the 2551 frwk802FilterDstAddrMask object, are potentially subject to 2552 the processing guidelines that are associated with this 2553 entry through the related action class." 2554 REFERENCE 2555 "[SMNPv2TC]." 2557 ::= { frwk802FilterEntry 1 } 2559 frwk802FilterDstAddrMask OBJECT-TYPE 2560 SYNTAX PhysAddress 2561 STATUS current 2562 DESCRIPTION 2563 "This object specifies the bits in a 802 destination address 2564 that should be considered when performing a 802 DA 2565 comparison against the address specified in the 2566 frwk802FilterDstAddr object. 2568 The value of this object represents a mask that is logically 2569 and'ed with the 802 DA in received frames to derive the 2570 value to be compared against the frwk802FilterDstAddr 2571 address. A zero bit in the mask thus means that the 2572 corresponding bit in the address always matches. The 2573 frwk802FilterDstAddr value must also be masked using this 2574 value prior to any comparisons. 2576 The length of this object in octets must equal the length in 2577 octets of the frwk802FilterDstAddr. Note that a mask with no 2578 bits set (i.e., all zeroes) effectively wildcards the 2579 frwk802FilterDstAddr object." 2581 ::= { frwk802FilterEntry 2 } 2583 frwk802FilterSrcAddr OBJECT-TYPE 2584 SYNTAX PhysAddress 2586 Framework Policy Information Base May 30, 2002 2588 STATUS current 2589 DESCRIPTION 2590 "The 802 MAC address against which the 802 MAC SA of 2591 incoming traffic streams will be compared. Frames whose 802 2592 MAC SA matches the physical address specified by this 2593 object, taking into account address wildcarding as specified 2594 by the frwk802FilterSrcAddrMask object, are potentially 2595 subject to the processing guidelines that are associated 2596 with this entry through the related action class." 2598 ::= { frwk802FilterEntry 3 } 2600 frwk802FilterSrcAddrMask OBJECT-TYPE 2601 SYNTAX PhysAddress 2602 STATUS current 2603 DESCRIPTION 2604 "This object specifies the bits in a 802 MAC source address 2605 that should be considered when performing a 802 MAC SA 2606 comparison against the address specified in the 2607 frwk802FilterSrcAddr object. 2609 The value of this object represents a mask that is logically 2610 and'ed with the 802 MAC SA in received frames to derive the 2611 value to be compared against the frwk802FilterSrcAddr 2612 address. A zero bit in the mask thus means that the 2613 corresponding bit in the address always matches. The 2614 frwk802FilterSrcAddr value must also be masked using this 2615 value prior to any comparisons. 2617 The length of this object in octets must equal the length in 2618 octets of the frwk802FilterSrcAddr. Note that a mask with no 2619 bits set (i.e., all zeroes) effectively wildcards the 2620 frwk802FilterSrcAddr object." 2622 ::= { frwk802FilterEntry 4 } 2624 frwk802FilterVlanId OBJECT-TYPE 2625 SYNTAX Integer32 (-1 | 1..4094) 2626 STATUS current 2627 DESCRIPTION 2628 "The VLAN ID (VID) that uniquely identifies a VLAN 2629 within the device. This VLAN may be known or unknown 2630 (i.e., traffic associated with this VID has not yet 2631 been seen by the device) at the time this entry 2632 is instantiated. 2634 Setting the frwk802FilterVlanId object to -1 indicates that 2635 VLAN data should not be considered during traffic 2636 classification." 2638 ::= { frwk802FilterEntry 5 } 2640 frwk802FilterVlanTagRequired OBJECT-TYPE 2641 SYNTAX INTEGER { 2643 Framework Policy Information Base May 30, 2002 2645 taggedOnly(1), 2646 priorityTaggedPlus(2), 2647 untaggedOnly(3), 2648 ignoreTag(4) 2649 } 2650 STATUS current 2651 DESCRIPTION 2652 "This object indicates whether the presence of an 2653 IEEE 802.1Q VLAN tag in data link layer frames must 2654 be considered when determining if a given frame 2655 matches this 802 filter entry. 2657 A value of 'taggedOnly(1)' means that only frames 2658 containing a VLAN tag with a non-Null VID (i.e., a 2659 VID in the range 1..4094) will be considered a match. 2661 A value of 'priorityTaggedPlus(2)' means that only 2662 frames containing a VLAN tag, regardless of the value 2663 of the VID, will be considered a match. 2665 A value of 'untaggedOnly(3)' indicates that only 2666 untagged frames will match this filter component. 2668 The presence of a VLAN tag is not taken into 2669 consideration in terms of a match if the value is 2670 'ignoreTag(4)'." 2672 ::= { frwk802FilterEntry 6 } 2674 frwk802FilterEtherType OBJECT-TYPE 2675 SYNTAX Integer32 (-1 | 0..'ffff'h) 2676 STATUS current 2677 DESCRIPTION 2678 "This object specifies the value that will be compared 2679 against the value contained in the EtherType field of an 2680 IEEE 802 frame. Example settings would include 'IP' 2681 (0x0800), 'ARP' (0x0806) and 'IPX' (0x8137). 2683 Setting the frwk802FilterEtherTypeMin object to -1 indicates 2684 that EtherType data should not be considered during traffic 2685 classification. 2687 Note that the position of the EtherType field depends on 2688 the underlying frame format. For Ethernet-II encapsulation, 2689 the EtherType field follows the 802 MAC source address. For 2690 802.2 LLC/SNAP encapsulation, the EtherType value follows 2691 the Organization Code field in the 802.2 SNAP header. The 2692 value that is tested with regard to this filter component 2693 therefore depends on the data link layer frame format being 2694 used. If this 802 filter component is active when there is 2695 no EtherType field in a frame (e.g., 802.2 LLC), a match is 2696 implied." 2698 Framework Policy Information Base May 30, 2002 2700 ::= { frwk802FilterEntry 7 } 2702 frwk802FilterUserPriority OBJECT-TYPE 2703 SYNTAX BITS { 2704 matchPriority0(0), 2705 matchPriority1(1), 2706 matchPriority2(2), 2707 matchPriority3(3), 2708 matchPriority4(4), 2709 matchPriority5(5), 2710 matchPriority6(6), 2711 matchPriority7(7) 2712 } 2713 STATUS current 2714 DESCRIPTION 2715 "The set of values, representing the potential range 2716 of user priority values, against which the value contained 2717 in the user priority field of a tagged 802.1 frame is 2718 compared. A test for equality is performed when determining 2719 if a match exists between the data in a data link layer 2720 frame and the value of this 802 filter component. Multiple 2721 values may be set at one time such that potentially several 2722 different user priority values may match this 802 filter 2723 component. 2725 Setting all of the bits that are associated with this 2726 object causes all user priority values to match this 2727 attribute. This essentially makes any comparisons 2728 with regard to user priority values unnecessary. Untagged 2729 frames are treated as an implicit match." 2731 ::= { frwk802FilterEntry 8 } 2733 -- 2734 -- The Internal label filter extension 2735 -- 2737 frwkILabelFilterTable OBJECT-TYPE 2738 SYNTAX SEQUENCE OF FrwkILabelFilterEntry 2739 PIB-ACCESS install 2740 STATUS current 2741 DESCRIPTION 2742 "Internal label filter Table. This PRC is used to achieve 2743 classification based on the internal flow label set by the 2744 PEP possibly after ingress classification to avoid 2745 re-classification at the egress interface on the same PEP." 2747 ::= { frwkClassifierClasses 4 } 2749 frwkILabelFilterEntry OBJECT-TYPE 2750 SYNTAX FrwkILabelFilterEntry 2751 STATUS current 2752 DESCRIPTION 2754 Framework Policy Information Base May 30, 2002 2756 "Internal label filter entry definition." 2758 EXTENDS { frwkBaseFilterEntry } 2759 UNIQUENESS { frwkBaseFilterNegation, 2760 frwkILabelFilterILabel } 2762 ::= { frwkILabelFilterTable 1 } 2764 FrwkILabelFilterEntry ::= SEQUENCE { 2765 frwkILabelFilterILabel OCTET STRING 2766 } 2768 frwkILabelFilterILabel OBJECT-TYPE 2769 SYNTAX OCTET STRING 2770 STATUS current 2771 DESCRIPTION 2772 "The Label that this flow uses for differentiating traffic 2773 flows. The flow labeling is meant for network device 2774 internal usage. A value of zero length string matches all 2775 internal labels." 2776 ::= { frwkILabelFilterEntry 1 } 2778 -- 2779 -- The Marker classes group 2780 -- 2782 frwkMarkerClasses 2783 OBJECT IDENTIFIER ::= { frameworkPib 4 } 2784 -- 2785 -- The 802 Marker Table 2786 -- 2788 frwk802MarkerTable OBJECT-TYPE 2789 SYNTAX SEQUENCE OF Frwk802MarkerEntry 2790 PIB-ACCESS install 2791 STATUS current 2792 DESCRIPTION 2793 "The 802 Marker class. An 802 packet can be marked with the 2794 specified VLAN id, priority level." 2796 ::= { frwkMarkerClasses 1 } 2798 frwk802MarkerEntry OBJECT-TYPE 2799 SYNTAX Frwk802MarkerEntry 2800 STATUS current 2801 DESCRIPTION 2802 "frwk802Marker entry definition." 2804 Framework Policy Information Base May 30, 2002 2806 PIB-INDEX { frwk802MarkerPrid } 2807 UNIQUENESS { frwk802MarkerVlanId, 2808 frwk802MarkerPriority } 2810 ::= { frwk802MarkerTable 1 } 2812 Frwk802MarkerEntry::= SEQUENCE { 2813 frwk802MarkerPrid InstanceId, 2814 frwk802MarkerVlanId Unsigned32, 2815 frwk802MarkerPriority Unsigned32 2816 } 2818 frwk802MarkerPrid OBJECT-TYPE 2819 SYNTAX InstanceId 2820 STATUS current 2821 DESCRIPTION 2822 "An integer index to uniquely identify this 802 Marker." 2824 ::= { frwk802MarkerEntry 1 } 2826 frwk802MarkerVlanId OBJECT-TYPE 2827 SYNTAX Unsigned32 (1..4094) 2828 STATUS current 2829 DESCRIPTION 2830 "The VLAN ID (VID) that uniquely identifies a VLAN within 2831 the device." 2833 ::= { frwk802MarkerEntry 2 } 2835 frwk802MarkerPriority OBJECT-TYPE 2836 SYNTAX Unsigned32 (0..7) 2837 STATUS current 2838 DESCRIPTION 2839 "The user priority field of a tagged 802.1 frame." 2841 ::= { frwk802MarkerEntry 3 } 2843 -- 2844 -- The Internal Label Marker Table 2845 -- 2847 frwkILabelMarkerTable OBJECT-TYPE 2848 SYNTAX SEQUENCE OF FrwkILabelMarkerEntry 2849 PIB-ACCESS install 2850 STATUS current 2851 DESCRIPTION 2852 "The Internal Label Marker class. A flow in a PEP can be 2853 marked with an internal label using this PRC." 2855 ::= { frwkMarkerClasses 2 } 2857 Framework Policy Information Base May 30, 2002 2859 frwkILabelMarkerEntry OBJECT-TYPE 2860 SYNTAX FrwkILabelMarkerEntry 2861 STATUS current 2862 DESCRIPTION 2863 "frwkILabelkMarker entry definition." 2865 PIB-INDEX { frwkILabelMarkerPrid } 2866 UNIQUENESS { frwkILabelMarkerILabel } 2868 ::= { frwkILabelMarkerTable 1 } 2870 FrwkILabelMarkerEntry::= SEQUENCE { 2871 frwkILabelMarkerPrid InstanceId, 2872 frwkILabelMarkerILabel OCTET STRING 2873 } 2875 frwkILabelMarkerPrid OBJECT-TYPE 2876 SYNTAX InstanceId 2877 STATUS current 2878 DESCRIPTION 2879 "An integer index to uniquely identify this Label Marker." 2881 ::= { frwkILabelMarkerEntry 1 } 2883 frwkILabelMarkerILabel OBJECT-TYPE 2884 SYNTAX OCTET STRING 2885 STATUS current 2886 DESCRIPTION 2887 "This internal label is implementation specific and may be 2888 used for other policy related functions like flow 2889 accounting purposes and/or other data path treatments." 2891 ::= { frwkILabelMarkerEntry 2 } 2893 -- 2894 -- Conformance Section 2895 -- 2897 frwkBasePibConformance 2898 OBJECT IDENTIFIER ::= { frameworkPib 5 } 2900 frwkBasePibCompliances 2901 OBJECT IDENTIFIER ::= { frwkBasePibConformance 1 } 2903 frwkBasePibGroups 2904 OBJECT IDENTIFIER ::= { frwkBasePibConformance 2 } 2906 Framework Policy Information Base May 30, 2002 2908 frwkBasePibCompliance MODULE-COMPLIANCE 2909 STATUS current 2910 DESCRIPTION 2911 "Describes the requirements for conformance to the 2912 Framework PIB." 2914 MODULE -- this module 2915 MANDATORY-GROUPS { frwkPrcSupportGroup, 2916 frwkPibIncarnationGroup, 2917 frwkDeviceIdGroup, 2918 frwkCompLimitsGroup, 2919 frwkCapabilitySetGroup, 2920 frwkRoleComboGroup, 2921 frwkIfRoleComboGroup } 2923 OBJECT frwkPibIncarnationLongevity 2924 PIB-MIN-ACCESS notify 2925 DESCRIPTION 2926 "Install support is required if policy expiration is to 2927 be supported." 2929 OBJECT frwkPibIncarnationTtl 2930 PIB-MIN-ACCESS notify 2931 DESCRIPTION 2932 "Install support is required if policy expiration is to 2933 be supported." 2935 OBJECT frwkPibIncarnationInCtxtSet 2936 PIB-MIN-ACCESS notify 2937 DESCRIPTION 2938 "Install support is required if configuration contexts 2939 and outsourcing contexts are both to be supported." 2941 OBJECT frwkPibIncarnationFullState 2942 PIB-MIN-ACCESS notify 2943 DESCRIPTION 2944 "Install support is required if incremental updates to 2945 request states is to be supported." 2947 GROUP frwkReferenceGroup 2948 DESCRIPTION 2949 "The frwkReferenceGroup is mandatory if referencing 2950 across PIB contexts for specific client-types is to be 2951 supported." 2953 GROUP frwkErrorGroup 2954 DESCRIPTION 2955 "The frwkErrorGroup is mandatory sending errors in 2956 decisions is to be supported." 2958 GROUP frwkBaseFilterGroup 2959 DESCRIPTION 2960 "The frwkBaseFilterGroup is mandatory if filtering 2961 based on traffic components is to be supported." 2963 Framework Policy Information Base May 30, 2002 2965 GROUP frwkIpFilterGroup 2966 DESCRIPTION 2967 "The frwkIpFilterGroup is mandatory if filtering 2968 based on IP traffic components is to be supported." 2970 GROUP frwk802FilterGroup 2971 DESCRIPTION 2972 "The frwk802FilterGroup is mandatory if filtering 2973 based on 802 traffic criteria is to be supported." 2975 GROUP frwkILabelFilterGroup 2976 DESCRIPTION 2977 "The frwkILabelFilterGroup is mandatory if filtering 2978 based on PEP internal label is to be supported." 2980 GROUP frwk802MarkerGroup 2981 DESCRIPTION 2982 "The frwk802MarkerGroup is mandatory if marking a packet 2983 with 802 traffic criteria is to be supported." 2985 GROUP frwkILabelMarkerGroup 2986 DESCRIPTION 2987 "The frwkILabelMarkerGroup is mandatory if marking a 2988 flow with internal labels is to be supported." 2990 ::= { frwkBasePibCompliances 1 } 2992 frwkPrcSupportGroup OBJECT-GROUP 2993 OBJECTS { 2994 frwkPrcSupportSupportedPrc, 2995 frwkPrcSupportSupportedAttrs } 2996 STATUS current 2997 DESCRIPTION 2998 "Objects from the frwkPrcSupportTable." 3000 ::= { frwkBasePibGroups 1 } 3002 frwkPibIncarnationGroup OBJECT-GROUP 3003 OBJECTS { 3004 frwkPibIncarnationName, 3005 frwkPibIncarnationId, 3006 frwkPibIncarnationLongevity, 3007 frwkPibIncarnationTtl, 3008 frwkPibIncarnationActive, 3009 frwkPibIncarnationFullState 3010 } 3011 STATUS current 3012 DESCRIPTION 3013 "Objects from the frwkDevicePibIncarnationTable." 3015 ::= { frwkBasePibGroups 2 } 3017 Framework Policy Information Base May 30, 2002 3019 frwkDeviceIdGroup OBJECT-GROUP 3020 OBJECTS { 3021 frwkDeviceIdDescr, 3022 frwkDeviceIdMaxMsg, 3023 frwkDeviceIdMaxContexts } 3024 STATUS current 3025 DESCRIPTION 3026 "Objects from the frwkDeviceIdTable." 3028 ::= { frwkBasePibGroups 3 } 3030 frwkCompLimitsGroup OBJECT-GROUP 3031 OBJECTS { 3032 frwkCompLimitsComponent, 3033 frwkCompLimitsAttrPos, 3034 frwkCompLimitsNegation, 3035 frwkCompLimitsType, 3036 frwkCompLimitsSubType, 3037 frwkCompLimitsGuidance } 3038 STATUS current 3039 DESCRIPTION 3040 "Objects from the frwkCompLimitsTable." 3042 ::= { frwkBasePibGroups 4 } 3044 frwkReferenceGroup OBJECT-GROUP 3045 OBJECTS { 3046 frwkReferenceClientType, 3047 frwkReferenceClientHandle, 3048 frwkReferencePrid } 3049 STATUS current 3050 DESCRIPTION 3051 "Objects from the frwkReferenceTable." 3053 ::= { frwkBasePibGroups 5 } 3055 frwkErrorGroup OBJECT-GROUP 3056 OBJECTS { 3057 frwkErrorCode, 3058 frwkErrorSubCode, 3059 frwkErrorPrc, 3060 frwkErrorInstance } 3061 STATUS current 3062 DESCRIPTION 3063 "Objects from the frwkErrorTable." 3065 ::= { frwkBasePibGroups 6 } 3067 frwkCapabilitySetGroup OBJECT-GROUP 3068 OBJECTS { 3069 frwkCapabilitySetName, 3070 frwkCapabilitySetCapability } 3071 STATUS current 3073 Framework Policy Information Base May 30, 2002 3075 DESCRIPTION 3076 "Objects from the frwkCapabilitySetTable." 3078 ::= { frwkBasePibGroups 7 } 3080 frwkRoleComboGroup OBJECT-GROUP 3081 OBJECTS { 3082 frwkRoleComboRoles, 3083 frwkRoleComboCapSetName } 3084 STATUS current 3085 DESCRIPTION 3086 "Objects from the frwkRoleComboTable." 3088 ::= { frwkBasePibGroups 8 } 3090 frwkIfRoleComboGroup OBJECT-GROUP 3091 OBJECTS { 3092 frwkIfRoleComboIfIndex } 3093 STATUS current 3094 DESCRIPTION 3095 "Objects from the frwkIfRoleComboTable." 3097 ::= { frwkBasePibGroups 9 } 3099 frwkBaseFilterGroup OBJECT-GROUP 3100 OBJECTS { 3101 frwkBaseFilterNegation } 3102 STATUS current 3103 DESCRIPTION 3104 "Objects from the frwkBaseFilterTable." 3106 ::= { frwkBasePibGroups 10 } 3108 frwkIpFilterGroup OBJECT-GROUP 3109 OBJECTS { 3110 frwkIpFilterAddrType, 3111 frwkIpFilterDstAddr, 3112 frwkIpFilterDstPrefixLength, 3113 frwkIpFilterSrcAddr, 3114 frwkIpFilterSrcPrefixLength, 3115 frwkIpFilterDscp, 3116 frwkIpFilterFlowId, 3117 frwkIpFilterProtocol, 3118 frwkIpFilterDstL4PortMin, 3119 frwkIpFilterDstL4PortMax, 3120 frwkIpFilterSrcL4PortMin, 3121 frwkIpFilterSrcL4PortMax } 3122 STATUS current 3123 DESCRIPTION 3124 "Objects from the frwkIpFilterTable." 3126 Framework Policy Information Base May 30, 2002 3128 ::= { frwkBasePibGroups 11 } 3130 frwk802FilterGroup OBJECT-GROUP 3131 OBJECTS { 3132 frwk802FilterDstAddr, 3133 frwk802FilterDstAddrMask, 3134 frwk802FilterSrcAddr, 3135 frwk802FilterSrcAddrMask, 3136 frwk802FilterVlanId, 3137 frwk802FilterVlanTagRequired, 3138 frwk802FilterEtherType, 3139 frwk802FilterUserPriority } 3140 STATUS current 3141 DESCRIPTION 3142 "Objects from the frwk802FilterTable." 3144 ::= { frwkBasePibGroups 12 } 3146 frwkILabelFilterGroup OBJECT-GROUP 3147 OBJECTS { frwkILabelFilterILabel } 3148 STATUS current 3149 DESCRIPTION 3150 "Objects from the frwkILabelFilterTable." 3152 ::= { frwkBasePibGroups 13 } 3154 frwk802MarkerGroup OBJECT-GROUP 3155 OBJECTS { 3156 frwk802MarkerVlanId, 3157 frwk802MarkerPriority } 3158 STATUS current 3159 DESCRIPTION 3160 "Objects from the frwk802MarkerTable." 3162 ::= { frwkBasePibGroups 14 } 3164 frwkILabelMarkerGroup OBJECT-GROUP 3165 OBJECTS { frwkILabelMarkerILabel } 3166 STATUS current 3167 DESCRIPTION 3168 "Objects from the frwkILabelMarkerTable." 3170 ::= { frwkBasePibGroups 15 } 3172 END 3174 Framework Policy Information Base May 30, 2002 3176 6. Security Considerations 3178 It is clear that this PIB is used for configuration using [COPS-PR], 3179 and anything that can be configured can be misconfigured, with 3180 potentially disastrous effect. At this writing, no security holes 3181 have been identified beyond those that the COPS base protocol 3182 security is itself intended to address. These relate primarily to 3183 controlled access to sensitive information and the ability to 3184 configure a device - or which might result from operator error, 3185 which is beyond the scope of any security architecture. 3187 There are a number of PRovisioning Classes defined in this PIB that 3188 have a PIB-ACCESS clause of install and install-notify (read- 3189 create). These are: 3191 frwkPibIncarnationTable: Malicious access of this PRC can cause the 3192 PEP to use an incorrect context of policies. 3193 frwkReferenceTable: Malicious access of this PRC can cause the PEP 3194 to interpret the installed policy in an incorrect manner. 3195 frwkErrorTable: Malicious access of this PRC can cause the PEP to 3196 incorrectly assume that the PDP could not process its messages. 3197 FrwkCapabilitySetTable, frwkRoleComboTable and frwkIfRoleComboTable: 3198 Malicious access of these PRCs can cause the PEP to apply policies 3199 to the wrong interfaces. 3200 FrwkBaseFilterTable, frwkIpFilterTable, frwk802FilterTable and 3201 frwkILabelFilterTable: Malicious access of these PRCs can cause 3202 unintended classification of traffic on the PEP potentially leading 3203 to incorrect policies being applied. 3204 frwk802MarkerTable, frwkILabelMarkerTable: Malicious access of these 3205 PRCs can cause unintended marking of traffic on the PEP potentially 3206 leading to incorrect policies being applied. 3208 Such objects may be considered sensitive or vulnerable in some 3209 network environments. The support for "Install" or "Install-Notify" 3210 decisions sent over [COPS-PR] in a non-secure environment without 3211 proper protection can have a negative effect on network operations. 3212 There are a number of PRovisioning Classes in this PIB that may 3213 contain information that may be sensitive from a business 3214 perspective, in that they may represent a customer's service 3215 contract or the filters that the service provider chooses to apply 3216 to a customer's ingress or egress traffic. There are no PRCs that 3217 are sensitive in their own right, such as passwords or monetary 3218 amounts. It may be important to control even "Notify"(read-only) 3219 access to these PRCs and possibly to even encrypt the values of 3220 these PRIs when sending them over the network via COPS-PR. The use 3221 of IPSEC between the PDP and the PEP, as described in [COPS], 3222 provides the necessary protection against security threats. However, 3223 even if the network itself is secure, there is no control as to who 3224 on the secure network is allowed to "Install/Notify" 3225 (read/change/create/delete) the PRIs in this PIB. 3227 Framework Policy Information Base May 30, 2002 3229 It is then a customer/user responsibility to ensure that the PEP/PDP 3230 giving access to an instance of this PIB, is properly configured to 3231 give access to the PRIs only to those principals (users) that have 3232 legitimate rights to indeed "Install" or "Notify" (change/create/ 3233 delete) them. 3235 7. RFC Editor Considerations 3237 This document normatively references [INETADDR] and [DS-MIB] which 3238 are in the IESG last call stage. Please use the corresponding RFC 3239 numbers prior to publishing of this document as a RFC. 3241 8. IANA Considerations 3243 This document describes the frameworkPib and frwkTcPib Policy 3244 Information Base (PIB) modules for standardization under the "pib" 3245 branch registered with IANA. An IANA assigned PIB number is 3246 requested for both under the "pib" branch. 3248 Both these PIBs use "all" in the SUBJECT-CATEGORIES clause, i.e., 3249 they apply to all COPS client types. No new COPS client type is to 3250 be registered for these two PIB modules. 3252 9. Author Information and Acknowledgments 3254 Michael Fine 3255 Atheros Communications 3256 529 Almanor Ave 3257 Sunnyvale, CA 94085 USA 3258 Phone: +1 408 773 5324 3259 Email: mfine@atheros.com 3261 Keith McCloghrie 3262 Cisco Systems, Inc. 3263 170 West Tasman Drive 3264 San Jose, CA 95134-1706 USA 3265 Phone: +1 408 526 5260 3266 Email: kzm@cisco.com 3268 John Seligson 3269 Nortel Networks, Inc. 3270 4401 Great America Parkway 3271 Santa Clara, CA 95054 USA 3272 Phone: +1 408 495 2992 3273 Email: jseligso@nortelnetworks.com 3275 Kwok Ho Chan 3276 Nortel Networks, Inc. 3277 600 Technology Park Drive 3278 Billerica, MA 01821 USA 3280 Framework Policy Information Base May 30, 2002 3282 Phone: +1 978 288 8175 3283 Email: khchan@nortelnetworks.com 3285 Ravi Sahita 3286 Intel Labs. 3287 2111 NE 25th Avenue 3288 Hillsboro, OR 97124 USA 3289 Phone: +1 503 712 1554 3290 Email: ravi.sahita@intel.com 3292 Scott Hahn 3293 Intel Labs. 3294 2111 NE 25th Avenue 3295 Hillsboro, OR 97124 USA 3296 Phone: +1 503 264 8231 3297 Email: scott.hahn@intel.com 3299 Andrew Smith 3300 Allegro Networks 3301 6399 San Ignacio Ave. 3302 San Jose 3303 CA 95119 3304 FAX: 415 345 1827 3305 Email: andrew@allegronetworks.com 3307 Francis Reichmeyer 3308 PFN, Inc. 3309 University Park at MIT 3310 26 Landsdowne Street 3311 Cambridge, MA 02139 3312 Phone: +1 617 494 9980 3313 Email: franr@pfn.com 3315 Special thanks to Carol Bell and David Durham for their many 3316 significant comments. 3318 Framework Policy Information Base May 30, 2002 3320 10. References 3322 10.1 Normative References 3324 [COPS] 3325 Boyle, J., Cohen, R., Durham, D., Herzog, S., Rajan, R., and 3326 A. Sastry, "The COPS (Common Open Policy Service) Protocol" 3327 RFC 2748, January 2000. 3329 [COPS-PR] 3330 K. Chan, D. Durham, S. Gai, S. Herzog, K. McCloghrie, 3331 F. Reichmeyer, J. Seligson, A. Smith, R. Yavatkar, "COPS Usage 3332 for Policy Provisioning," RFC 3084, March 2001. 3334 [SPPI] 3335 K. McCloghrie, M. Fine, J. Seligson, K. Chan, S. Hahn, 3336 R. Sahita, A. Smith, F. Reichmeyer, "Structure of Policy 3337 Provisioning Information," RFC 3159, August 2001. 3339 [SNMP-SMI] 3340 K. McCloghrie, D. Perkins, J. Schoenwaelder, J. Case, M. Rose 3341 and S. Waldbusser, "Structure of Management Information 3342 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 3344 [INETADDR] 3345 M. Daniele, B. Haberman, S. Routhier and J. Schoenwaelder 3346 "Textual Conventions for Internet Network Addresses" 3347 RFC3291, May 2002 3349 [802] 3350 IEEE Standards for Local and Metropolitan Area Networks: 3351 Overview and Architecture, ANSI/IEEE Std 802, 1990. 3353 [SNMPFRWK] 3354 Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture 3355 for Describing SNMP Management Frameworks", RFC 2571, 3356 May 1999 3358 [RFC2863] 3359 K. McCloghrie, F. Kastenholz, "The Interfaces Group MIB", 3360 RFC 2863, June 2000 3362 [DS-MIB] 3363 F. Baker, K. Chan, A. Smith, "Management Information Base for 3364 the Differentiated Services Architecture", 3365 draft-ietf-diffserv-mib-16.txt, November 2001 3367 [SNMPv2TC] 3368 K. McCloghrie, D. Perkins, J. Schoenwaelder, "Textual 3369 Conventions for SMIv2", RFC 2579, STD 58, April 1999 3371 Framework Policy Information Base May 30, 2002 3373 [RFC2279] 3374 F. Yergeau, "UTF-8, a transformation format of ISO 10646", 3375 RFC 2279, January 1998 3377 10.2 Informative References 3379 [RAP-FRAMEWORK] 3380 R. Yavatkar, D. Pendarakis, "A Framework for Policy-based 3381 Admission Control", RFC 2753, January 2000. 3383 [POLTERM] 3384 A. Westerinen, J. Schnizlein, J. Strassner, M. Scherling, B. 3385 Quinn, S. Herzog, A. Huynh, M. Carlson, J. Perry, S. 3386 Waldbusser, "Terminology for Policy-Based Management", RFC 3387 3198, November 2001. 3389 11. Full Copyright 3391 Copyright (C) The Internet Society (2001). All Rights Reserved. This 3392 document and translations of it may be copied and furnished to 3393 others, and derivative works that comment on or otherwise explain it 3394 or assist in its implementation may be prepared, copied, published 3395 and distributed, in whole or in part, without restriction of any 3396 kind, provided that the above copyright notice and this paragraph 3397 are included on all such copies and derivative works. However, this 3398 document itself may not be modified in any way, such as by removing 3399 the copyright notice or references to the Internet Society or other 3400 Internet organizations, except as needed for the purpose of 3401 developing Internet standards in which case the procedures for 3402 copyrights defined in the Internet Standards process must be 3403 followed, or as required to translate it into languages other than 3404 English. 3406 The limited permissions granted above are perpetual and will not be 3407 revoked by the Internet Society or its successors or assigns. 3409 This document and the information contained herein is provided on an 3410 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 3411 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 3412 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 3413 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 3414 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3416 Framework Policy Information Base May 30, 2002 3418 Table of Contents 3420 Status of this Memo...............................................1 3421 Abstract..........................................................2 3422 1. Glossary.......................................................2 3423 2. General PIB Concepts...........................................2 3424 2.1. Roles........................................................2 3425 2.1.1. An Example.................................................4 3426 2.2. Management of Role-Combinations from the PDP.................5 3427 2.3. Updating a Request State.....................................6 3428 2.3.1 Full Request State..........................................7 3429 2.3.2 Installing PRIs in a Request................................7 3430 2.3.3 Updating PRIs in a Request..................................7 3431 2.3.4 Removing PRIs from a Request................................7 3432 2.3.5 Removing EXTENDED, AUGMENTED PRIs...........................8 3433 2.3.6 Error Handling in Request updates...........................8 3434 2.4. Multiple PIB Instances.......................................8 3435 2.5. Reporting and Configuring of Device Capabilities............10 3436 2.6. Reporting of Device Limitations.............................10 3437 3. The Framework TC PIB module...................................12 3438 4. Summary of the Framework PIB..................................17 3439 4.1. Base PIB classes Group......................................17 3440 4.2. Device Capabilities group...................................18 3441 4.3. Classifier group............................................19 3442 4.4. Marker group................................................19 3443 5. The Framework PIB Module......................................20 3444 6. Security Considerations.......................................61 3445 7. RFC Editor Considerations.....................................62 3446 8. IANA Considerations...........................................62 3447 9. Author Information and Acknowledgments........................62 3448 10. References...................................................64 3449 10.1 Normative References........................................64 3450 10.2 Informative References......................................65 3451 11. Full Copyright...............................................65