idnits 2.17.1 draft-ietf-rap-frameworkpib-07.txt: -(89): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(243): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(272): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(791): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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? == There are 6 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 60 longer pages, the longest (page 2) being 66 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 60 pages 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([COPS-PR], [COPS], [SPPI]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** 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 167: '...ct, then the PEP MUST reject the insta...' RFC 2119 keyword, line 185: '...ters "+" and "*" MUST not be used in a...' RFC 2119 keyword, line 272: '... PDP, the PEP SHOULD send updated ...' RFC 2119 keyword, line 276: '... PEP SHOULD send these updated reque...' RFC 2119 keyword, line 278: '...cessfully and it MUST do so after send...' (25 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1499 has weird spacing: '...xLength attrV...' == Line 1500 has weird spacing: '...xLength attrV...' == Line 1501 has weird spacing: '...Limited range...' == Line 1502 has weird spacing: '...Limited range...' == Line 1515 has weird spacing: '...dNotify none ...' == (3 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 '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 (January 28, 2002) is 8117 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 2998, but no explicit reference was found in the text == Unused Reference: 'IFMIB' is defined on line 3008, but no explicit reference was found in the text == Unused Reference: 'SNMPFRWK' is defined on line 3018, 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') ** Downref: Normative reference to an Informational RFC: RFC 2753 (ref. 'RAP-FRAMEWORK') ** Obsolete normative reference: RFC 2233 (ref. 'IFMIB') (Obsoleted by RFC 2863) -- Possible downref: Non-RFC (?) normative reference: ref. '802' ** Obsolete normative reference: RFC 2571 (ref. 'SNMPFRWK') (Obsoleted by RFC 3411) Summary: 13 errors (**), 0 flaws (~~), 16 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft M. Fine 2 Expires July 2002 K. McCloghrie 3 File: draft-ietf-rap-frameworkpib-07.txt Cisco Systems 4 J. Seligson 5 K. Chan 6 Nortel Networks 7 S. Hahn 8 R. Sahita 9 Intel 10 A. Smith 11 Allegro Networks 12 F. Reichmeyer 13 PFN 15 January 28, 2002 17 Framework Policy Information Base 19 Status of this Memo 21 This document is an Internet-Draft and is in full conformance with 22 all provisions of Section 10 of RFC2026. Internet-Drafts are 23 working documents of the Internet Engineering Task Force (IETF), its 24 areas, and its working groups. Note that other groups may also 25 distribute working documents as Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six 28 months and may be updated, replaced, or obsoleted by other documents 29 at any time. It is inappropriate to use Internet-Drafts as 30 reference material or to cite them other than as ''work in 31 progress''. 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/1id-abstracts.html 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html 39 Framework Policy Information Base January 2002 41 Abstract 43 [SPPI] describes a structure for specifying policy information that 44 can then be transmitted to a network device for the purpose of 45 configuring policy at that device. The model underlying this 46 structure is one of well-defined provisioning classes and instances 47 of these classes residing in a virtual information store called the 48 Policy Information Base (PIB). 50 One way to provision policy is by means of the COPS protocol [COPS] 51 with the extensions for provisioning [COPS-PR]. This protocol 52 supports multiple clients, each of which may provision policy for a 53 specific policy domain such as QoS, virtual private networks, or 54 security. 56 As described in [COPS-PR], each client supports a non-overlapping 57 and independent set of PIB modules. However, some provisioning 58 classes are common to all subject-categories (client-types) and need 59 to be present in each. This document defines a set of PRCs and 60 textual conventions that are common to all clients that provision 61 policy using COPS for Provisioning. 63 1. Glossary 65 PRC Provisioning Class. A type of policy data. 66 PRI Provisioning Instance. An instance of a PRC. 67 PIB Policy Information Base. The database of policy information. 68 PDP Policy Decision Point. See [RAP-FRAMEWORK]. 69 PEP Policy Enforcement Point. See [RAP-FRAMEWORK]. 70 PRID Provisioning Instance Identifier. Uniquely identifies an 71 instance of a PRC. 73 2. General PIB Concepts 75 2.1. Roles 77 The policy to apply to an interface may depend on many factors such 78 as immutable characteristics of the interface (e.g., Ethernet or 79 frame relay), the status of the interface (e.g., half or full 80 duplex), or user configuration (e.g., branch office or headquarters 81 interface). Rather than specifying policies explicitly for each 82 interface of all devices in the network, policies are specified in 83 terms of interface functionality. 85 To describe these functionalities of an interface we use the concept 86 of "Roles". A Role is simply a string that is associated with an 87 interface. A given interface may have any number of roles 88 simultaneously. Provisioning classes have an attribute called a 89 "RoleCombination� which is a lexicographically ordered set of roles. 90 Instances of a given provisioning class are applied to an interface 91 if and only if the set of roles in the role combination matches the 92 set of the roles of the interface. 94 Framework Policy Information Base January 2002 96 Thus, roles provide a way to bind policy to interfaces without 97 having to explicitly identify interfaces in a consistent manner 98 across all network devices. (The SNMP experience with ifIndex has 99 proved this to be a difficult task.) That is, roles provide a level 100 of indirection to the application of a set of policies to specific 101 interfaces. Furthermore, if the same policy is being applied to 102 several interfaces, that policy need be pushed to the device only 103 once, rather than once per interface, as long as the interfaces are 104 configured with the same role combination. 106 We point out that, in the event that the administrator needs to have 107 unique policy for each interface, this can be achieved by 108 configuring each interface with a unique role. 110 The PEP sends all its Capability Set Names, Role Combinations, 111 Policy Controlled Interfaces, and their relationships to the PDP in 112 the first COPS request (REQ) message for a handle and whenever any 113 updates or deletes occur. The PDP can install new instances or 114 change existing instances of these PRIs. This operation can also 115 occur in subsequent request messages generated in response to COPS 116 state synchronization (SSQ) requests and local configuration 117 changes. 119 The comparing of roles (or role combinations) is case sensitive. 121 By convention, when formatting the role-combination for exchange 122 within a protocol message, within a PIB/MIB object's value, or as a 123 printed value, the set is formatted in lexicographical order of the 124 role's ASCII values; that is, the role that is first is formatted 125 first. For example, "a+b" and "b+a" are NOT different role- 126 combinations; rather, they are different formatting of the same 127 role-combination, and hence for this example: 128 - "a+b" is the valid formatting of that role-combination, 129 - "b+a" is an invalid formatting of that role-combination. 131 The role-combination of interfaces to which no roles have been 132 assigned is known as the "null" role-combination. (Note the 133 deliberate use of lower-case letters for "null" so that it avoids 134 confusion with the ASCII NULL character that has a value of zero but 135 a length of one.) 137 In an "install" or an "install-notify" class, the wildcard role- 138 combination "*" can be used. In addition to providing for interface- 139 specific roles, it also allows for other optimizations in reducing 140 the number of role-combinations for which a policy has to be 141 specified. For example: 143 Suppose we have three interfaces: 145 Roles A, B and R1 are assigned to interface I1 146 Roles A, B and R2 are assigned to interface I2 148 Framework Policy Information Base January 2002 150 Roles A, B and R3 are assigned to interface I3 152 Then, a PRI of a fictional IfDscpAssignTable that has the following 153 values for its attributes: 155 ifDscpAssignPrid = 1 156 ifDscpAssignRoles = "*+A+B" 157 ifDscpAssignName = "4queues" 158 ifDscpAssignDscpMap = 1 160 will apply to all three interfaces, because "*" matches with R1, R2 161 and R3. The policies can be assigned to an interface due to more 162 than one wild-carded role combo matching a given interface's role 163 combo string. The PDP should attempt to resolve conflicts between 164 policies before sending policies to the PEP. In the situation where 165 the PDP sends multiple policies to a PEP and they do conflict, 166 either because of an error by the PDP or because of a device- 167 specific conflict, then the PEP MUST reject the installation of the 168 conflicting policies and return an error. 170 Formally, 171 - The wildcard Role is denoted by "*", 172 - The "*" Role is not allowed to be defined as part of the role- 173 combination of an interface as notified by the PEP to the PDP; it 174 is only allowed in policies installed/deleted via COPS-PR from 175 the PDP to the PEP. 176 - For a policy to apply to an interface when the policy's role- 177 combination is "*+a+b", then the interface's role-combination: 178 - Must include "a" and "b", and 179 - Can include zero or more other roles. 180 - The wildcard character "*" is listed before the other roles as 181 "*" is lexicographically before "a"; however, the wildcard matches 182 any zero or more roles, irrespective of lexicographical order. 183 For example: "*+b+e+g" would match "a+b+c+e+f+g" 185 Note that the characters "+" and "*" MUST not be used in an 186 interface Role. The Framework Role PIB module in section 4 of this 187 document contains the Role and RoleCombination Textual Conventions. 189 2.1.1. An Example 191 The functioning of roles might be best understood by an example. 192 Suppose I have a device with three interfaces, with roles as 193 follows: 195 IF1: "finance" 196 IF2: "finance" 197 IF3: "manager" 199 Suppose, I also have a PDP with two policies: 201 P1: Packets from finance department (role "finance") get DSCP 5 202 P2: Packets from managers (role "manager") get DSCP 6 204 Framework Policy Information Base January 2002 206 To obtain policy, the PEP reports to the PDP that it has some 207 interfaces with role combination "finance" and some with role 208 combination "manager". In response, the PDP downloads policy P1 209 associated with role combination "finance" and downloads a second 210 policy P2 associated with role combination "manager". 212 Now suppose the finance person attached to IF2 is promoted to 213 manager and so the system administrator adds the role "manager" to 214 IF2. The PEP now reports to the PDP that it has three role 215 combinations: some interfaces with role combination "finance", some 216 with role combination "manager" and some with role combination 217 "finance+manager". In response, the PDP downloads an additional 218 third policy associated with the new role combination 219 "finance+manager". 221 How the PDP determines the policy for this new role combination is 222 entirely the responsibility of the PDP. It could do so 223 algorithmically or by rule. For example, there might be a rule that 224 specifies that manager policy takes preference over department 225 policy. Or there might be a third policy installed in the PDP as 226 follows: 228 P3: Packets from finance managers (role "finance" and role 229 "manager") get DSCP 7 231 The point here is that the PDP is required to determine what policy 232 applies to this new role combination and to download a third policy 233 to the PEP for the role combination "finance+manager" even if that 234 policy is the same as one already downloaded. The PEP is not 235 required (or allowed) to construct policy for new role combinations 236 from existing policy. 238 2.2. Management of Role-Combinations from the PDP 240 The PEP notifies the PDP of the Role-Combination assigned to each 241 interface and ifCapSetName in a COPS configuration request 242 (instances of the frwkIfRoleComboTable). The first request sent to 243 the PDP must be a �full state� request. A �full state� request for a 244 PEP includes all the notify and install-notify table PRIs for the 245 PEP. 247 All existing frwkIfRoleCombo instances must be sent to the PDP in 248 the first configuration request for a request handle. If the Role- 249 Combinations are not assigned specific values, default ('null') 250 Role-Combinations must be sent to the PDP for all ifIndices active 251 on the PEP and updates must be sent every time the IfIndices are 252 updated. The PEP may notify the PDP of the Interface Capability sets 253 (if any) via the frwkIfCapSetTable. If the PEP does not need to 254 notify the PDP of capability sets, it must set the ifCapSetName in 255 the frwkIfRoleComboTable instances to a zero length string. 257 In response to this configuration request, if applicable, the PDP 258 may send policies for the PEP in a solicited decision or must send a 260 Framework Policy Information Base January 2002 262 null decision. The PEP must then send a solicited report message for 263 the decision. 265 At any later time, the PDP can update the Role-Combinations assigned 266 to a specific interface, identified by IfIndex, or for an aggregate, 267 identified by IfCapSetName, via an unsolicited decision to the PEP 268 on any open request handle. The PDP does this by sending updated 269 PRIs for the frwkIfRoleComboTable. 271 When the Interface Role Combination associations are updated by the 272 PDP, the PEP SHOULD send updated �full state� requests for all open 273 contexts (request handles). This is true even if the PEP's request 274 state changes due to an internal event or if the state is changed by 275 the PDP. If the role-combination updates were sent by the PDP, the 276 PEP SHOULD send these updated requests only if it can process the 277 unsolicited decision containing the frwkIfRoleCombo PRIs 278 successfully and it MUST do so after sending the success report for 279 the unsolicited decision. If the PEP failed to process the decision 280 (i.e., the frwkIfRoleCombo PRIs) it MUST only send a failure report 281 to the PDP. 283 On the other hand, the PDP must not expect to receive the updated 284 requests with the revised role-combination information until after 285 it receives a success report for these updates from the PEP. If the 286 PDP does not receive updated requests on some request handles, the 287 PEP must not be sent decision updates for that frwkIfRoleCombo 288 updates, i.e., the PDP must have the previous request state that it 289 maintained for that request handle. 291 Note that, any unsolicited decisions received by the PEP in the time 292 period after it receives updates to its Role-Combination 293 associations and before receiving solicited decisions for the 294 updated requests it sent for all context handles, must be ignored 295 since they would contain outdated decisions sent by the PDP for the 296 old request information. 298 The PDP must respond to the updated requests by solicited decisions, 299 sending policies if applicable or null decisions. The PEP must 300 respond to these solicited decisions with solicited reports to 301 complete the transaction. 303 2.3. Updating a Request State 305 This section describes the messages exchanged between the PEP and 306 PDP when the PEP is updating a previously sent request for a 307 particular COPS handle. Note that a PEP can incrementally update a 308 request only if the frwkPibIncarnationFullState attribute is shown 309 to be supported via the supported PRC table. If this attribute is 310 not supported the PDP must treat all PEP requests as the full 311 request state. 313 2.3.1 Full Request State 315 Framework Policy Information Base January 2002 317 When the PEP wants to send the entire request state to the PDP (for 318 example, in response to a Synchronize State Request from the PDP), 319 the PEP MUST send the incarnation instance with the 320 frwkPibIncarnationFullState attribute set to TRUE. 322 A PDP that receives an incarnation instance in the request message 323 with this attribute set to TRUE, must clear the request information 324 it maintains for this request handle and re-install the information 325 received. 327 If this attribute is set to FALSE or if the incarnation instance is 328 missing in the request message, the request must be interpreted as 329 an incremental update to the previous request message. 331 2.3.2 Installing PRIs in a Request 333 If the PEP wants to install additional PRIs for a request handle, 334 the PEP MUST ensure that frwkPibIncarnationFullState attribute is 335 set to FALSE and the PEP MUST use new (unused in this context) 336 InstanceIds [SPPI] for these PRIs. 338 When a PDP receives instances with new InstanceIds for a request 339 with the frwkPibIncarnationFullState in the incarnation instance set 340 to FALSE or if the request has no incarnation information, it must 341 interpret these PRIs as an incremental update to the request state 342 and add them to the request state it maintains for this handle. 344 2.3.3 Updating PRIs in a Request 346 If the PEP wants to update previously installed PRIs for a request 347 handle, the PEP MUST ensure that frwkPibIncarnationFullState 348 attribute is set to FALSE for these PRIs. Note that the PEP must 349 send the same InstanceIds for the PRIs being updated. If the PEP 350 uses new InstanceIds, the PDP must interpret them as Install's 351 for this request state. 353 When a PDP receives a request with instances having InstanceIds that 354 exist in its state for that handle with the 355 frwkPibIncarnationFullState in the incarnation instance set to FALSE 356 or if the request has no incarnation information, it must interpret 357 these PRIs as an update to the PRIs in the request state it 358 maintains for this handle. 360 2.3.4 Removing PRIs from a Request 362 If the PEP wants to remove previously installed PRIs for a request 363 handle, the PEP MUST ensure that frwkPibIncarnationFullState 364 attribute is set to FALSE and MUST send the PRI bindings with the 365 PRID set to the InstanceId of the PRI to be removed and the length 366 field in the EPD object header set to the header length only, 367 effectively setting the data length to zero. 369 Framework Policy Information Base January 2002 371 Note that the PEP must send the same InstanceIds for the PRIs being 372 removed. If the PEP sends new InstanceIds and the length field in 373 the EPD object header is set to the header length only (implying the 374 data length is zero), the PEP is attempting to remove an 375 unknown/non-existent PRI. This SHOULD result in the PDP sending 376 error PRIs in the solicited decision (see section 2.3.6 for a 377 description of the frwkErrorTable). 379 If the PEP sends new InstanceIds and the length field in the EPD 380 object header is greater than the header length only (implying the 381 EPD object has some attributes encoded in it), the PDP will 382 interpret this as an install of the PRI if it can decode the EPD 383 successfully. 385 When a PDP receives a request with instances having InstanceIds that 386 exist in its state for that handle with the 387 frwkPibIncarnationFullState in the incarnation instance set to FALSE 388 or if the request has no incarnation information, and the length 389 field in the EPD object header is set to the header length only 390 (implying the data length is zero), it must remove these PRIs from 391 the request state it maintains for this handle. 393 2.3.5 Removing EXTENDED, AUGMENTED PRIs 395 The PEP should remove the extended/augmented PRIs when it removes 396 the base PRIs in the same COPS message. See [SPPI] for description 397 of EXTENDED/AUGMENTED PRCs. A PDP that receives removes for a base 398 PRI must implicitly remove the extensions. 400 2.3.6 Error Handling in Request updates 402 If the PDP cannot process all the request installs/updates/removes 403 in the COPS request message successfully, it MUST rollback to its 404 previous request state and it MUST send a solicited decision to the 405 PEP that contains frwkErrorTable instances. These instances contain 406 an error code and a sub-code as defined in the [COPS-PR] CPERR 407 object. For example if the PEP tries to remove an instance that does 408 not exist, the 'priInstanceInvalid' error code must be sent to the 409 PEP in a frwkError PRI. The frwkError PRIs also contain the PRC and 410 the InstanceId of the error-causing PRI. The PEP may then examine 411 these error PRIs and resend the modified request. Note that, until 412 the PEP resends the request updates/removes it will have 413 configuration information for the last successful request state it 414 sent to the PDP. 416 2.4. Multiple PIB Instances 418 [COPS-PR] supports multiple, disjoint, independent instances of the 419 PIB to represent multiple instances of configured policy. The 420 intent is to allow for the pre-provisioning of policy that can then 421 be made active by a single, short decision from the PDP. 423 Framework Policy Information Base January 2002 425 A COPS context can be defined as an independent COPS request state 426 for a particular subject category (client-type). 428 With the COPS-PR protocol, each of these states is identified by a 429 unique client handle. The creation and deletion of these PIB 430 instances can be controlled by the PDP as described in [COPS-PR] or 431 can be triggered by an event by the PEP. A PEP must open at least 432 one "request-state" for configuration for a given subject-category 433 (client type). Additional "request-states" at the PEP may be 434 initiated by the PDP or asynchronously generated by the PEP for 435 outsourcing due to local events, which will be fully specified by 436 the PRID/EPD data carried in the request. 438 The frwkPibIncarnationInCtxtSet flag defines a set of contexts out 439 of which only one context can be active at any given time. This set 440 is called the 'configuration contexts' set. At the most one context 441 may be active from this 'configuration context' set at any given 442 time. Contexts that have the frwkPibIncarnationInCtxtSet attribute 443 set to 'true' belong to this set. Contexts that do not belong to 444 this set have the frwkPibIncarnationInCtxtSet set to 'false' and 445 belong to the set of 'outsourcing contexts'. Note that a PEP can 446 have these two sets of contexts only if the 447 frwkPibIncarnationInCtxtSet attribute is shown to be supported via 448 the supported PRC table. If the frwkPibIncarnationInCtxtSet is not 449 supported a PEP must treat all contexts as belonging to the set of 450 'configuration contexts' i.e., at the most one context can be active 451 at any given time. 453 Note that in the event that a PEP has an interface capability change 454 such as a card hot swap or any other change in its notify 455 information that may warrant a policy refresh, a subsequent complete 456 or incremental request must be issued to the PDP containing the 457 new/updated capabilities for all the configuration contexts. A 458 request for re-configuration is issued for all request state 459 configuration contexts, both for the active configuration context as 460 well as any inactive configuration contexts. This is to ensure that 461 when an inactive configuration context is activated, it has been 462 pre-configured with policies compatible with the PEP's current 463 capabilities. 465 Although many PIB instances may be configured on a device (the 466 maximum number of these instances being determined by the device 467 itself) only one of the contexts from the 'configuration contexts' 468 set can be active at any given time, the active one being selected 469 by the PDP. The Framework PIB supports the attribute 470 frwkPibIncarnationActive in the frwkPibIncarnationTable to allow the 471 PDP to denote the PIB instance as being active in a COPS decision 472 message, and similarly, to report the active state (active or not) 473 of the PIB instance to the PDP in a COPS request message. 475 When the PEP installs an attribute frwkPibIncarnationActive that is 476 'true' in one PIB instance which belongs to the 'configuration 477 contexts' set, the PEP must ensure, re-setting the attribute if 479 Framework Policy Information Base January 2002 481 necessary, that the frwkPibIncarnationActive attribute is 'false' 482 in all other installed contexts that belong to this set. To switch 483 contexts, the PDP should set the frwkPibIncarnationActive attribute 484 to 'true' in the context it wants to make the active context. The 485 PDP should set this attribute in a context to 'false' only if it 486 wants to send an inactive context to the PEP or deactivate the 487 active context on the PEP. If an active context is made inactive 488 without activating another context, the PEP must not have any 489 policies enforced from any configuration contexts installed. 491 2.5. Reporting and Configuring of Device Capabilities 493 Each network device providing policy-based services has its own 494 inherent capabilities. These capabilities can be hardware specific, 495 e.g., an Ethernet interface supporting input classification, or can 496 be statically configured, e.g., supported queuing disciplines. 497 These capabilities are organized into Interface Capability Sets, 498 with each Capability Set given a unique name (ifCapSetName) and 499 associated with a set of Role Combinations. Each Role Combination 500 may in that way be associated with a set of interfaces. . These 501 capabilities are communicated to the PDP when policy is requested by 502 the PEP. Knowing device capabilities, the PDP can send the 503 provisioning instances (PRIs) relevant to the specific device, 504 rather than sending the entire PIB. 506 Specific capability PRCs may be defined in other PIBs. These 507 capability instances are grouped via the frwkIfCapSetTable. If the 508 PEP wishes to send capability information to the PDP, the PIB must 509 indicate which capabilities the PEP may send to the PDP by means of 510 the 'notify' PIB-ACCESS clause as described in [SPPI]. If a PIB does 511 not have any capabilities to communicate to the PDP, it must not 512 send any instances for the frwkIfCapSetTable. If in this case the 513 frwkIfRoleCombo table is used to communicate role combinations 514 assigned to interfaces (via IfIndex), the ifCapSetName attribute in 515 the frwkIfRoleComboTable instances must be set to a zero length 516 string. 518 2.6. Reporting of Device Limitations 520 To facilitate efficient policy installation, it is important to 521 understand a device's limitations in relation to the advertised 522 device capabilities. Limitations may be class-based, e.g., an 523 "install" class is supported as a "notify" or only a limited number 524 of class instances may be created, or attribute-based. Attribute 525 limitations, such as supporting a restricted set of enumerations or 526 requiring related attributes to have certain values, detail 527 implementation limitations at a fine level of granularity. 529 A PDP can avoid certain installation issues in a proactive fashion 530 by taking into account a device's limitations prior to policy 531 installation rather than in a reactive mode during installation. As 532 with device capabilities, device limitations are communicated to the 533 PDP when policy is requested. 535 Framework Policy Information Base January 2002 537 Reported device limitations may be accompanied by guidance values 538 that can be used by a PDP to determine acceptable values for the 539 identified attributes. 541 3. The Framework TC PIB module 543 FRAMEWORK-TC-PIB PIB-DEFINITIONS ::= BEGIN 545 IMPORTS MODULE-IDENTITY, TEXTUAL-CONVENTION, pib FROM COPS-PR-SPPI; 547 frwkTcPib MODULE-IDENTITY 548 SUBJECT-CATEGORIES { all } 549 LAST-UPDATED "200111130400Z" 550 ORGANIZATION "IETF RAP WG" 551 CONTACT-INFO "Keith McCloghrie 552 Cisco Systems, Inc. 553 170 West Tasman Drive, 554 San Jose, CA 95134-1706 USA 555 Phone: +1 408 526 5260 556 Email: kzm@cisco.com 558 John Seligson 559 Nortel Networks, Inc. 560 4401 Great America Parkway 561 Santa Clara, CA 95054 USA 562 Phone: +1 408 495 2992 563 Email: jseligso@nortelnetworks.com" 564 DESCRIPTION 565 "The PIB module containing the Role and 566 RoleCombination Textual Conventions and other 567 generic TCs." 569 ::= { pib tbd } -- tbd to be assigned by IANA 571 Role ::= TEXTUAL-CONVENTION 572 STATUS current 573 DESCRIPTION 574 "A role represents a functionality characteristic or 575 capability of a resource to which policies are applied. 576 Examples of roles include Backbone interface, 577 Frame_Relay_interface, BGP-capable-router, web-server, 578 firewall, etc. 579 Valid characters are a-z, A-Z, 0-9, period, hyphen and 580 underscore. A role must not start with an underscore." 581 SYNTAX OCTET STRING (SIZE (1..31)) 583 RoleCombination ::= TEXTUAL-CONVENTION 585 Framework Policy Information Base January 2002 587 STATUS current 588 DESCRIPTION 589 "A Display string consisting of a set of roles concatenated 590 with a '+' character where the roles are in lexicographic 591 order from minimum to maximum. 592 For example, a+b and b+a are NOT different 593 role-combinations; rather, they are different formatting of 594 the same (one) role-combination. 596 Notice the roles within a role-combination are in 597 Lexicographic order from minimum to maximum, hence, we 598 declare: 599 a+b is the valid formatting of the role-combination, 600 b+a is an invalid formatting of the role-combination. 602 Notice the need of zero-length role-combination as the role- 603 combination of interfaces to which no roles have been 604 assigned. This role-combination is also known as the null 605 role-combination. (Note the deliberate use of lower case 606 letters to avoid confusion with the ASCII NULL character 607 which has a value of zero but length of one.)" 608 SYNTAX OCTET STRING (SIZE (0..255)) 610 PrcIdentifier ::= TEXTUAL-CONVENTION 611 STATUS current 612 DESCRIPTION 613 "An OID that identifies a PRC. The value MUST be an OID 614 assigned to a PRC's row definition. An attribute with this 615 syntax can have the value 0.0 (zeroDotZero) to indicate that 616 it currently does not identify a PRC." 617 SYNTAX OBJECT IDENTIFIER 619 AttrIdentifier ::= TEXTUAL-CONVENTION 620 STATUS current 621 DESCRIPTION 622 "A Unsigned32 value that identifies an attribute in a PRC. 624 A AttrIdentifier value is always interpreted within the 625 context of a PrcIdentifier value. The PrcIdentifier object 626 which defines the context must be registered immediately 627 before the object which uses the AttrIdentifier textual 628 convention. 630 An attribute with this syntax can have the value 0 to 631 indicate that it currently does not identify a PRC 632 attribute." 633 SYNTAX Unsigned32 635 AttrIdentifierOid ::= TEXTUAL-CONVENTION 636 STATUS current 637 DESCRIPTION 638 "An OID that identifies an attribute in a PRC. The value 639 MUST be an OID assigned to a PRC's attribute definition. The 641 Framework Policy Information Base January 2002 643 last sub-id is the position of the attribute as it is 644 defined in the PRC entry definition. The prefix OID (after 645 dropping the last sub-id) is the OID assigned to a defined 646 PRC. An attribute with this syntax can have the value 0.0 647 (zeroDotZero) to indicate that it currently does not 648 identify a PRC's attribute." 649 SYNTAX OBJECT IDENTIFIER 651 ClientType ::= TEXTUAL-CONVENTION 652 STATUS current 653 DESCRIPTION 654 "An Unsigned32 value that identifies a COPS Client-type 655 [COPS]. An attribute with this syntax must be set to zero if 656 it does not specify a COPS client-type." 657 SYNTAX Unsigned32 (0..65535) 659 ClientHandle ::= TEXTUAL-CONVENTION 660 STATUS current 661 DESCRIPTION 662 "An octet string that identifies a COPS Client handle 663 [COPS]." 664 SYNTAX OCTET STRING (SIZE(0..65535)) 666 END 668 Framework Policy Information Base January 2002 670 4. Summary of the Framework PIB 672 The Framework PIB comprises of three groups: 674 4.1. Base PIB classes Group 676 This contains PRCs intended to describe the PRCs supported 677 by the PEP, PRC and/or attribute limitations and its current 678 configuration. 680 PRC Support Table 682 As the technology evolves, we expect devices to be enhanced 683 with new PIBs, existing PIBs to add new PRCs and existing PRCs 684 to be augmented or extended with new attributes. Also, it is 685 likely that some existing PRCs or individual attributes of PRCs 686 will be deprecated. The PRC Support Table describes the PRCs 687 that the device supports as well as the individual attributes 688 of each PRC. Using this information the PDP can potentially 689 tailor the policy to more closely match the capabilities of the 690 device. The PRC Support Table instances are specific to the 691 particular Subject Category (Client-Type). That is, the PRC 692 Support Table for Subject Category 'A' will not include 693 instances for classes supported by the Subject Category 'B'. 694 Note that the COPS client-type [COPS] used for Framework PIB 695 PRIs sent/received over COPS-PR MUST be the unique SUBJECT- 696 CATEGORY number assigned for the area of policy being managed 697 (e.g. QoS, Security etc). 698 The PEP MUST ignore the attributes that it reports as not 699 Supported in the decision from the PDP. The PEP SHOULD not send 700 duplicate PRC support instances in a COPS Request and the PDP 701 MUST ignore duplicate instances and MUST use the first instance 702 received for a supported PRC in a COPS Request. 704 PIB Incarnation Table 706 This table contains exactly one row (corresponding to one PRI) 707 per context. It identifies the PDP that was the last to 708 download policy into the device and also contains an identifier 709 to identify the version of the policy currently downloaded. 710 This identifier, both its syntax and value, is meaningful only 711 to the PDPs. It is intended to be a mechanism whereby a PDP, 712 on connecting to a PEP, can easily identify a known incarnation 713 of policy. This PRC defines a flag via which the installed 714 contexts are divided into a set of contexts out of which only 715 one context is active ('configuration contexts') and a set of 716 'outsourcing contexts'. The incarnation PRC also 717 defines an attribute to indicate which context is the 718 active one at the present time in the 'configuration contexts' 719 set. The incarnation instance is specific to the particular 720 Subject Category (Client-Type). 722 Framework Policy Information Base January 2002 724 Component Limitations Table 726 Some devices may not be able to implement the full range of 727 values for all attributes. In principle, each PRC supports a 728 set of errors that the PEP can report to the PDP in the event 729 that the specified policy is not implementable. It may be 730 preferable for the PDP to be informed of the device limitations 731 before actually attempting to install policy, and while the 732 error can indicate that a particular attribute value is 733 unacceptable to the PEP, this does not help the PDP ascertain 734 which values would be acceptable. To alleviate these 735 limitations, the PEP can report some limitations of attribute 736 values and/or classes and possibly guidance values for the 737 attribute in the Component Limitations Table 739 Device Identification Table 741 This class contains a single provisioning instance that 742 contains device-specific information that is used to facilitate 743 efficient policy installation by a PDP. The instance of this 744 class is reported to the PDP in a COPS request message so that 745 the PDP can take into account certain device characteristics 746 during policy installation. 748 4.2. Device Capabilities group 750 This group contains the PRCs that describe the characteristics of 751 interfaces of the device and the Role Combinations assigned to 752 them. 754 Interface Capabilities Set Table 756 The interfaces the PEP supports are described by rows in 757 this table (frwkIfCapSetTable). Each row, or instance of this 758 class, associates a unique interface name with a set of 759 capabilities that the interface supports. The unique name is 760 used to form a set of capabilities that the name represents. 761 The capability references can specify instances in relevant 762 capability tables in any PIB. The PEP notifies the PDP of these 763 interface names and capabilities and then the PDP configures 764 the interfaces, per role combination. The unique name 765 (IfCapSetName) is not to be confused with the IfType object in 766 MIB-II [STD17]. 768 Interface and Role Combination Table 770 The Interface Capabilities Set Table (explained above) 771 describes the interfaces the PEP supports by their 772 capabilities, by assigning the capability sets a unique name 773 (ifCapSetName). It is possible to tailor the behavior of 774 interfaces by assigning specific role-combinations to the 775 capability sets. This allows interfaces with the same 776 capability sets to be assigned different policies, based on the 778 Framework Policy Information Base January 2002 780 current roles assigned to them. At the PDP, configuration is 781 done in terms of these interface capability set names and the 782 role-combinations assigned to them. Thus, each row of this 783 class is a tuple, that indicates the roles that have been 785 assigned to a particular capability set (as identified by 786 IfCapSetName) and to a particular ifCapSetName. Note that the 787 uniqueness criteria for this table has all the attributes, thus 788 a ifCapSetName may have multiple role-combinations that it is 789 associated with. Via the IfIndex, this table answers the 790 questions of �which interfaces have a specific role 791 combination?� and �what role combination a specific interface 792 is a part of?�. 794 4.3. Classifier group 796 This group contains the IP, IEEE 802 and Internal Label 797 Classifier elements. The set of tables consist of a Base Filter 798 table that contains the Index InstanceId and the Negation flag 799 for the filter. This frwkBaseFilterTable is extended to form the 800 IP Filter table, the 802 Filter table [802] and the Internal 801 Label table. Filters may also be defined outside this document 802 and used to extend the Base Filter table. 804 The Extended classes do not have a separate Index value. 805 Instances of the extended classes have the same indices as their 806 base class instance. Inheritance is achieved using the EXTENDS 807 keyword as defined in [SPPI]. 809 4.4. Marker group 811 This group contains the 802 marker and internal label marker 812 PRCs. The 802 marker may be applied to mark 802 packets with the 813 required VLAN Id and/or priority value. The Internal Label marker 814 is applied to traffic in order to label it with a network device 815 specific label. Such a label is used to assist the 816 differentiation of an input flow after it has been aggregated 817 with other flows. The label is implementation specific and may 818 be used for other policy related functions like flow accounting 819 purposes and/or other data path treatments. 821 Framework Policy Information Base January 2002 823 5. The Framework PIB Module 825 FRAMEWORK-PIB PIB-DEFINITIONS ::= BEGIN 827 IMPORTS 828 Unsigned32, Integer32, MODULE-IDENTITY, 829 MODULE-COMPLIANCE, OBJECT-TYPE, OBJECT-GROUP, pib 830 FROM COPS-PR-SPPI 831 InstanceId, Prid 832 FROM COPS-PR-SPPI-TC 833 RoleCombination, PrcIdentifier, AttrIdentifier, 834 ClientType, ClientHandle 835 FROM FRAMEWORK-TC-PIB 836 InetAddress, InetAddressType, 837 InetAddressPrefixLength, InetPortNumber 838 FROM INET-ADDRESS-MIB 839 InterfaceIndex 840 FROM IF-MIB 841 DscpOrAny 842 FROM DIFFSERV-DSCP-TC 843 TruthValue, PhysAddress 844 FROM SNMPv2-TC 845 SnmpAdminString 846 FROM SNMP-FRAMEWORK-MIB; 848 frameworkPib MODULE-IDENTITY 849 SUBJECT-CATEGORIES { all } 850 LAST-UPDATED "200201280400Z" 851 ORGANIZATION "IETF RAP WG" 852 CONTACT-INFO " 853 Michael Fine 854 Cisco Systems, Inc. 855 170 West Tasman Drive 856 San Jose, CA 95134-1706 USA 857 Phone: +1 408 527 8218 858 Email: mfine@cisco.com 860 Keith McCloghrie 861 Cisco Systems, Inc. 862 170 West Tasman Drive, 863 San Jose, CA 95134-1706 USA 864 Phone: +1 408 526 5260 865 Email: kzm@cisco.com 867 John Seligson 868 Nortel Networks, Inc. 869 4401 Great America Parkway 870 Santa Clara, CA 95054 USA 871 Phone: +1 408 495 2992 872 Email: jseligso@nortelnetworks.com" 874 DESCRIPTION 875 "A PIB module containing the base set of provisioning 877 Framework Policy Information Base January 2002 879 classes that are required for support of policies for 880 all subject-categories." 882 ::= { pib tbd } -- tbd to be assigned by IANA 884 -- 885 -- The root OID for PRCs in the Framework PIB 886 -- 888 frwkBasePibClasses 889 OBJECT IDENTIFIER ::= { frameworkPib 1 } 891 -- 892 -- Textual Conventions 893 -- 895 -- 896 -- PRC Support Table 897 -- 899 frwkPrcSupportTable OBJECT-TYPE 900 SYNTAX SEQUENCE OF FrwkPrcSupportEntry 901 PIB-ACCESS notify 902 STATUS current 903 DESCRIPTION 904 "Each instance of this class specifies a PRC that the device 905 supports and a bit string to indicate the attributes of the 906 class that are supported. These PRIs are sent to the PDP to 907 indicate to the PDP which PRCs, and which attributes of 908 these PRCs, the device supports. This table can also be 909 downloaded by a network manager when static configuration is 910 used. 912 All install and install-notify PRCs supported by the device 913 must be represented in this table. Notify PRCs may be 914 represented for informational purposes." 916 ::= { frwkBasePibClasses 1 } 918 frwkPrcSupportEntry OBJECT-TYPE 919 SYNTAX FrwkPrcSupportEntry 920 STATUS current 921 DESCRIPTION 922 "An instance of the frwkPrcSupport class that identifies a 923 specific PRC and associated attributes as supported 924 by the device." 926 PIB-INDEX { frwkPrcSupportPrid } 927 UNIQUENESS { frwkPrcSupportSupportedPrc } 929 ::= { frwkPrcSupportTable 1 } 931 Framework Policy Information Base January 2002 933 FrwkPrcSupportEntry ::= SEQUENCE { 934 frwkPrcSupportPrid InstanceId, 935 frwkPrcSupportSupportedPrc PrcIdentifier, 936 frwkPrcSupportSupportedAttrs OCTET STRING 937 } 939 frwkPrcSupportPrid OBJECT-TYPE 940 SYNTAX InstanceId 941 STATUS current 942 DESCRIPTION 943 "An arbitrary integer index that uniquely identifies an 944 instance of the frwkPrcSupport class." 946 ::= { frwkPrcSupportEntry 1 } 948 frwkPrcSupportSupportedPrc OBJECT-TYPE 949 SYNTAX PrcIdentifier 950 STATUS current 951 DESCRIPTION 952 "The object identifier of a supported PRC. The value is the 953 OID of the table entry. There may not be more than one 954 instance of the frwkPrcSupport class with the same value of 955 frwkPrcSupportSupportedPrc." 957 ::= { frwkPrcSupportEntry 2 } 959 frwkPrcSupportSupportedAttrs OBJECT-TYPE 960 SYNTAX OCTET STRING 961 STATUS current 962 DESCRIPTION 963 "A bit string representing the supported attributes of the 964 class that is identified by the frwkPrcSupportSupportedPrc 965 object. 967 Each bit of this bit string corresponds to a class 968 attribute, with the most significant bit of the i-th octet 969 of this octet string corresponding to the (8*i - 7)-th 970 attribute, and the least significant bit of the i-th octet 971 corresponding to the (8*i)-th class attribute. Each bit 972 specifies whether or not the corresponding class attribute 973 is currently supported, with a '1' indicating support and a 974 '0' indicating no support. If the value of this bit string 975 is N bits long and there are more than N class attributes 976 then the bit string is logically extended with 0's to the 977 required length." 979 ::= { frwkPrcSupportEntry 3 } 981 Framework Policy Information Base January 2002 983 -- 984 -- PIB Incarnation Table 985 -- 987 frwkPibIncarnationTable OBJECT-TYPE 988 SYNTAX SEQUENCE OF FrwkPibIncarnationEntry 989 PIB-ACCESS install-notify 990 STATUS current 991 DESCRIPTION 992 "This class contains a single provisioning instance per 993 installed context that identifies the current incarnation 994 of the PIB and the PDP or network manager that installed 995 this incarnation. The instance of this class is reported to 996 the PDP in the REQ message so that the PDP can (attempt to) 997 ascertain the current state of the PIB. A network manager 998 may use the instance to determine the state of the device." 1000 ::= { frwkBasePibClasses 2 } 1002 frwkPibIncarnationEntry OBJECT-TYPE 1003 SYNTAX FrwkPibIncarnationEntry 1004 STATUS current 1005 DESCRIPTION 1006 "An instance of the frwkPibIncarnation class. Only 1007 one instance of this provisioning class is ever 1008 instantiated per context" 1010 PIB-INDEX { frwkPibIncarnationPrid } 1012 ::= { frwkPibIncarnationTable 1 } 1014 FrwkPibIncarnationEntry ::= SEQUENCE { 1015 frwkPibIncarnationPrid InstanceId, 1016 frwkPibIncarnationName SnmpAdminString, 1017 frwkPibIncarnationId OCTET STRING, 1018 frwkPibIncarnationLongevity Unsigned32, 1019 frwkPibIncarnationTtl Unsigned32, 1020 frwkPibIncarnationInCtxtSet TruthValue, 1021 frwkPibIncarnationActive TruthValue, 1022 frwkPibIncarnationFullState TruthValue 1023 } 1025 frwkPibIncarnationPrid OBJECT-TYPE 1026 SYNTAX InstanceId 1027 STATUS current 1028 DESCRIPTION 1029 "An index to uniquely identify an instance of this 1030 provisioning class." 1032 ::= { frwkPibIncarnationEntry 1 } 1034 Framework Policy Information Base January 2002 1036 frwkPibIncarnationName OBJECT-TYPE 1037 SYNTAX SnmpAdminString 1038 STATUS current 1039 DESCRIPTION 1040 "The name of the PDP that installed the current incarnation 1041 of the PIB into the device. By default, it is the zero 1042 length string." 1044 ::= { frwkPibIncarnationEntry 2 } 1046 frwkPibIncarnationId OBJECT-TYPE 1047 SYNTAX OCTET STRING 1048 STATUS current 1049 DESCRIPTION 1050 "An ID to identify the current incarnation. It has meaning 1051 to the PDP/manager that installed the PIB and perhaps its 1052 standby PDPs/managers. By default, it is the zero-length 1053 string." 1055 ::= { frwkPibIncarnationEntry 3 } 1057 frwkPibIncarnationLongevity OBJECT-TYPE 1058 SYNTAX Unsigned32 { 1059 expireNever(1), 1060 expireImmediate(2), 1061 expireOnTimeout(3) 1062 } 1063 STATUS current 1064 DESCRIPTION 1065 "This attribute controls what the PEP does with the 1066 downloaded policy on a Client Close message or a loss of 1067 connection to the PDP. 1069 If set to expireNever, the PEP continues to operate with the 1070 installed policy indefinitely. If set to expireImmediate, 1071 the PEP immediately expires the policy obtained from the PDP 1072 and installs policy from local configuration. If set to 1073 expireOnTimeout, the PEP continues to operate with the 1074 policy installed by the PDP for a period of time specified 1075 by frwkPibIncarnationTtl. After this time (and it has not 1076 reconnected to the original or new PDP) the PEP expires this 1077 policy and reverts to local configuration. 1079 For all cases, it is the responsibility of the PDP to check 1080 the incarnation and download new policy, if necessary, on a 1081 reconnect. On receiving a Remove-State [COPS-PR] for the 1082 active context, this attribute value MUST be ignored and the 1083 PEP should expire the policy in that active context 1084 immediately. 1085 Policy enforcement timing only applies to policies that have 1086 been installed dynamically (e.g., by a PDP via COPS)." 1088 ::= { frwkPibIncarnationEntry 4 } 1090 Framework Policy Information Base January 2002 1092 frwkPibIncarnationTtl OBJECT-TYPE 1093 SYNTAX Unsigned32 1094 UNITS "seconds" 1095 STATUS current 1096 DESCRIPTION 1097 "The number of seconds after a Client Close or TCP timeout 1098 for which the PEP continues to enforce the policy in the 1099 PIB. After this interval, the PIB is considered expired and 1100 the device no longer enforces the policy installed in the 1101 PIB. 1103 This attribute is only meaningful if 1104 frwkPibIncarnationLongevity is set to expireOnTimeout." 1106 ::= { frwkPibIncarnationEntry 5 } 1108 frwkPibIncarnationInCtxtSet OBJECT-TYPE 1109 SYNTAX TruthValue 1110 STATUS current 1111 DESCRIPTION 1112 "When the PDP installs a PRI with this flag set to 'true' it 1113 implies this context belongs to the set of contexts out of 1114 which at the most one context can be active at a given time. 1115 If this attribute is set to false this context is one of the 1116 outsourcing (simultaneous active) contexts on the PEP." 1117 ::= { frwkPibIncarnationEntry 6 } 1119 frwkPibIncarnationActive OBJECT-TYPE 1120 SYNTAX TruthValue 1121 STATUS current 1122 DESCRIPTION 1123 "When the PDP installs a PRI on the PEP with this attribute 1124 set to 'true', then the PIB instance to which this PRI 1125 belongs must become the active PIB instance if this context 1126 belongs to the 'configuration contexts' set. In this case, 1127 the previous active instance from this set MUST become 1128 inactive and the frwkPibIncarnationActive attribute in that 1129 PIB instance MUST be set to 'false'. 1131 When the PDP installs an attribute frwkPibIncarnationActive 1132 on the PEP that is 'true' in one PIB instance and if the 1133 context belongs to the 'configuration contexts' set, the PEP 1134 must ensure, re-setting the attribute if necessary, that the 1135 frwkPibIncarnationActive attribute is 'false' in all other 1136 contexts which belong to the 'configuration contexts' set." 1138 ::= { frwkPibIncarnationEntry 7 } 1140 Framework Policy Information Base January 2002 1142 frwkPibIncarnationFullState OBJECT-TYPE 1143 SYNTAX TruthValue 1144 STATUS current 1145 DESCRIPTION 1146 "This attribute is interpreted only when sent in a COPS 1147 request message from the PEP to the PDP. It does not have 1148 any meaning when sent from the PDP to the PDP. 1150 If this attribute is set to TRUE by the PEP, then the 1151 request that the PEP sends to the PDP must be interpreted as 1152 the complete configuration request for the PEP. The PDP must 1153 in this case refresh the request information for that 1154 handle. If this attribute is set to FALSE, then the request 1155 PRIs sent in the request must be interpreted as updates to 1156 the previous request PRIs sent for that handle. See section 1157 3.3 for details on updating request state information." 1159 ::= { frwkPibIncarnationEntry 8 } 1161 -- 1162 -- Device Identification Table 1163 -- 1165 -- This table supports the ability to export general 1166 -- purpose device information to facilitate efficient 1167 -- communication between the device and a PDP 1169 frwkDeviceIdTable OBJECT-TYPE 1170 SYNTAX SEQUENCE OF FrwkDeviceIdEntry 1171 PIB-ACCESS notify 1172 STATUS current 1173 DESCRIPTION 1174 "This class contains a single provisioning instance that 1175 contains device-specific information that is used to 1176 facilitate efficient policy installation by a PDP. The 1177 instance of this class is reported to the PDP in a COPS 1178 request message so that the PDP can take into account 1179 certain device characteristics during policy installation." 1181 ::= { frwkBasePibClasses 3 } 1183 frwkDeviceIdEntry OBJECT-TYPE 1184 SYNTAX FrwkDeviceIdEntry 1185 STATUS current 1186 DESCRIPTION 1187 "An instance of the frwkDeviceId class. Only one instance of 1188 this provisioning class is ever instantiated." 1190 PIB-INDEX { frwkDeviceIdPrid } 1192 ::= { frwkDeviceIdTable 1 } 1194 Framework Policy Information Base January 2002 1196 FrwkDeviceIdEntry ::= SEQUENCE { 1197 frwkDeviceIdPrid InstanceId, 1198 frwkDeviceIdDescr SnmpAdminString, 1199 frwkDeviceIdMaxMsg Unsigned32, 1200 frwkDeviceIdMaxContexts Unsigned32 1201 } 1203 frwkDeviceIdPrid OBJECT-TYPE 1204 SYNTAX InstanceId 1205 STATUS current 1206 DESCRIPTION 1207 "An index to uniquely identify an instance of this 1208 provisioning class." 1210 ::= { frwkDeviceIdEntry 1 } 1212 frwkDeviceIdDescr OBJECT-TYPE 1213 SYNTAX SnmpAdminString 1214 STATUS current 1215 DESCRIPTION 1216 "A textual description of the PEP. This value should include 1217 the name and version identification of the PEP's hardware 1218 and software." 1220 ::= { frwkDeviceIdEntry 2 } 1222 frwkDeviceIdMaxMsg OBJECT-TYPE 1223 SYNTAX Unsigned32 1224 UNITS "octets" 1225 STATUS current 1226 DESCRIPTION 1227 "The maximum message size, in octets, that the device 1228 is capable of processing. Received messages with a 1229 size in excess of this value must cause the PEP to return an 1230 error to the PDP containing the global error code 1231 'maxMsgSizeExceeded'. This is an additional error-avoidance 1232 mechanism to allow the administrator to have the ability to 1233 control the message size of messages sent to the device. The 1234 device should send the MAX value for Unsigned32 for 1235 this attribute if it not defined." 1237 ::= { frwkDeviceIdEntry 3 } 1239 frwkDeviceIdMaxContexts OBJECT-TYPE 1240 SYNTAX Unsigned32 1241 UNITS "contexts" 1242 STATUS current 1243 DESCRIPTION 1245 Framework Policy Information Base January 2002 1247 "The maximum number of unique contexts supported by 1248 the device. This is an additional error-avoidance mechanism 1249 to allow the administrators to have the ability to control 1250 the number of contexts installed on the device. The 1251 device should send the MAX value for Unsigned32 for 1252 this attribute if it not defined." 1254 ::= { frwkDeviceIdEntry 4 } 1256 -- 1257 -- Component Limitations Table 1258 -- 1260 -- This table supports the ability to export information 1261 -- detailing provisioning class/attribute implementation limitations 1262 -- to the policy management system. Instances of this PRC apply only 1263 -- for PRCs with access type 'install' or 'install-notify'. 1265 frwkCompLimitsTable OBJECT-TYPE 1266 SYNTAX SEQUENCE OF FrwkCompLimitsEntry 1267 PIB-ACCESS notify 1268 STATUS current 1269 DESCRIPTION 1270 "Each instance of this class identifies a provisioning class 1271 or attribute and a limitation related to the implementation 1272 of the class/attribute in the device. Additional information 1273 providing guidance related to the limitation may also be 1274 present. These PRIs are sent to the PDP to indicate which 1275 PRCs or PRC attributes the device supports in a restricted 1276 manner." 1278 ::= { frwkBasePibClasses 4 } 1280 frwkCompLimitsEntry OBJECT-TYPE 1281 SYNTAX FrwkCompLimitsEntry 1282 STATUS current 1283 DESCRIPTION 1284 "An instance of the frwkCompLimits class that identifies 1285 a PRC or PRC attribute and a limitation related to the PRC 1286 or PRC attribute implementation supported by the device. 1287 [COPS-PR] lists the error codes that MUST be returned (if 1288 applicable)for policy installation that don't abide by the 1289 restrictions indicated by the limitations exported. [SPPI] 1290 defines an INSTALL-ERRORS clause that allows PIB designers 1291 to define PRC specific error codes that can be returned for 1292 policy installation. This allows efficient debugging of PIB 1293 implementations." 1295 PIB-INDEX { frwkCompLimitsPrid } 1296 UNIQUENESS { frwkCompLimitsComponent, 1297 frwkCompLimitsAttrPos, 1298 frwkCompLimitsNegation, 1299 frwkCompLimitsType, 1301 Framework Policy Information Base January 2002 1303 frwkCompLimitsSubType, 1304 frwkCompLimitsGuidance } 1306 ::= { frwkCompLimitsTable 1 } 1308 FrwkCompLimitsEntry ::= SEQUENCE { 1309 frwkCompLimitsPrid InstanceId, 1310 frwkCompLimitsComponent PrcIdentifier, 1311 frwkCompLimitsAttrPos AttrIdentifier, 1312 frwkCompLimitsNegation TruthValue, 1313 frwkCompLimitsType Unsigned32, 1314 frwkCompLimitsSubType Unsigned32, 1315 frwkCompLimitsGuidance OCTET STRING 1316 } 1318 frwkCompLimitsPrid OBJECT-TYPE 1319 SYNTAX InstanceId 1320 STATUS current 1321 DESCRIPTION 1322 "An arbitrary integer index that uniquely identifies an 1323 instance of the frwkCompLimits class." 1325 ::= { frwkCompLimitsEntry 1 } 1327 frwkCompLimitsComponent OBJECT-TYPE 1328 SYNTAX PrcIdentifier 1329 STATUS current 1330 DESCRIPTION 1331 "The value is the OID of a PRC (the table entry) which is 1332 supported in some limited fashion or contains an attribute 1333 that is supported in some limited fashion with regard to 1334 it's definition in the associated PIB module. The same OID 1335 may appear in the table several times, once for each 1336 implementation limitation acknowledged by the device." 1338 ::= { frwkCompLimitsEntry 2 } 1340 frwkCompLimitsAttrPos OBJECT-TYPE 1341 SYNTAX AttrIdentifier 1342 STATUS current 1343 DESCRIPTION 1344 "The relative position of the attribute within the PRC 1345 specified by the frwkCompLimitsComponent. A value of 1 would 1346 represent the first columnar object in the PRC and a value 1347 of N would represent the Nth columnar object in the PRC. A 1348 NULL value indicates that the limit applies to the PRC 1349 itself and not to a specific attribute." 1351 ::= { frwkCompLimitsEntry 3 } 1353 Framework Policy Information Base January 2002 1355 frwkCompLimitsNegation OBJECT-TYPE 1356 SYNTAX TruthValue 1357 STATUS current 1358 DESCRIPTION 1359 "A boolean value ,if TRUE, negates the component limit 1360 exported." 1362 ::= { frwkCompLimitsEntry 4 } 1364 frwkCompLimitsType OBJECT-TYPE 1365 SYNTAX Unsigned32 { 1366 priSpaceLimited(1), 1367 attrValueSupLimited(2), 1368 attrEnumSupLimited(3), 1369 attrLengthLimited(4), 1370 prcLimitedNotify(5) 1371 } 1372 STATUS current 1373 DESCRIPTION 1374 "A value describing an implementation limitation for the 1375 device related to the PRC or PRC attribute identified by 1376 the frwkCompLimitsComponent and the frwkCompLimitsAttrPos 1377 attributes in this class instance. 1379 Values for this object are one of the following: 1381 priSpaceLimited(1) - No more instances than that specified 1382 by the guidance value may be installed in the given class. 1383 The component identified MUST be a valid PRC. The SubType 1384 used MUST be valueOnly(9). 1386 attrValueSupLimited(2) - Limited values are acceptable for 1387 the identified component. The component identified MUST be a 1388 valid PRC attribute. The guidance OCTET STRING will be 1389 decoded according to the attribute type. 1391 attrEnumSupLimited(3) - Limited enumeration values are legal 1392 for the identified component. The attribute identified MUST 1393 be a valid enum type. 1395 attrLengthLimited(4) - The length of the specified 1396 value for the identified component is limited. The component 1397 identified MUST be a valid PRC attribute of base-type OCTET 1398 STRING. 1400 prcLimitedNotify (5) - The component is currently limited 1401 for use by request or report messages prohibiting decision 1402 installation. The component identified must be a valid PRC." 1404 ::= { frwkCompLimitsEntry 5 } 1406 Framework Policy Information Base January 2002 1408 frwkCompLimitsSubType OBJECT-TYPE 1409 SYNTAX Unsigned32 { 1410 none(1), 1411 lengthMin(2), 1412 lengthMax(3), 1413 rangeMin(4), 1414 rangeMax(5), 1415 enumMin(6), 1416 enumMax(7), 1417 enumOnly(8), 1418 valueOnly(9), 1419 bitMask(10) 1420 } 1421 STATUS current 1422 DESCRIPTION 1423 "This object indicates the type of guidance related 1424 to the noted limitation (as indicated by the 1425 frwkCompLimitsType attribute) that is provided 1426 in the frwkCompLimitsGuidance attribute. 1428 A value of 'none(1)' means that no additional 1429 guidance is provided for the noted limitation type. 1431 A value of 'lengthMin(2)' means that the guidance 1432 attribute provides data related to the minimum 1433 acceptable length for the value of the identified 1434 component. A corresponding class instance 1435 specifying the 'lengthMax(3)' value is required 1436 in conjunction with this sub-type. 1438 A value of 'lengthMax(3)' means that the guidance 1439 attribute provides data related to the maximum 1440 acceptable length for the value of the identified 1441 component. A corresponding class instance 1442 specifying the 'lengthMin(2)' value is required 1443 in conjunction with this sub-type. 1445 A value of 'rangeMin(4)' means that the guidance 1446 attribute provides data related to the lower bound 1447 of the range for the value of the identified 1448 component. A corresponding class instance 1449 specifying the 'rangeMax(5)' value is required 1450 in conjunction with this sub-type. 1452 A value of 'rangeMax(5)' means that the guidance 1453 attribute provides data related to the upper bound 1454 of the range for the value of the identified 1455 component. A corresponding class instance 1456 specifying the 'rangeMin(4)' value is required 1457 in conjunction with this sub-type. 1459 A value of 'enumMin(6)' means that the guidance 1460 attribute provides data related to the lowest 1462 Framework Policy Information Base January 2002 1464 enumeration acceptable for the value of the 1465 identified component. A corresponding 1466 class instance specifying the 'enumMax(7)' 1467 value is required in conjunction with this sub-type. 1469 A value of 'enumMax(7)' means that the guidance 1470 attribute provides data related to the largest 1471 enumeration acceptable for the value of the 1472 identified component. A corresponding 1473 class instance specifying the 'enumMin(6)' 1474 value is required in conjunction with this sub-type. 1476 A value of 'enumOnly(8)' means that the guidance 1477 attribute provides data related to a single 1478 enumeration acceptable for the value of the 1479 identified component. 1481 A value of 'valueOnly(9)' means that the guidance 1482 attribute provides data related to a single 1483 value that is acceptable for the identified 1484 component. 1486 A value of 'bitMask(10)' means that the guidance 1487 attribute is a bit mask such that all the combinations of 1488 bits set in the bitmask are acceptable values for the 1489 identified component which should be an attribute of type 1490 'BITS'. 1492 For example, an implementation of the frwkIpFilter class may 1493 be limited in several ways, such as address mask, protocol 1494 and Layer 4 port options. These limitations could be 1495 exported using this table with the following instances: 1497 Component Type Sub-Type Guidance 1498 ------------------------------------------------------------ 1499 DstPrefixLength attrValueSupLimited valueOnly 24 1500 SrcPrefixLength attrValueSupLimited valueOnly 24 1501 Protocol attrValueSupLimited rangeMin 10 1502 Protocol attrValueSupLimited rangeMax 20 1504 The above entries describe a number of limitations that 1505 may be in effect for the frwkIpFilter class on a given 1506 device. The limitations include restrictions on acceptable 1507 values for certain attributes. 1509 Also, an implementation of a PRC may be limited in the ways 1510 it can be accessed. For instance, for a fictitious PRC 1511 dscpMapEntry, which has a PIB-ACCESS of 'install-notify': 1513 Component Type SubType Guidance 1514 ------------------------------------------------------------ 1515 dscpMapEntry prcLimitedNotify none zero-length string." 1517 Framework Policy Information Base January 2002 1519 ::= { frwkCompLimitsEntry 6 } 1521 frwkCompLimitsGuidance OBJECT-TYPE 1522 SYNTAX OCTET STRING 1523 STATUS current 1524 DESCRIPTION 1525 "A value used to convey additional information related 1526 to the implementation limitation. Note that a guidance 1527 value will not necessarily be provided for all exported 1528 limitations. If a guidance value is not provided, the 1529 value must be a zero-length string. 1531 The format of the guidance value, if one is present as 1532 indicated by the frwkCompLimitsSubType attribute, 1533 is described by the following table. Note that the 1534 type of guidance value is dictated by the type of the 1535 component whose limitation is being exported, interpreted 1536 in the context of the frwkCompLimitsType and 1537 frwkCompLimitsSubType values. 1539 Note that numbers are encoded in network byte order. 1541 Base Type Value 1542 --------- ----- 1543 Unsigned32/Integer32 32-bit value. 1544 Unsigned64/Integer64 64-bit Value. 1545 OCTET STRING octets of data. 1546 OID 32-bit OID components. 1547 BITS Binary octets of length same as 1548 Component specified." 1550 ::= { frwkCompLimitsEntry 7 } 1552 -- 1553 -- Complete Reference specification table 1554 -- 1556 frwkReferenceTable OBJECT-TYPE 1557 SYNTAX SEQUENCE OF FrwkReferenceEntry 1558 PIB-ACCESS install-notify 1559 STATUS current 1560 DESCRIPTION 1561 "Each instance of this class specifies a reference to a PRI 1562 in a specific PIB context (handle) for a specific client- 1563 type." 1565 ::= { frwkBasePibClasses 5 } 1567 Framework Policy Information Base January 2002 1569 frwkReferenceEntry OBJECT-TYPE 1570 SYNTAX FrwkReferenceEntry 1571 STATUS current 1572 DESCRIPTION 1573 "Entry specification for the frwkReferenceTable." 1575 PIB-INDEX { frwkReferencePrid } 1576 UNIQUENESS { } 1578 ::= { frwkReferenceTable 1 } 1580 FrwkReferenceEntry ::= SEQUENCE { 1581 frwkReferencePrid InstanceId, 1582 frwkReferenceClientType ClientType, 1583 frwkReferenceClientHandle ClientHandle, 1584 frwkReferenceInstance Prid 1585 } 1587 frwkReferencePrid OBJECT-TYPE 1588 SYNTAX InstanceId 1589 STATUS current 1590 DESCRIPTION 1591 "An arbitrary integer index that uniquely identifies an 1592 instance of the frwkReference class." 1594 ::= { frwkReferenceEntry 1 } 1596 frwkReferenceClientType OBJECT-TYPE 1597 SYNTAX ClientType 1598 STATUS current 1599 DESCRIPTION 1600 "Is unused if set to zero else specifies a client-type for 1601 which the reference is to be interpreted. This non-zero 1602 client-type must be activated explicitly via a separate 1603 COPS client-open else this attribute is not valid." 1605 ::= { frwkReferenceEntry 2 } 1607 frwkReferenceClientHandle OBJECT-TYPE 1608 SYNTAX ClientHandle 1609 STATUS current 1610 DESCRIPTION 1611 "Must be set to specify a valid client-handle in the scope 1612 of the client-type specified." 1614 ::= { frwkReferenceEntry 3 } 1616 Framework Policy Information Base January 2002 1618 frwkReferenceInstance OBJECT-TYPE 1619 SYNTAX Prid 1620 STATUS current 1621 DESCRIPTION 1622 "References a PRI in the context identified by 1623 frwkReferenceClientHandle for client-type identified by 1624 frwkReferenceClientType." 1626 ::= { frwkReferenceEntry 4 } 1628 -- 1629 -- Error specification table 1630 -- 1632 frwkErrorTable OBJECT-TYPE 1633 SYNTAX SEQUENCE OF FrwkErrorEntry 1634 PIB-ACCESS install 1635 STATUS current 1636 DESCRIPTION 1637 "Each instance of this class specifies a class specific 1638 error object. Instances of this table are transient." 1640 ::= { frwkBasePibClasses 6 } 1642 frwkErrorEntry OBJECT-TYPE 1643 SYNTAX FrwkErrorEntry 1644 STATUS current 1645 DESCRIPTION 1646 "Entry specification for the frwkErrorTable." 1648 PIB-INDEX { frwkErrorPrid } 1649 UNIQUENESS { } 1651 ::= { frwkErrorTable 1 } 1653 FrwkErrorEntry ::= SEQUENCE { 1654 frwkErrorPrid InstanceId, 1655 frwkErrorCode Unsigned32, 1656 frwkErrorSubCode Unsigned32, 1657 frwkErrorPrc PrcIdentifier, 1658 frwkErrorInstance InstanceId 1659 } 1661 frwkErrorPrid OBJECT-TYPE 1662 SYNTAX InstanceId 1663 STATUS current 1664 DESCRIPTION 1665 "An arbitrary integer index that uniquely identifies an 1666 instance of the frwkError class." 1668 ::= { frwkErrorEntry 1 } 1670 Framework Policy Information Base January 2002 1672 frwkErrorCode OBJECT-TYPE 1673 SYNTAX Unsigned32 (0..65535) 1674 STATUS current 1675 DESCRIPTION 1676 "Error code defined in [COPS-PR] CPERR object." 1678 ::= { frwkErrorEntry 2 } 1680 frwkErrorSubCode OBJECT-TYPE 1681 SYNTAX Unsigned32 (0..65535) 1682 STATUS current 1683 DESCRIPTION 1684 "The class-specific error object is used to communicate 1685 errors relating to specific PRCs." 1687 ::= { frwkErrorEntry 3 } 1689 frwkErrorPrc OBJECT-TYPE 1690 SYNTAX PrcIdentifier 1691 STATUS current 1692 DESCRIPTION 1693 "The PRC due to which the error specified by codes 1694 (frwkErrorCode , frwkErrorSubCode) occurred." 1696 ::= { frwkErrorEntry 4 } 1698 frwkErrorInstance OBJECT-TYPE 1699 SYNTAX InstanceId 1700 STATUS current 1701 DESCRIPTION 1702 "The PRI of the identified PRC (frwkErrorPrc) due to which 1703 the error specified by codes (frwkErrorCode , 1704 frwkErrorSubCode) occurred. Must be set to zero if unused." 1706 ::= { frwkErrorEntry 5 } 1708 -- 1709 -- The device interface capabilities and role combo classes group 1710 -- 1712 frwkDeviceCapClasses 1713 OBJECT IDENTIFIER ::= { frameworkPib 2 } 1715 Framework Policy Information Base January 2002 1717 -- 1718 -- Interface Capability Set Table 1719 -- 1721 frwkIfCapSetTable OBJECT-TYPE 1722 SYNTAX SEQUENCE OF FrwkIfCapSetEntry 1723 PIB-ACCESS notify 1724 STATUS current 1725 DESCRIPTION 1726 "This class describes the interfaces that exist on the 1727 device. Associated with each interface is a set of 1728 capabilities. The capability set is given a unique name that 1729 identifies the interface type. These capabilities are used 1730 by the PDP to determine policy information to be associated 1731 with interfaces of this type." 1733 ::= { frwkDeviceCapClasses 1 } 1735 frwkIfCapSetEntry OBJECT-TYPE 1736 SYNTAX FrwkIfCapSetEntry 1737 STATUS current 1738 DESCRIPTION 1739 "An instance of this class describes the characteristics 1740 of a type of an interface." 1742 PIB-INDEX { frwkIfCapSetPrid } 1743 UNIQUENESS { frwkIfCapSetName, 1744 frwkIfCapSetCapability } 1746 ::= { frwkIfCapSetTable 1 } 1748 FrwkIfCapSetEntry ::= SEQUENCE { 1749 frwkIfCapSetPrid InstanceId, 1750 frwkIfCapSetName SnmpAdminString, 1751 frwkIfCapSetCapability Prid 1752 } 1754 frwkIfCapSetPrid OBJECT-TYPE 1755 SYNTAX InstanceId 1756 STATUS current 1757 DESCRIPTION 1758 "An arbitrary integer index that uniquely identifies a 1759 instance of the class." 1761 ::= { frwkIfCapSetEntry 1 } 1763 frwkIfCapSetName OBJECT-TYPE 1764 SYNTAX SnmpAdminString 1765 STATUS current 1766 DESCRIPTION 1768 Framework Policy Information Base January 2002 1770 "The name for the capability set. The capability set name 1771 is the unique identifier of an interface type." 1773 ::= { frwkIfCapSetEntry 2 } 1775 frwkIfCapSetCapability OBJECT-TYPE 1776 SYNTAX Prid 1777 STATUS current 1778 DESCRIPTION 1779 "The complete PRC OID and instance identifier specifying the 1780 capability PRC instance for the interface." 1782 ::= { frwkIfCapSetEntry 3 } 1784 -- 1785 -- Interface and Role Combination Tables 1786 -- 1788 frwkRoleComboTable OBJECT-TYPE 1789 SYNTAX SEQUENCE OF FrwkRoleComboEntry 1790 PIB-ACCESS install-notify 1791 STATUS current 1792 DESCRIPTION 1793 "This is an abstract PRC that may be extended or referenced 1794 to enumerate the role combinations, capability set names 1795 assigned to any interface on a PEP. The identification of 1796 the interface is to be defined by its extensions or 1797 referencing PRCs." 1799 ::= { frwkDeviceCapClasses 2 } 1801 frwkRoleComboEntry OBJECT-TYPE 1802 SYNTAX FrwkRoleComboEntry 1803 STATUS current 1804 DESCRIPTION 1805 "An instance of this class describes one association of an 1806 interface to a role-combination and capability set name . 1807 Note that an interface can have multiple associations. This 1808 constraint is controlled by the extending or referencing 1809 PRC's uniqueness clause." 1811 PIB-INDEX { frwkRoleComboPrid } 1812 UNIQUENESS { } 1814 ::= { frwkRoleComboTable 1 } 1816 FrwkRoleComboEntry ::= SEQUENCE { 1817 frwkRoleComboPrid InstanceId, 1819 Framework Policy Information Base January 2002 1821 frwkRoleComboRoles RoleCombination, 1822 frwkRoleComboCapSetName SnmpAdminString 1823 } 1825 frwkRoleComboPrid OBJECT-TYPE 1826 SYNTAX InstanceId 1827 STATUS current 1828 DESCRIPTION 1829 "An arbitrary integer index that uniquely identifies an 1830 instance of the class." 1832 ::= { frwkRoleComboEntry 1 } 1834 frwkRoleComboRoles OBJECT-TYPE 1835 SYNTAX RoleCombination 1836 STATUS current 1837 DESCRIPTION 1838 "The role combination assigned to a specific interface." 1840 ::= { frwkRoleComboEntry 2 } 1842 frwkRoleComboCapSetName OBJECT-TYPE 1843 SYNTAX SnmpAdminString 1844 STATUS current 1845 DESCRIPTION 1846 "The name of the interface capability set associated with 1847 the Role Combination specified in frwkRoleComboRoles. 1848 This name must exist in frwkIfCapSetTable." 1850 ::= { frwkRoleComboEntry 3 } 1852 -- 1853 -- Interface, Role Combinatrion association via IfIndex 1854 -- 1856 frwkIfRoleComboTable OBJECT-TYPE 1857 SYNTAX SEQUENCE OF FrwkIfRoleComboEntry 1858 PIB-ACCESS install-notify 1859 STATUS current 1860 DESCRIPTION 1861 "This table enumerates the interface to role combination and 1862 IfCapSetName mapping for all policy managed interfaces of a 1863 device. Policy for an interface depends not only on the 1864 capability set of an interface but also on its roles. This 1865 table specifies all the tuples currently on 1867 the device" 1869 ::= { frwkDeviceCapClasses 3 } 1871 Framework Policy Information Base January 2002 1873 frwkIfRoleComboEntry OBJECT-TYPE 1874 SYNTAX FrwkIfRoleComboEntry 1875 STATUS current 1876 DESCRIPTION 1877 "An instance of this class describes the association of 1878 a interface to an IfCapSetName and a role combination. 1879 Note that a IfCapSetName can have multiple role combinations 1880 assigned to it, but an IfIndex can have only one role 1881 combination associated." 1883 EXTENDS { frwkRoleComboEntry } 1884 UNIQUENESS { frwkIfRoleComboIfIndex, 1885 frwkRoleComboCapSetName } 1887 ::= { frwkIfRoleComboTable 1 } 1889 FrwkIfRoleComboEntry ::= SEQUENCE { 1890 frwkIfRoleComboIfIndex InterfaceIndex 1891 } 1893 frwkIfRoleComboIfIndex OBJECT-TYPE 1894 SYNTAX InterfaceIndex 1895 STATUS current 1896 DESCRIPTION 1897 "The ifIndex value for which this conceptual row provides 1898 policy information via the use of role combination." 1900 ::= { frwkIfRoleComboEntry 1 } 1902 -- 1903 -- The Classification classes group 1904 -- 1906 frwkClassifierClasses 1907 OBJECT IDENTIFIER ::= { frameworkPib 3 } 1908 -- 1909 -- The Base Filter Table 1910 -- 1912 frwkBaseFilterTable OBJECT-TYPE 1913 SYNTAX SEQUENCE OF FrwkBaseFilterEntry 1914 PIB-ACCESS install 1915 STATUS current 1916 DESCRIPTION 1918 Framework Policy Information Base January 2002 1920 "The Base Filter class. A packet has to match all 1921 fields in an Filter. Wildcards may be specified for those 1922 fields that are not relevant." 1924 ::= { frwkClassifierClasses 1 } 1926 frwkBaseFilterEntry OBJECT-TYPE 1927 SYNTAX FrwkBaseFilterEntry 1928 STATUS current 1929 DESCRIPTION 1930 "An instance of the frwkBaseFilter class." 1932 PIB-INDEX { frwkBaseFilterPrid } 1934 ::= { frwkBaseFilterTable 1 } 1936 FrwkBaseFilterEntry ::= SEQUENCE { 1937 frwkBaseFilterPrid InstanceId, 1938 frwkBaseFilterNegation TruthValue 1939 } 1941 frwkBaseFilterPrid OBJECT-TYPE 1942 SYNTAX InstanceId 1943 STATUS current 1944 DESCRIPTION 1945 "An integer index to uniquely identify this Filter among all 1946 the Filters." 1948 ::= { frwkBaseFilterEntry 1 } 1950 frwkBaseFilterNegation OBJECT-TYPE 1951 SYNTAX TruthValue 1952 STATUS current 1953 DESCRIPTION 1954 "This attribute behaves like a logical NOT for the filter. 1955 If the packet matches this filter and the value of this 1956 attribute is true, the action associated with this filter 1957 is not applied to the packet. If the value of this 1958 attribute is false, then the action is applied to the 1959 packet." 1961 ::= { frwkBaseFilterEntry 2 } 1963 -- 1964 -- The IP Filter Table 1965 -- 1967 frwkIpFilterTable OBJECT-TYPE 1968 SYNTAX SEQUENCE OF FrwkIpFilterEntry 1970 Framework Policy Information Base January 2002 1972 PIB-ACCESS install 1973 STATUS current 1974 DESCRIPTION 1975 "Filter definitions. A packet has to match all fields in a 1976 filter. Wildcards may be specified for those fields that 1977 are not relevant." 1979 INSTALL-ERRORS { 1980 invalidDstL4PortData(1), 1981 invalidSrcL4PortData(2) 1982 } 1983 ::= { frwkClassifierClasses 2 } 1985 frwkIpFilterEntry OBJECT-TYPE 1986 SYNTAX FrwkIpFilterEntry 1987 STATUS current 1988 DESCRIPTION 1989 "An instance of the frwkIpFilter class." 1991 EXTENDS { frwkBaseFilterEntry } 1992 UNIQUENESS { frwkBaseFilterNegation, 1993 frwkIpFilterAddrType, 1994 frwkIpFilterDstAddr, 1995 frwkIpFilterDstPrefixLength, 1996 frwkIpFilterSrcAddr, 1997 frwkIpFilterSrcPrefixLength, 1998 frwkIpFilterDscp, 1999 frwkIpFilterFlowId, 2000 frwkIpFilterProtocol, 2001 frwkIpFilterDstL4PortMin, 2002 frwkIpFilterDstL4PortMax, 2003 frwkIpFilterSrcL4PortMin, 2004 frwkIpFilterSrcL4PortMax } 2006 ::= { frwkIpFilterTable 1 } 2008 FrwkIpFilterEntry ::= SEQUENCE { 2009 frwkIpFilterAddrType InetAddressType, 2010 frwkIpFilterDstAddr InetAddress, 2011 frwkIpFilterDstPrefixLength InetAddressPrefixLength, 2012 frwkIpFilterSrcAddr InetAddress, 2013 frwkIpFilterSrcPrefixLength InetAddressPrefixLength, 2014 frwkIpFilterDscp DscpOrAny, 2015 frwkIpFilterFlowId Unsigned32, 2016 frwkIpFilterProtocol Integer32, 2017 frwkIpFilterDstL4PortMin InetPortNumber, 2018 frwkIpFilterDstL4PortMax InetPortNumber, 2019 frwkIpFilterSrcL4PortMin InetPortNumber, 2020 frwkIpFilterSrcL4PortMax InetPortNumber 2021 } 2023 Framework Policy Information Base January 2002 2025 frwkIpFilterAddrType OBJECT-TYPE 2027 SYNTAX InetAddressType 2028 STATUS current 2029 DESCRIPTION 2030 "The address type enumeration value [INETADDR] to specify 2031 the type of the packet's IP address." 2033 ::= { frwkIpFilterEntry 1 } 2035 frwkIpFilterDstAddr OBJECT-TYPE 2037 SYNTAX InetAddress 2038 STATUS current 2039 DESCRIPTION 2040 "The IP address [INETADDR] to match against the packet's 2041 destination IP address. frwkIpFilterDstPrefixLength 2042 indicates the number of bits that are relevant. " 2044 ::= { frwkIpFilterEntry 2 } 2046 frwkIpFilterDstPrefixLength OBJECT-TYPE 2047 SYNTAX InetAddressPrefixLength 2048 STATUS current 2049 DESCRIPTION 2050 "The length of a mask for the matching of the destination 2051 IP address. Masks are constructed by setting bits in 2052 sequence from the most-significant bit downwards for 2053 frwkIpFilterDstPrefixLength bits length. All other bits in 2054 the mask, up to the number needed to fill the length of 2055 the address frwkIpFilterDstAddr are cleared to zero. A zero 2056 bit in the mask then means that the corresponding bit in 2057 the address always matches." 2059 ::= { frwkIpFilterEntry 3 } 2061 frwkIpFilterSrcAddr OBJECT-TYPE 2062 SYNTAX InetAddress 2063 STATUS current 2064 DESCRIPTION 2065 "The IP address to match against the packet's source IP 2066 address. frwkIpFilterSrcPrefixLength indicates the 2067 number of bits that are relevant. " 2069 ::= { frwkIpFilterEntry 4 } 2071 frwkIpFilterSrcPrefixLength OBJECT-TYPE 2072 SYNTAX InetAddressPrefixLength 2073 UNITS "bits" 2074 STATUS current 2076 Framework Policy Information Base January 2002 2078 DESCRIPTION 2079 "The length of a mask for the matching of the source IP 2080 address. Masks are constructed by setting bits in sequence 2081 from the most-significant bit downwards for 2082 frwkIpFilterSrcPrefixLength bits length. All other bits in 2083 the mask, up to the number needed to fill the length of 2084 the address frwkIpFilterSrcAddr are cleared to zero. A 2085 zero bit in the mask then means that the corresponding bit 2086 in the address always matches." 2088 ::= { frwkIpFilterEntry 5 } 2090 frwkIpFilterDscp OBJECT-TYPE 2091 SYNTAX DscpOrAny 2092 STATUS current 2093 DESCRIPTION 2094 "The value that the DSCP in the packet can have and 2095 match this filter. A value of -1 indicates that a specific 2096 DSCP value has not been defined and thus all DSCP values 2097 are considered a match." 2099 ::= { frwkIpFilterEntry 6 } 2101 frwkIpFilterFlowId OBJECT-TYPE 2102 SYNTAX Unsigned32 (0..1048575) 2103 STATUS current 2104 DESCRIPTION 2105 "The flow identifier in an IPv6 header." 2106 ::= { frwkIpFilterEntry 7 } 2108 frwkIpFilterProtocol OBJECT-TYPE 2109 SYNTAX Integer32 (-1 | 0..255) 2110 STATUS current 2111 DESCRIPTION 2112 "The IP protocol to match against the packet's protocol. 2113 A value of -1 means match all." 2115 ::= { frwkIpFilterEntry 8 } 2117 frwkIpFilterDstL4PortMin OBJECT-TYPE 2118 SYNTAX InetPortNumber 2119 STATUS current 2120 DESCRIPTION 2121 "The minimum value that the packet's layer 4 destination 2122 port number can have and match this filter. This value must 2123 be equal to or lesser that the value specified for this 2124 filter in frwkIpFilterDstL4PortMax." 2126 ::= { frwkIpFilterEntry 9 } 2128 frwkIpFilterDstL4PortMax OBJECT-TYPE 2129 SYNTAX InetPortNumber 2131 Framework Policy Information Base January 2002 2133 STATUS current 2134 DESCRIPTION 2135 "The maximum value that the packet's layer 4 destination 2136 port number can have and match this filter. This value must 2137 be equal to or greater that the value specified for this 2138 filter in frwkIpFilterDstL4PortMin." 2140 ::= { frwkIpFilterEntry 10 } 2142 frwkIpFilterSrcL4PortMin OBJECT-TYPE 2143 SYNTAX InetPortNumber 2144 STATUS current 2145 DESCRIPTION 2146 "The minimum value that the packet's layer 4 source port 2147 number can have and match this filter. This value must 2148 be equal to or lesser that the value specified for this 2149 filter in frwkIpFilterSrcL4PortMax." 2151 ::= { frwkIpFilterEntry 11 } 2153 frwkIpFilterSrcL4PortMax OBJECT-TYPE 2154 SYNTAX InetPortNumber 2155 STATUS current 2156 DESCRIPTION 2157 "The maximum value that the packet's layer 4 source port 2158 number can have and match this filter. This value must be 2159 equal to or greater that the value specified for this filter 2160 in frwkIpFilterSrcL4PortMin." 2162 ::= { frwkIpFilterEntry 12 } 2164 -- 2165 -- The IEEE 802 Filter Table 2166 -- 2168 -- The IEEE 802 Filter Table supports the specification of IEEE 2169 -- 802-based [802] (e.g., 802.3) information that is used to perform 2170 -- traffic classification. 2171 -- 2173 frwk802FilterTable OBJECT-TYPE 2174 SYNTAX SEQUENCE OF Frwk802FilterEntry 2175 PIB-ACCESS install 2176 STATUS current 2177 DESCRIPTION 2178 "IEEE 802-based filter definitions. A class that contains 2179 attributes of IEEE 802 (e.g., 802.3) traffic that form 2180 filters that are used to perform traffic classification." 2182 Framework Policy Information Base January 2002 2184 ::= { frwkClassifierClasses 3 } 2186 frwk802FilterEntry OBJECT-TYPE 2187 SYNTAX Frwk802FilterEntry 2188 STATUS current 2189 DESCRIPTION 2190 "IEEE 802-based filter definitions. An entry specifies 2191 (potentially) several distinct matching components. Each 2192 component is tested against the data in a frame 2193 individually. An overall match occurs when all of the 2194 individual components match the data they are compared 2195 against in the frame being processed. A failure of any 2196 one test causes the overall match to fail. 2198 Wildcards may be specified for those fields that are not 2199 relevant." 2201 EXTENDS { frwkBaseFilterEntry } 2202 UNIQUENESS { frwkBaseFilterNegation, 2203 frwk802FilterDstAddr, 2204 frwk802FilterDstAddrMask, 2205 frwk802FilterSrcAddr, 2206 frwk802FilterSrcAddrMask, 2207 frwk802FilterVlanId, 2208 frwk802FilterVlanTagRequired, 2209 frwk802FilterEtherType, 2210 frwk802FilterUserPriority } 2212 ::= { frwk802FilterTable 1 } 2214 Frwk802FilterEntry ::= SEQUENCE { 2215 frwk802FilterDstAddr PhysAddress, 2216 frwk802FilterDstAddrMask PhysAddress, 2217 frwk802FilterSrcAddr PhysAddress, 2218 frwk802FilterSrcAddrMask PhysAddress, 2219 frwk802FilterVlanId Integer32, 2220 frwk802FilterVlanTagRequired Unsigned32, 2221 frwk802FilterEtherType Integer32, 2222 frwk802FilterUserPriority BITS 2223 } 2225 frwk802FilterDstAddr OBJECT-TYPE 2226 SYNTAX PhysAddress 2227 STATUS current 2229 DESCRIPTION 2230 "The 802 address against which the 802 DA of incoming 2231 traffic streams will be compared. Frames whose 802 DA 2232 matches the physical address specified by this object, 2233 taking into account address wildcarding as specified by the 2235 Framework Policy Information Base January 2002 2237 frwk802FilterDstAddrMask object, are potentially subject to 2238 the processing guidelines that are associated with this 2239 entry through the related action class." 2241 ::= { frwk802FilterEntry 1 } 2243 frwk802FilterDstAddrMask OBJECT-TYPE 2244 SYNTAX PhysAddress 2245 STATUS current 2246 DESCRIPTION 2247 "This object specifies the bits in a 802 destination address 2248 that should be considered when performing a 802 DA 2249 comparison against the address specified in the 2250 frwk802FilterDstAddr object. 2252 The value of this object represents a mask that is logically 2253 and'ed with the 802 DA in received frames to derive the 2254 value to be compared against the frwk802FilterDstAddr 2255 address. A zero bit in the mask thus means that the 2256 corresponding bit in the address always matches. The 2257 frwk802FilterDstAddr value must also be masked using this 2258 value prior to any comparisons. 2260 The length of this object in octets must equal the length in 2261 octets of the frwk802FilterDstAddr. Note that a mask with no 2262 bits set (i.e., all zeroes) effectively wildcards the 2263 frwk802FilterDstAddr object." 2265 ::= { frwk802FilterEntry 2 } 2267 frwk802FilterSrcAddr OBJECT-TYPE 2268 SYNTAX PhysAddress 2269 STATUS current 2270 DESCRIPTION 2271 "The 802 MAC address against which the 802 MAC SA of 2272 incoming traffic streams will be compared. Frames whose 802 2273 MAC SA matches the physical address specified by this 2274 object, taking into account address wildcarding as specified 2275 by the frwk802FilterSrcAddrMask object, are potentially 2276 subject to the processing guidelines that are associated 2277 with this entry through the related action class." 2279 ::= { frwk802FilterEntry 3 } 2281 frwk802FilterSrcAddrMask OBJECT-TYPE 2282 SYNTAX PhysAddress 2283 STATUS current 2284 DESCRIPTION 2285 "This object specifies the bits in a 802 MAC source address 2286 that should be considered when performing a 802 MAC SA 2287 comparison against the address specified in the 2289 Framework Policy Information Base January 2002 2291 frwk802FilterSrcAddr object. 2293 The value of this object represents a mask that is logically 2294 and'ed with the 802 MAC SA in received frames to derive the 2295 value to be compared against the frwk802FilterSrcAddr 2296 address. A zero bit in the mask thus means that the 2297 corresponding bit in the address always matches. The 2298 frwk802FilterSrcAddr value must also be masked using this 2299 value prior to any comparisons. 2301 The length of this object in octets must equal the length in 2302 octets of the frwk802FilterSrcAddr. Note that a mask with no 2303 bits set (i.e., all zeroes) effectively wildcards the 2304 frwk802FilterSrcAddr object." 2306 ::= { frwk802FilterEntry 4 } 2308 frwk802FilterVlanId OBJECT-TYPE 2309 SYNTAX Integer32 (-1 | 1..4094) 2310 STATUS current 2311 DESCRIPTION 2312 "The VLAN ID (VID) that uniquely identifies a VLAN 2313 within the device. This VLAN may be known or unknown 2314 (i.e., traffic associated with this VID has not yet 2315 been seen by the device) at the time this entry 2316 is instantiated. 2318 Setting the frwk802FilterVlanId object to -1 indicates that 2319 VLAN data should not be considered during traffic 2320 classification." 2322 ::= { frwk802FilterEntry 5 } 2324 frwk802FilterVlanTagRequired OBJECT-TYPE 2325 SYNTAX Unsigned32 { 2326 taggedOnly(1), 2327 priorityTaggedPlus(2), 2328 untaggedOnly(3), 2329 ignoreTag(4) 2330 } 2331 STATUS current 2332 DESCRIPTION 2333 "This object indicates whether the presence of an 2334 IEEE 802.1Q VLAN tag in data link layer frames must 2335 be considered when determining if a given frame 2336 matches this 802 filter entry. 2338 A value of 'taggedOnly(1)' means that only frames 2339 containing a VLAN tag with a non-Null VID (i.e., a 2340 VID in the range 1..4094) will be considered a match. 2342 A value of 'priorityTaggedPlus(2)' means that only 2343 frames containing a VLAN tag, regardless of the value 2345 Framework Policy Information Base January 2002 2347 of the VID, will be considered a match. 2349 A value of 'untaggedOnly(3)' indicates that only 2350 untagged frames will match this filter component. 2352 The presence of a VLAN tag is not taken into 2353 consideration in terms of a match if the value is 2354 'ignoreTag(4)'." 2356 ::= { frwk802FilterEntry 6 } 2358 frwk802FilterEtherType OBJECT-TYPE 2359 SYNTAX Integer32 (-1 | 0..'ffff'h) 2360 STATUS current 2361 DESCRIPTION 2362 "This object specifies the value that will be compared 2363 against the value contained in the EtherType field of an 2364 IEEE 802 frame. Example settings would include 'IP' 2365 (0x0800), 'ARP' (0x0806) and 'IPX' (0x8137). 2367 Setting the frwk802FilterEtherTypeMin object to -1 indicates 2368 that EtherType data should not be considered during traffic 2369 classification. 2371 Note that the position of the EtherType field depends on 2372 the underlying frame format. For Ethernet-II encapsulation, 2373 the EtherType field follows the 802 MAC source address. For 2374 802.2 LLC/SNAP encapsulation, the EtherType value follows 2375 the Organization Code field in the 802.2 SNAP header. The 2376 value that is tested with regard to this filter component 2377 therefore depends on the data link layer frame format being 2378 used. If this 802 filter component is active when there is 2379 no EtherType field in a frame (e.g., 802.2 LLC), a match is 2380 implied." 2382 ::= { frwk802FilterEntry 7 } 2384 frwk802FilterUserPriority OBJECT-TYPE 2385 SYNTAX BITS { 2386 matchPriority0(0), 2387 matchPriority1(1), 2388 matchPriority2(2), 2389 matchPriority3(3), 2390 matchPriority4(4), 2391 matchPriority5(5), 2392 matchPriority6(6), 2393 matchPriority7(7) 2394 } 2395 STATUS current 2396 DESCRIPTION 2397 "The set of values, representing the potential range 2399 Framework Policy Information Base January 2002 2401 of user priority values, against which the value contained 2402 in the user priority field of a tagged 802.1 frame is 2403 compared. A test for equality is performed when determining 2404 if a match exists between the data in a data link layer 2405 frame and the value of this 802 filter component. Multiple 2406 values may be set at one time such that potentially several 2407 different user priority values may match this 802 filter 2408 component. 2410 Setting all of the bits that are associated with this 2411 object causes all user priority values to match this 2412 attribute. This essentially makes any comparisons 2413 with regard to user priority values unnecessary. Untagged 2414 frames are treated as an implicit match." 2416 ::= { frwk802FilterEntry 8 } 2418 -- 2419 -- The Internal label filter extension 2420 -- 2422 frwkILabelFilterTable OBJECT-TYPE 2423 SYNTAX SEQUENCE OF FrwkILabelFilterEntry 2424 PIB-ACCESS install 2425 STATUS current 2426 DESCRIPTION 2427 "Internal label filter Table. This PRC is used to achieve 2428 classification based on the internal flow label set by the 2429 PEP possibly after ingress classification to avoid 2430 re-classification at the egress interface on the same PEP." 2432 ::= { frwkClassifierClasses 4 } 2434 frwkILabelFilterEntry OBJECT-TYPE 2435 SYNTAX FrwkILabelFilterEntry 2436 STATUS current 2437 DESCRIPTION 2438 "Internal label filter entry definition." 2440 EXTENDS { frwkBaseFilterEntry } 2441 UNIQUENESS { frwkBaseFilterNegation, 2442 frwkILabelFilterILabel } 2444 ::= { frwkILabelFilterTable 1 } 2446 FrwkILabelFilterEntry ::= SEQUENCE { 2447 frwkILabelFilterILabel OCTET STRING 2448 } 2450 frwkILabelFilterILabel OBJECT-TYPE 2451 SYNTAX OCTET STRING 2452 STATUS current 2454 Framework Policy Information Base January 2002 2456 DESCRIPTION 2457 "The Label that this flow uses for differentiating traffic 2458 flows. The flow labeling is meant for network device 2459 internal usage. A value of zero length string matches all 2460 internal labels." 2461 ::= { frwkILabelFilterEntry 1 } 2463 -- 2464 -- The Marker classes group 2465 -- 2467 frwkMarkerClasses 2468 OBJECT IDENTIFIER ::= { frameworkPib 4 } 2469 -- 2470 -- The 802 Marker Table 2471 -- 2473 frwk802MarkerTable OBJECT-TYPE 2474 SYNTAX SEQUENCE OF Frwk802MarkerEntry 2475 PIB-ACCESS install 2476 STATUS current 2477 DESCRIPTION 2478 "The 802 Marker class. An 802 packet can be marked with the 2479 specified VLAN id, priority level." 2481 ::= { frwkMarkerClasses 1 } 2483 frwk802MarkerEntry OBJECT-TYPE 2484 SYNTAX Frwk802MarkerEntry 2485 STATUS current 2486 DESCRIPTION 2487 "frwk802Marker entry definition." 2489 PIB-INDEX { frwk802MarkerPrid } 2490 UNIQUENESS { frwk802MarkerVlanId, 2491 frwk802MarkerPriority } 2493 ::= { frwk802MarkerTable 1 } 2495 Frwk802MarkerEntry::= SEQUENCE { 2496 frwk802MarkerPrid InstanceId, 2497 frwk802MarkerVlanId Unsigned32, 2498 frwk802MarkerPriority Unsigned32 2499 } 2501 frwk802MarkerPrid OBJECT-TYPE 2502 SYNTAX InstanceId 2504 Framework Policy Information Base January 2002 2506 STATUS current 2507 DESCRIPTION 2508 "An integer index to uniquely identify this 802 Marker." 2510 ::= { frwk802MarkerEntry 1 } 2512 frwk802MarkerVlanId OBJECT-TYPE 2513 SYNTAX Unsigned32 (1..4094) 2514 STATUS current 2515 DESCRIPTION 2516 "The VLAN ID (VID) that uniquely identifies a VLAN within 2517 the device." 2519 ::= { frwk802MarkerEntry 2 } 2521 frwk802MarkerPriority OBJECT-TYPE 2522 SYNTAX Unsigned32 (0..7) 2523 STATUS current 2524 DESCRIPTION 2525 "The user priority field of a tagged 802.1 frame." 2527 ::= { frwk802MarkerEntry 3 } 2529 -- 2530 -- The Internal Label Marker Table 2531 -- 2533 frwkILabelMarkerTable OBJECT-TYPE 2534 SYNTAX SEQUENCE OF FrwkILabelMarkerEntry 2535 PIB-ACCESS install 2536 STATUS current 2537 DESCRIPTION 2538 "The Internal Label Marker class. A flow in a PEP can be 2539 marked with an internal label using this PRC." 2541 ::= { frwkMarkerClasses 2 } 2543 frwkILabelMarkerEntry OBJECT-TYPE 2544 SYNTAX FrwkILabelMarkerEntry 2545 STATUS current 2546 DESCRIPTION 2547 "frwkILabelkMarker entry definition." 2549 PIB-INDEX { frwkILabelMarkerPrid } 2550 UNIQUENESS { frwkILabelMarkerILabel } 2552 ::= { frwkILabelMarkerEntry 1 } 2554 FrwkILabelMarkerEntry::= SEQUENCE { 2556 Framework Policy Information Base January 2002 2558 frwkILabelMarkerPrid InstanceId, 2559 frwkILabelMarkerILabel OCTET STRING 2560 } 2562 frwkILabelMarkerPrid OBJECT-TYPE 2563 SYNTAX InstanceId 2564 STATUS current 2565 DESCRIPTION 2566 "An integer index to uniquely identify this Label Marker." 2568 ::= { frwkILabelMarkerEntry 1 } 2570 frwkILabelMarkerILabel OBJECT-TYPE 2571 SYNTAX OCTET STRING 2572 STATUS current 2573 DESCRIPTION 2574 "This internal label is implementation specific and may be 2575 used for other policy related functions like flow 2576 accounting purposes and/or other data path treatments." 2578 ::= { frwkILabelMarkerEntry 2 } 2580 -- 2581 -- Conformance Section 2582 -- 2584 frwkBasePibConformance 2585 OBJECT IDENTIFIER ::= { frameworkPib 4 } 2587 frwkBasePibCompliances 2588 OBJECT IDENTIFIER ::= { frwkBasePibConformance 1 } 2590 frwkBasePibGroups 2591 OBJECT IDENTIFIER ::= { frwkBasePibConformance 2 } 2593 frwkBasePibCompliance MODULE-COMPLIANCE 2594 STATUS current 2595 DESCRIPTION 2596 "Describes the requirements for conformance to the 2597 Framework PIB." 2599 MODULE -- this module 2600 MANDATORY-GROUPS { frwkPrcSupportGroup, 2601 frwkPibIncarnationGroup, 2602 frwkDeviceIdGroup, 2603 frwkCompLimitsGroup, 2604 frwkIfCapSetGroup, 2605 frwkRoleComboGroup, 2607 Framework Policy Information Base January 2002 2609 frwkIfRoleComboGroup } 2611 OBJECT frwkPibIncarnationLongevity 2612 PIB-MIN-ACCESS notify 2613 DESCRIPTION "Install support is not required." 2615 OBJECT frwkPibIncarnationTtl 2616 PIB-MIN-ACCESS notify 2617 DESCRIPTION "Install support is not required." 2619 OBJECT frwkPibIncarnationInCtxtSet 2620 PIB-MIN-ACCESS notify 2621 DESCRIPTION "Install support is not required." 2623 OBJECT frwkPibIncarnationFullState 2624 PIB-MIN-ACCESS notify 2625 DESCRIPTION "Install support is not required." 2627 GROUP frwkReferenceGroup 2628 DESCRIPTION 2629 "The frwkReferenceGroup is mandatory if referencing 2630 across PIB contexts for specific client-types is 2631 supported." 2633 GROUP frwkErrorGroup 2634 DESCRIPTION 2635 "The frwkErrorGroup is mandatory sending errors in 2636 decisions is required." 2638 GROUP frwkBaseFilterGroup 2639 DESCRIPTION 2640 "The frwkBaseFilterGroup is mandatory if filtering 2641 based on traffic components is supported." 2643 GROUP frwkIpFilterGroup 2644 DESCRIPTION 2645 "The frwkIpFilterGroup is mandatory if filtering 2646 based on IP traffic components is supported." 2648 GROUP frwk802FilterGroup 2649 DESCRIPTION 2650 "The frwk802FilterGroup is mandatory if filtering 2651 based on 802 traffic criteria is supported." 2653 GROUP frwkILabelFilterGroup 2654 DESCRIPTION 2655 "The frwkILabelFilterGroup is mandatory if filtering 2656 based on PEP internal label is supported." 2658 GROUP frwk802MarkerGroup 2659 DESCRIPTION 2660 "The frwk802MarkerGroup is mandatory if marking a packet 2662 Framework Policy Information Base January 2002 2664 with 802 traffic criteria is supported." 2666 GROUP frwkILabelMarkerGroup 2667 DESCRIPTION 2668 "The frwkILabelMarkerGroup is mandatory if marking a 2669 flow with internal labels is supported." 2671 ::= { frwkBasePibCompliances 1 } 2673 frwkPrcSupportGroup OBJECT-GROUP 2674 OBJECTS { 2675 frwkPrcSupportSupportedPrc, 2676 frwkPrcSupportSupportedAttrs } 2677 STATUS current 2678 DESCRIPTION 2679 "Objects from the frwkPrcSupportTable." 2681 ::= { frwkBasePibGroups 1 } 2683 frwkPibIncarnationGroup OBJECT-GROUP 2684 OBJECTS { 2685 frwkPibIncarnationName, 2686 frwkPibIncarnationId, 2687 frwkPibIncarnationLongevity, 2688 frwkPibIncarnationTtl, 2689 frwkPibIncarnationActive, 2690 frwkPibIncarnationFullState 2691 } 2692 STATUS current 2693 DESCRIPTION 2694 "Objects from the frwkDevicePibIncarnationTable." 2696 ::= { frwkBasePibGroups 2 } 2698 frwkDeviceIdGroup OBJECT-GROUP 2699 OBJECTS { 2700 frwkDeviceIdDescr, 2701 frwkDeviceIdMaxMsg, 2702 frwkDeviceIdMaxContexts } 2703 STATUS current 2704 DESCRIPTION 2705 "Objects from the frwkDeviceIdTable." 2707 ::= { frwkBasePibGroups 3 } 2709 frwkCompLimitsGroup OBJECT-GROUP 2710 OBJECTS { 2711 frwkCompLimitsComponent, 2712 frwkCompLimitsAttrPos, 2713 frwkCompLimitsNegation, 2714 frwkCompLimitsType, 2715 frwkCompLimitsSubType, 2717 Framework Policy Information Base January 2002 2719 frwkCompLimitsGuidance } 2720 STATUS current 2721 DESCRIPTION 2722 "Objects from the frwkCompLimitsTable." 2724 ::= { frwkBasePibGroups 4 } 2726 frwkReferenceGroup OBJECT-GROUP 2727 OBJECTS { 2728 frwkReferenceClientType, 2729 frwkReferenceClientHandle, 2730 frwkReferencePrid, } 2731 STATUS current 2732 DESCRIPTION 2733 "Objects from the frwkReferenceTable." 2735 ::= { frwkBasePibGroups 5 } 2737 frwkErrorGroup OBJECT-GROUP 2738 OBJECTS { 2739 frwkErrorCode, 2740 frwkErrorSubCode, 2741 frwkErrorPrc, 2742 frwkErrorInstance } 2743 STATUS current 2744 DESCRIPTION 2745 "Objects from the frwkErrorTable." 2747 ::= { frwkBasePibGroups 6 } 2749 frwkIfCapSetGroup OBJECT-GROUP 2750 OBJECTS { 2751 frwkIfCapSetName, 2752 frwkIfCapSetCapability } 2753 STATUS current 2754 DESCRIPTION 2755 "Objects from the frwkIfCapSetTable." 2757 ::= { frwkBasePibGroups 7 } 2759 frwkRoleComboGroup OBJECT-GROUP 2760 OBJECTS { 2761 frwkRoleComboRoles, 2762 frwkRoleComboCapSetName } 2763 STATUS current 2764 DESCRIPTION 2765 "Objects from the frwkRoleComboTable." 2767 ::= { frwkBasePibGroups 8 } 2769 Framework Policy Information Base January 2002 2771 frwkIfRoleComboGroup OBJECT-GROUP 2772 OBJECTS { 2773 frwkIfRoleComboIfIndex } 2774 STATUS current 2775 DESCRIPTION 2776 "Objects from the frwkIfRoleComboTable." 2778 ::= { frwkBasePibGroups 9 } 2780 frwkBaseFilterGroup OBJECT-GROUP 2781 OBJECTS { 2782 frwkBaseFilterNegation } 2783 STATUS current 2784 DESCRIPTION 2785 "Objects from the frwkBaseFilterTable." 2787 ::= { frwkBasePibGroups 10 } 2789 frwkIpFilterGroup OBJECT-GROUP 2790 OBJECTS { 2791 frwkIpFilterAddrType, 2792 frwkIpFilterDstAddr, 2793 frwkIpFilterDstPrefixLength, 2794 frwkIpFilterSrcAddr, 2795 frwkIpFilterSrcPrefixLength, 2796 frwkIpFilterDscp, 2797 frwkIpFilterFlowId 2798 frwkIpFilterProtocol, 2799 frwkIpFilterDstL4PortMin, 2800 frwkIpFilterDstL4PortMax, 2801 frwkIpFilterSrcL4PortMin, 2802 frwkIpFilterSrcL4PortMax } 2803 STATUS current 2804 DESCRIPTION 2805 "Objects from the frwkIpFilterTable." 2807 ::= { frwkBasePibGroups 11 } 2809 frwk802FilterGroup OBJECT-GROUP 2810 OBJECTS { 2811 frwk802FilterDstAddr, 2812 frwk802FilterDstAddrMask, 2813 frwk802FilterSrcAddr, 2814 frwk802FilterSrcAddrMask, 2815 frwk802FilterVlanId, 2816 frwk802FilterVlanTagRequired, 2817 frwk802FilterEtherType, 2818 frwk802FilterUserPriority } 2819 STATUS current 2820 DESCRIPTION 2821 "Objects from the frwk802FilterTable." 2823 Framework Policy Information Base January 2002 2825 ::= { frwkBasePibGroups 12 } 2827 frwkILabelFilterGroup OBJECT-GROUP 2828 OBJECTS { 2829 FrwkILabelFilterILabel } 2830 STATUS current 2831 DESCRIPTION 2832 "Objects from the frwkILabelFilterTable." 2834 ::= { frwkBasePibGroups 13 } 2836 frwk802MarkerGroup OBJECT-GROUP 2837 OBJECTS { 2838 frwk802MarkerVlanId, 2839 frwk802MarkerPriority } 2840 STATUS current 2841 DESCRIPTION 2842 "Objects from the frwk802MarkerTable." 2844 ::= { frwkBasePibGroups 14 } 2846 frwkILabelMarkerGroup OBJECT-GROUP 2847 OBJECTS { 2848 FrwkILabelMarkerILabel } 2849 STATUS current 2850 DESCRIPTION 2851 "Objects from the frwkILabelMarkerTable." 2853 ::= { frwkBasePibGroups 15 } 2855 END 2857 Framework Policy Information Base January 2002 2859 6. Security Considerations 2861 It is clear that this PIB is used for configuration using [COPS-PR], 2862 and anything that can be configured can be misconfigured, with 2863 potentially disastrous effect. At this writing, no security holes 2864 have been identified beyond those that the COPS base protocol 2865 security is itself intended to address. These relate primarily to 2866 controlled access to sensitive information and the ability to 2867 configure a device - or which might result from operator error, 2868 which is beyond the scope of any security architecture. 2870 There are a number of provisioning classes defined in this PIB that 2871 have a PIB-ACCESS clause of install and install-notify (read- 2872 create). Such objects may be considered sensitive or vulnerable in 2873 some network environments. The support for "Install" or "Install- 2874 Notify" decisions sent over [COPS-PR] in a non-secure environment 2875 without proper protection can have a negative effect on network 2876 operations. There are a number of provisioning classes in this PIB 2877 that may contain information that may be sensitive from a business 2878 perspective, in that they may represent a customer's service 2879 contract or the filters that the service provider chooses to apply 2880 to a customer's ingress or egress traffic. There are no PRCs that 2881 are sensitive in their own right, such as passwords or monetary 2882 amounts. It may be important to control even "Notify"(read-only) 2883 access to these PRCs and possibly to even encrypt the values of 2884 these PRIs when sending them over the network via COPS-PR. The use 2885 of IPSEC between the PDP and the PEP, as described in [COPS], 2886 provides the necessary protection against security threats. However, 2887 even if the network itself is secure, there is no control as to who 2888 on the secure network is allowed to "Install/Notify" 2889 (read/change/create/delete) the PRIs in this PIB. 2891 It is then a customer/user responsibility to ensure that the PEP/PDP 2892 giving access to an instance of this PIB, is properly configured to 2893 give access to the PRIs only to those principals (users) that have 2894 legitimate rights to indeed "Install" or "Notify" (change/create/ 2895 delete) them. 2897 7. RFC Editor Considerations 2899 This document references [INETADDR] which is in the IESG last call 2900 stage. This document references it as an Internet Draft. Please use 2901 the corresponding RFC number prior to publishing of this document as 2902 a RFC. 2904 8. IANA Considerations 2906 This document describes the frameworkPib and frwkTcPib Policy 2907 Information Base (PIB) modules for standardization. An IANA assigned 2908 PIB number is requested for both [SPPI]. 2910 Framework Policy Information Base January 2002 2912 9. Author Information and Acknowledgments 2914 Michael Fine 2915 Cisco Systems, Inc. 2916 170 West Tasman Drive 2917 San Jose, CA 95134-1706 USA 2918 Phone: +1 408 527 8218 2919 Email: mfine@cisco.com 2921 Keith McCloghrie 2922 Cisco Systems, Inc. 2923 170 West Tasman Drive 2924 San Jose, CA 95134-1706 USA 2925 Phone: +1 408 526 5260 2926 Email: kzm@cisco.com 2928 John Seligson 2929 Nortel Networks, Inc. 2930 4401 Great America Parkway 2931 Santa Clara, CA 95054 USA 2932 Phone: +1 408 495 2992 2933 Email: jseligso@nortelnetworks.com 2935 Kwok Ho Chan 2936 Nortel Networks, Inc. 2937 600 Technology Park Drive 2938 Billerica, MA 01821 USA 2939 Phone: +1 978 288 8175 2940 Email: khchan@nortelnetworks.com 2942 Scott Hahn 2943 Intel Corp. 2944 2111 NE 25th Avenue 2945 Hillsboro, OR 97124 USA 2946 Phone: +1 503 264 8231 2947 Email: scott.hahn@intel.com 2949 Ravi Sahita 2950 Intel Corp. 2951 2111 NE 25th Avenue 2952 Hillsboro, OR 97124 USA 2953 Phone: +1 503 712 1554 2954 Email: ravi.sahita@intel.com 2956 Andrew Smith 2957 Allegro Networks 2958 6399 San Ignacio Ave. 2959 San Jose 2960 CA 95119 2961 FAX: 415 345 1827 2962 Email: andrew@allegronetworks.com 2964 Framework Policy Information Base January 2002 2966 Francis Reichmeyer 2967 PFN, Inc. 2968 University Park at MIT 2969 26 Landsdowne Street 2970 Cambridge, MA 02139 2971 Phone: +1 617 494 9980 2972 Email: franr@pfn.com 2974 Special thanks to Carol Bell and David Durham for their many 2975 significant comments. 2977 10. References 2979 [COPS] 2980 Boyle, J., Cohen, R., Durham, D., Herzog, S., Rajan, R., and 2981 A. Sastry, "The COPS (Common Open Policy Service) Protocol" 2982 RFC 2748, January 2000. 2984 [COPS-PR] 2985 K. Chan, D. Durham, S. Gai, S. Herzog, K. McCloghrie, 2986 F. Reichmeyer, J. Seligson, A. Smith, R. Yavatkar, "COPS Usage 2987 for Policy Provisioning," RFC 3084, March 2001. 2989 [SPPI] 2990 K. McCloghrie, M. Fine, J. Seligson, K. Chan, S. Hahn, 2991 R. Sahita, A. Smith, F. Reichmeyer, "Structure of Policy 2992 Provisioning Information," RFC 3159, August 2001. 2994 [RAP-FRAMEWORK] 2995 R. Yavatkar, D. Pendarakis, "A Framework for Policy-based 2996 Admission Control", RFC 2753, January 2000. 2998 [SNMP-SMI] 2999 K. McCloghrie, D. Perkins, J. Schoenwaelder, J. Case, M. Rose 3000 and S. Waldbusser, "Structure of Management Information 3001 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 3003 [INETADDR] 3004 M. Daniele, B. Haberman, S. Routhier and J. Schoenwaelder 3005 "Textual Conventions for Internet Network Addresses" 3006 draft-ietf-ops-rfc2851-update-06.txt, December 17, 2001 3008 [IFMIB] 3009 K. McCloghrie, F. Kastenholz, "The Interface Group MIB using 3010 SMIv2" RFC 2233, November 1977. 3012 [802] 3013 IEEE Standards for Local and Metropolitan Area Networks: 3014 Overview and Architecture, ANSI/IEEE Std 802, 1990. 3016 Framework Policy Information Base January 2002 3018 [SNMPFRWK] 3019 Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture 3020 for Describing SNMP Management Frameworks", RFC 2571, 3021 May 1999 3023 [STD17] 3024 K. McCloghrie, M. Rose "Management Information Base for Network 3025 Management of TCP/IP-based internets: MIB-II" STD 17, RFC 1213, 3026 March 1991 3028 11. Full Copyright 3030 Copyright (C) The Internet Society (2001). All Rights Reserved. This 3031 document and translations of it may be copied and furnished to 3032 others, and derivative works that comment on or otherwise explain it 3033 or assist in its implementation may be prepared, copied, published 3034 and distributed, in whole or in part, without restriction of any 3035 kind, provided that the above copyright notice and this paragraph 3036 are included on all such copies and derivative works. However, this 3037 document itself may not be modified in any way, such as by removing 3038 the copyright notice or references to the Internet Society or other 3039 Internet organizations, except as needed for the purpose of 3040 developing Internet standards in which case the procedures for 3041 copyrights defined in the Internet Standards process must be 3042 followed, or as required to translate it into languages other than 3043 English. 3045 The limited permissions granted above are perpetual and will not be 3046 revoked by the Internet Society or its successors or assigns. 3048 This document and the information contained herein is provided on an 3049 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 3050 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 3051 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 3052 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 3053 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3055 Framework Policy Information Base January 2002 3057 Table of Contents 3059 Status of this Memo...............................................1 3060 Abstract..........................................................2 3061 1. Glossary.......................................................2 3062 2. General PIB Concepts...........................................2 3063 2.1. Roles........................................................2 3064 2.1.1. An Example.................................................4 3065 2.2. Management of Role-Combinations from the PDP.................5 3066 2.3. Updating a Request State.....................................6 3067 2.3.1 Full Request State..........................................6 3068 2.3.2 Installing PRIs in a Request................................7 3069 2.3.3 Updating PRIs in a Request..................................7 3070 2.3.4 Removing PRIs from a Request................................7 3071 2.3.5 Removing EXTENDED, AUGMENTED PRIs...........................8 3072 2.3.6 Error Handling in Request updates...........................8 3073 2.4. Multiple PIB Instances.......................................8 3074 2.5. Reporting and Configuring of Device Capabilities............10 3075 2.6. Reporting of Device Limitations.............................10 3076 3. The Framework TC PIB module...................................11 3077 4. Summary of the Framework PIB..................................14 3078 4.1. Base PIB classes Group......................................14 3079 4.2. Device Capabilities group...................................15 3080 4.3. Classifier group............................................16 3081 4.4. Marker group................................................16 3082 5. The Framework PIB Module......................................17 3083 6. Security Considerations.......................................56 3084 7. RFC Editor Considerations.....................................56 3085 8. IANA Considerations...........................................56 3086 9. Author Information and Acknowledgments........................57 3087 10. References...................................................58 3088 11. Full Copyright...............................................59