idnits 2.17.1 draft-ietf-rap-frameworkpib-05.txt: -(88): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(520): 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? ** The document is more than 15 pages and seems to lack a Table of Contents. == There are 4 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 1 longer page, the longest (page 1) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 160: '...ct, then the PEP MUST reject the insta...' RFC 2119 keyword, line 178: '...ters "+" and "*" MUST not be used in a...' RFC 2119 keyword, line 256: '... instance MUST ensure that the attri...' RFC 2119 keyword, line 368: '...tifies a PRC. The value MUST be an OID...' RFC 2119 keyword, line 393: '... an attribute in a PRC. The value MUST...' (13 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1149 has weird spacing: '...ddrMask attrV...' == Line 1150 has weird spacing: '...ddrMask attrV...' == Line 1151 has weird spacing: '...Limited range...' == Line 1152 has weird spacing: '...Limited range...' == Line 1165 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 (July 20, 2001) is 8315 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 2185, but no explicit reference was found in the text == Unused Reference: 'IFMIB' is defined on line 2195, but no explicit reference was found in the text == Unused Reference: 'SNMPFRWK' is defined on line 2203, 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 draft: draft-ietf-rap-sppi (ref. 'SPPI') ** Downref: Normative reference to an Informational RFC: RFC 2753 (ref. 'RAP-FRAMEWORK') ** Obsolete normative reference: RFC 2851 (ref. 'INETADDR') (Obsoleted by RFC 3291) ** 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: 15 errors (**), 0 flaws (~~), 15 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft M. Fine 3 Expires January 2002 K. McCloghrie 4 File: draft-ietf-rap-frameworkpib-05.txt Cisco Systems 5 J. Seligson 6 K. Chan 7 Nortel Networks 8 S. Hahn 9 R. Sahita 10 Intel 11 A. Smith 12 Allegro Networks 13 F. Reichmeyer 14 PFN 16 July 20, 2001 18 Framework Policy Information Base 20 Status of this Memo 22 This document is an Internet-Draft and is in full conformance with 23 all provisions of Section 10 of RFC2026. Internet-Drafts are 24 working documents of the Internet Engineering Task Force (IETF), its 25 areas, and its working groups. Note that other groups may also 26 distribute working documents as Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six 29 months and may be updated, replaced, or obsoleted by other documents 30 at any time. It is inappropriate to use Internet-Drafts as 31 reference material or to cite them other than as ''work in 32 progress''. 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/1id-abstracts.html 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 1. Glossary 42 PRC Provisioning Class. A type of policy data. 43 PRI Provisioning Instance. An instance of a PRC. 44 PIB Policy Information Base. The database of policy information. 45 PDP Policy Decision Point. See [RAP-FRAMEWORK]. 46 PEP Policy Enforcement Point. See [RAP-FRAMEWORK]. 47 PRID Provisioning Instance Identifier. Uniquely identifies an 48 instance of a PRC. 50 2. Introduction 52 [SPPI] describes a structure for specifying policy information that 53 can then be transmitted to a network device for the purpose of 54 configuring policy at that device. The model underlying this 55 structure is one of well-defined provisioning classes and instances 56 of these classes residing in a virtual information store called the 57 Policy Information Base (PIB). 59 One way to provision policy is by means of the COPS protocol [COPS] 60 with the extensions for provisioning [COPS-PR]. This protocol 61 supports multiple clients, each of which may provision policy for a 62 specific policy domain such as QoS, virtual private networks, or 63 security. 65 As described in [COPS-PR], each client supports a non-overlapping 66 and independent set of PIB modules. However, some provisioning 67 classes are common to all subject-categories (client-types) and need 68 to be present in each. This document presents a set of PRCs that 69 are common to all clients that provision policy using COPS for 70 Provisioning. 72 3. General PIB Concepts 74 3.1. Roles 76 The policy to apply to an interface may depend on many factors such 77 as immutable characteristics of the interface (e.g., ethernet or 78 frame relay), the status of the interface (e.g., half or full 79 duplex), or user configuration (e.g., branch office or headquarters 80 interface). Rather than specifying policies explicitly for each 81 interface of all devices in the network, policies are specified in 82 terms of interface functionality. 84 To describe these functionalities of an interface we use the concept 85 of "Roles". A Role is simply a string that is associated with an 86 interface. A given interface may have any number of roles 87 simultaneously. Provisioning classes have an attribute called a 88 "RoleCombination� which is a lexicographically ordered set of roles. 89 Instances of a given provisioning class are applied to an interface 90 if and only if the set of roles in the role combination matches the 91 set of the roles of the interface. 93 Thus, roles provide a way to bind policy to interfaces without 94 having to explicitly identify interfaces in a consistent manner 95 across all network devices. (The SNMP experience with ifIndex has 96 proved this to be a difficult task.) That is, roles provide a level 97 of indirection to the application of a set of policies to specific 98 interfaces. Furthermore, if the same policy is being applied to 99 several interfaces, that policy need be pushed to the device only 100 once, rather than once per interface, as long as the interfaces are 101 configured with the same role combination. 103 We point out that, in the event that the administrator needs to have 104 unique policy for each interface, this can be achieved by 105 configuring each interface with a unique role. 107 The PEP sends all its Capability Set Names, Role Combinations, 108 Policy Controlled Interfaces, and their relationships to the PDP in 109 the initial COPS request (REQ) message. The PDP can install new 110 instances or change existing instances of these PRIs. This 111 operation can also occur in subsequent request messages generated in 112 response to COPS state synchronization (SSQ) requests and local 113 configuration changes. 115 The comparing of roles (or role combinations) is case sensitive. 117 By convention, when formatting the role-combination for exchange 118 within a protocol message, within a PIB/MIB object's value, or as a 119 printed value, the set is formatted in lexicographical order of the 120 role's ASCII values; that is, the role that is first is formatted 121 first. For example, "a+b" and "b+a" are NOT different role- 122 combinations; rather, they are different formatting of the same 123 role-combination, and hence for this example: 124 - "a+b" is the valid formatting of that role-combination, 125 - "b+a" is an invalid formatting of that role-combination. 127 The role-combination of interfaces to which no roles have been 128 assigned is known as the "null" role-combination. (Note the 129 deliberate use of lower-case letters for "null" so that it avoids 130 confusion with the ASCII NULL character that has a value of zero but 131 a length of one.) 133 In an "install" or an "install-notify" class, the wildcard role- 134 combination "*" can be used. In addition to providing for interface- 135 specific roles, it also allows for other optimizations in reducing 136 the number of role-combinations for which a policy has to be 137 specified. For example: 139 Suppose we have three interfaces: 141 Roles A, B and R1 are assigned to interface I1 142 Roles A, B and R2 are assigned to interface I2 143 Roles A, B and R3 are assigned to interface I3 145 Then, a PRI of a fictional IfDscpAssignTable that has the following 146 values for its attributes: 148 ifDscpAssignPrid = 1 149 ifDscpAssignRoles = "*+A+B" 150 ifDscpAssignName = "4queues" 151 ifDscpAssignDscpMap = 1 153 will apply to all three interfaces, because "*" matches with R1, R2 154 and R3. The policies can be assigned to an interface due to more 155 than one wild-carded role combo matching a given interface's role 156 combo string. The PDP should attempt to resolve conflicts between 157 policies before sending policies to the PEP. In the situation where 158 the PDP sends multiple policies to a PEP and they do conflict, 159 either because of an error by the PDP or because of a device- 160 specific conflict, then the PEP MUST reject the installation of the 161 conflicting policies and return an error. 163 Formally, 164 - The wildcard Role is denoted by "*", 165 - The "*" Role is not allowed to be defined as part of the role- 166 combination of an interface as notified by the PEP to the PDP; it 167 is only allowed in policies installed/deleted via COPS-PR from 168 the PDP to the PEP. 169 - For a policy to apply to an interface when the policy's role- 170 combination is "*+a+b", then the interface's role-combination: 171 - Must include "a" and "b", and 172 - Can include zero or more other roles. 173 - The wildcard character "*" is listed before the other roles as 174 "*" is lexicographically before "a"; however, the wildcard matches 175 any zero or more roles, irrespective of lexicographical order. 176 For example: "*+b+e+g" would match "a+b+c+e+f+g" 178 Note that the characters "+" and "*" MUST not be used in an 179 interface Role. The Framework Role PIB module in section 4 of this 180 document contains the Role and RoleCombination Textual Conventions. 182 3.1.1. An Example 184 The functioning of roles might be best understood by an example. 185 Suppose I have a device with three interfaces, with roles as 186 follows: 188 IF1: "finance" 189 IF2: "finance" 190 IF3: "manager" 192 Suppose, I also have a PDP with two policies: 194 P1: Packets from finance department (role "finance") get DSCP 5 195 P2: Packets from managers (role "manager") get DSCP 6 197 To obtain policy, the PEP reports to the PDP that it has some 198 interfaces with role combination "finance" and some with role 199 combination "manager". In response, the PDP downloads policy P1 200 associated with role combination "finance" and downloads a second 201 policy P2 associated with role combination "manager". 203 Now suppose the finance person attached to IF2 is promoted to 204 manager and so the system administrator adds the role "manager" to 205 IF2. The PEP now reports to the PDP that it has three role 206 combinations: some interfaces with role combination "finance", some 207 with role combination "manager" and some with role combination 208 "finance+manager". In response, the PDP downloads an additional 209 third policy associated with the new role combination 210 "finance+manager". 212 How the PDP determines the policy for this new role combination is 213 entirely the responsibility of the PDP. It could do so 214 algorithmically or by rule. For example, there might be a rule that 215 specifies that manager policy takes preference over department 216 policy. Or there might be a third policy installed in the PDP as 217 follows: 219 P3: Packets from finance managers (role "finance" and role 220 "manager") get DSCP 7 222 The point here is that the PDP is required to determine what policy 223 applies to this new role combination and to download a third policy 224 to the PEP for the role combination "finance+manager" even if that 225 policy is the same as one already downloaded. The PEP is not 226 required (or allowed) to construct policy for new role combinations 227 from existing policy. 229 3.2. Multiple PIB Instances 231 [COPS-PR] supports multiple, disjoint, independent instances of the 232 PIB to represent multiple instances of configured policy. The 233 intent is to allow for the pre-provisioning of policy that can then 234 be made active by a single, short decision from the PDP. 236 A COPS context can be defined as an independent COPS request state 237 for a particular subject category (client-type). 239 With the COPS-PR protocol, each of these states is identified by a 240 unique client handle. The creation and deletion of these PIB 241 instances is controlled by the PDP as described in [COPS-PR]. A PEP 242 must open only a single "request-state" for configuration for a 243 given subject-category (client type). Any additional "request- 244 states" at the PEP must be initiated by the PDP. 246 Although many PIB instances may be configured on a device (the 247 maximum number of these instances being determined by the device 248 itself) only one of them can be active at any given time, the active 249 one being selected by the PDP. To facilitate this selection, the 250 Framework PIB supports an attribute to make a PIB instance the 251 active one and, similarly, to report the active PIB instance to the 252 PDP in a COPS request message. This attribute is in the Incarnation 253 Table described below. 255 Setting the attribute frwkPibIncarnationActive to 'true' in one PIB 256 instance MUST ensure that the attribute is 'false' in all other 257 contexts. 259 3.3. Reporting and Configuring of Device Capabilities 261 Each network device providing policy-based services has its own 262 inherent capabilities. These capabilities can be hardware specific, 263 e.g., an ethernet interface supporting input classification, or can 264 be statically configured, e.g., supported queuing disciplines. 265 These capabilities are organized into some PEP default Interface 266 Capability Set, with each Capability Set associated with a set of 267 Role Combinations, each Role Combination associated with a set of 268 interfaces. After receiving the PEP default setting for the PEP 269 device capabilities, the PDP can change them. These capabilities 270 are communicated to the PDP when initial policy is requested by the 271 PEP. Knowing device capabilities, the PDP can send the provisioning 272 instances (PRIs) relevant to the specific device, rather than 273 sending the entire PIB. 275 The PIB indicates which capabilities the PEP must report to the PDP 276 by means of the PIB-ACCESS clause as described in [SPPI]. 278 3.4. Reporting of Device Limitations 280 To facilitate efficient policy installation, it is important to 281 understand a device's limitations in relation to the advertised 282 device capabilities. Limitations may be class-based, e.g., an 283 "install" class is supported as a "notify" or only a limited number 284 of class instances may be created, or attribute-based. Attribute 285 limitations, such as supporting a restricted set of enumerations or 286 requiring related attributes to have certain values, detail 287 implementation limitations at a fine level of granularity. 289 A PDP can avoid certain installation issues in a proactive fashion 290 by taking into account a device's limitations prior to policy 291 installation rather than in a reactive mode during installation. As 292 with device capabilities, device limitations are communicated to the 293 PDP when initial policy is requested. 295 Reported device limitations may be accompanied by guidance values 296 that can be used by a PDP to determine acceptable values for the 297 identified attributes. 299 4. The Framework Role PIB module 301 FRAMEWORK-ROLE-PIB PIB-DEFINITIONS ::= BEGIN 303 IMPORTS MODULE-IDENTITY, TEXTUAL-CONVENTION, pib FROM COPS-PR-SPPI 304 SnmpAdminString FROM SNMP-FRAMEWORK-MIB; 306 frwkRolePib MODULE-IDENTITY 307 SUBJECT-CATEGORIES { all } 308 LAST-UPDATED "200003010400Z" 309 ORGANIZATION "IETF RAP WG" 310 CONTACT-INFO "Keith McCloghrie 311 Cisco Systems, Inc. 312 170 West Tasman Drive, 313 San Jose, CA 95134-1706 USA 314 Phone: +1 408 526 5260 315 Email: kzm@cisco.com 317 John Seligson 318 Nortel Networks, Inc. 319 4401 Great America Parkway 320 Santa Clara, CA 95054 USA 321 Phone: +1 408 495 2992 322 Email: jseligso@nortelnetworks.com" 323 DESCRIPTION 324 "The PIB module containing the Role and 325 RoleCombination Textual Conventions and other 326 required TCs." 327 ::= { pib tbd } -- tbd to be assigned by IANA 329 Role ::= TEXTUAL-CONVENTION 330 STATUS current 331 DESCRIPTION 332 "A role represents a functionality characteristic or 333 capability of a resource to which policies are applied. 334 Examples of roles include Backbone_interface, 335 Frame_Relay_interface, BGP-capable-router, web-server, 336 firewall, etc. 337 Valid characters are a-z, A-Z, 0-9, period, hyphen and 338 underscore. A role must not start with an underscore." 339 SYNTAX SnmpAdminString (SIZE (1..31)) 341 RoleCombination ::= TEXTUAL-CONVENTION 342 STATUS current 343 DESCRIPTION 344 "A Display string consisting of a set of roles concatenated 345 with a '+' character where the roles are in lexicographic 346 order from minimum to maximum. 347 For example, a+b and b+a are NOT different 348 role-combinations; rather, they are different formatting of 349 the same (one) role-combination. 351 Notice the roles within a role-combination are in 352 Lexicographic order from minimum to maximum, hence, we 353 declare: 354 a+b is the valid formatting of the role-combination, 355 b+a is an invalid formatting of the role-combination. 357 Notice the need of zero-length role-combination as the role- 358 combination of interfaces to which no roles have been 359 assigned. This role-combination is also known as the null 360 role-combination. (Note the deliberate use of lower case 361 letters to avoid confusion with the ASCII NULL character 362 which has a value of zero but length of one.)" 363 SYNTAX SnmpAdminString (SIZE (0..255)) 365 PrcIdentifier ::= TEXTUAL-CONVENTION 366 STATUS current 367 DESCRIPTION 368 "An OID that identifies a PRC. The value MUST be an OID 369 assigned to a PRC's row definition. An attribute with this 370 syntax can have the value 0.0 (zeroDotZero) to indicate that 371 it currently does not identify a PRC." 372 SYNTAX OBJECT IDENTIFIER 374 AttrIdentifier ::= TEXTUAL-CONVENTION 375 STATUS current 376 DESCRIPTION 377 "A Unsigned32 value that identifies an attribute in a PRC. 379 A AttrIdentifier value is always interpreted within the 380 context of a PrcIdentifier value. The PrcIdentifier object 381 which defines the context must be registered immediately 382 before the object which uses the AttrIdentifier textual 383 convention. 385 An attribute with this syntax can have the value 0 to 386 indicate that it currently does not identify a PRC 387 attribute." 388 SYNTAX Unsigned32 390 AttrIdentifierOid ::= TEXTUAL-CONVENTION 391 STATUS current 392 DESCRIPTION 393 An OID that identifies an attribute in a PRC. The value MUST 394 be an OID assigned to a PRC's attribute definition. The last 395 sub-id is the position of the attribute as it is defined in 396 the PRC entry definition. The prefix OID (after dropping the 397 last sub-id) is the OID assigned to a defined PRC. An 398 attribute with this syntax can have the value 0.0 399 (zeroDotZero) to indicate that it currently does not 400 identify a PRC's attribute." 401 SYNTAX OBJECT IDENTIFIER 403 END 405 5. Summary of the Framework PIB 407 The Framework PIB comprises of three groups: 409 1. Base PIB classes Group 411 This contains PRCs intended to describe the PRCs supported 412 by the PEP, PRC and/or attribute limitations and its current 413 configuration. 415 PRC Support Table 417 As the technology evolves, we expect devices to be enhanced 418 with new PIBs, existing PIBs to add new PRCs and existing PRCs 419 to be augmented or extended with new attributes. Also, it is 420 likely that some existing PRCs or individual attributes of PRCs 421 will be deprecated. The PRC Support Table describes the PRCs 422 that the device supports as well as the individual attributes 423 of each PRC. Using this information the PDP can potentially 424 tailor the policy to more closely match the capabilities of the 425 device. The PRC Support Table instances are specific to the 426 particular Subject Category (Client-Type). That is, the PRC 427 Support Table for Subject Category 'A' will not include 428 instances for classes supported by the Subject Category 'B'. 429 Note that the COPS client-type [COPS] used for Framework PIB 430 PRIs sent/received over COPS-PR MUST be the unique SUBJECT- 431 CATEGORY number assigned for the area of policy being managed 432 (e.g. QoS, Security etc). 433 The PEP MUST ignore the attributes that it reports as not 434 Supported in the decision from the PDP. The PEP SHOULD not send 435 duplicate PRC support instances in a COPS Request and the PDP 436 MUST ignore duplicate instances and MUST use the first instance 437 received for a supported PRC in a COPS Request. 439 PIB Incarnation Table 441 This table contains exactly one row (corresponding to one PRI) 442 per context. It identifies the PDP that was the last to 443 download policy into the device and also contains an identifier 444 to identify the version of the policy currently downloaded. 445 This identifier, both its syntax and value, is meaningful only 446 to the PDPs. It is intended to be a mechanism whereby a PDP, 447 on connecting to a PEP, can easily identify a known incarnation 448 of policy. The incarnation PRC also includes an attribute to 449 indicate which context is the active one at the present time. 450 The incarnation instance is specific to the particular Subject 451 Category (Client-Type). 453 Component Limitations Table 455 Some devices may not be able to implement the full range of 456 values for all attributes. In principle, each PRC supports a 457 set of errors that the PEP can report to the PDP in the event 458 that the specified policy is not implementable. It may be 459 preferable for the PDP to be informed of the device limitations 460 before actually attempting to install policy, and while the 461 error can indicate that a particular attribute value is 462 unacceptable to the PEP, this does not help the PDP ascertain 463 which values would be acceptable. To alleviate these 464 limitations, the PEP can report some limitations of attribute 465 values and/or classes and possibly guidance values for the 466 attribute in the Component Limitations Table 468 Device Identification Table 470 This class contains a single provisioning instance that 471 contains device-specific information that is used to facilitate 472 efficient policy installation by a PDP. The instance of this 473 class is reported to the PDP in a COPS request message so that 474 the PDP can take into account certain device characteristics 475 during policy installation. 477 2. Device Capabilities group 479 This group contains the PRCs that describe the characteristics of 480 interfaces of the device and the Role Combinations assigned to 481 them. 483 Interface Capabilities Set Table 485 The interfaces the PEP supports are described by rows in 486 this table (frwkIfCapSetTable). Each row, or instance of this 487 class, associates a unique interface name with a set of 488 capabilities that the interface supports. The unique name is 489 used to form a set of capabilities that the name represents. 490 The capability references can specify instances in relevant 491 capability tables in any PIB. The PEP notifies the PDP of these 492 interface names and capabilities and then the PDP configures 493 the interfaces, per role combination. The unique name 494 (IfCapSetName) is not to be confused with the IfType object in 495 MIB-II [STD17]. 497 Interface Capability and Role Combo Table 499 The Interface Capabilities Set Table (explained above) 500 describes the interfaces the PEP supports by their 501 capabilities, by assigning the capability sets a unique name. 502 It is possible to tailor the behavior of interfaces by 503 assigning specific roles to the capability sets. This allows 504 interfaces with the same capability sets to be assigned 505 different policies, based on the current roles assigned to 506 them. At the PDP, configuration is done in terms of these 507 interface capability set names (ifCapSetName) and the role 508 combinations assigned to them. Thus, each row of this 509 class is a two- 510 tuple, that indicates the roles that have been assigned to a 511 particular capability set (as identified by IfCapSetName). The 512 ifCapSetName is the grouping attribute used to form a set of 513 role combinations that apply to this capability set. 515 Interface and Role Combination Table 517 The Interface and Role Combination Table describes the 518 association between specific interfaces with each role 519 combination. It answers the questions of �which interfaces 520 have a specific role combination?� and �what role combination 521 a specific interface is a part of?�. The Interface and Role 522 Combination Table entries each contains a 523 two-tuple to accomplish this mapping. 525 3. Classifier group 527 This group contains the IP and IEEE 802 Classifier elements. The 528 set of tables consist of a Base Filter table that contains the 529 Index InstanceId and the Negation flag for the filter. This 530 frwkBaseFilterTable is extended to form the IP Filter table and 531 the 802 Filter table [802]. Filters may also be defined outside 532 this document and used to extend the Base Filter table. 534 The Extended classes do not have a separate Index value. 535 Instances of the extended classes have the same indices as their 536 base class instance. Inheritance is achieved using the EXTENDS 537 keyword as defined in [SPPI]. 539 6. The Framework PIB Module 541 FRAMEWORK-PIB PIB-DEFINITIONS ::= BEGIN 543 IMPORTS 544 Unsigned32, Integer32, MODULE-IDENTITY, 545 MODULE-COMPLIANCE, OBJECT-TYPE, OBJECT-GROUP, pib 546 FROM COPS-PR-SPPI 547 InstanceId, Prid 548 FROM COPS-PR-SPPI-TC 549 RoleCombination, PrcIdentifier 550 FROM FRAMEWORK-ROLE-PIB 551 InetAddress, InetAddressType 552 FROM INET-ADDRESS-MIB 553 InterfaceIndex 554 FROM IF-MIB 555 TruthValue, PhysAddress 556 FROM SNMPv2-TC 557 SnmpAdminString 558 FROM SNMP-FRAMEWORK-MIB; 560 frameworkPib MODULE-IDENTITY 561 SUBJECT-CATEGORIES { all } 562 LAST-UPDATED "200003010400Z" 563 ORGANIZATION "IETF RAP WG" 564 CONTACT-INFO " 565 Michael Fine 566 Cisco Systems, Inc. 567 170 West Tasman Drive 568 San Jose, CA 95134-1706 USA 569 Phone: +1 408 527 8218 570 Email: mfine@cisco.com 572 Keith McCloghrie 573 Cisco Systems, Inc. 574 170 West Tasman Drive, 575 San Jose, CA 95134-1706 USA 576 Phone: +1 408 526 5260 577 Email: kzm@cisco.com 579 John Seligson 580 Nortel Networks, Inc. 581 4401 Great America Parkway 582 Santa Clara, CA 95054 USA 583 Phone: +1 408 495 2992 584 Email: jseligso@nortelnetworks.com" 585 DESCRIPTION 586 "A PIB module containing the base set of provisioning 587 classes that are required for support of policies for 588 all subject-categories." 590 ::= { pib tbd } -- tbd to be assigned by IANA 592 -- 593 -- The root OID for PRCs in the Framework PIB 594 -- 596 frwkBasePibClasses 597 OBJECT IDENTIFIER ::= { frameworkPib 1 } 599 -- 600 -- Textual Conventions 601 -- 603 -- 604 -- PRC Support Table 605 -- 607 frwkPrcSupportTable OBJECT-TYPE 608 SYNTAX SEQUENCE OF FrwkPrcSupportEntry 609 PIB-ACCESS notify 610 STATUS current 611 DESCRIPTION 612 "Each instance of this class specifies a PRC that the device 613 supports and a bit string to indicate the attributes of the 614 class that are supported. These PRIs are sent to the PDP to 615 indicate to the PDP which PRCs, and which attributes of 616 these PRCs, the device supports. This table can also be 617 downloaded by a network manager when static configuration is 618 used. 620 All install and install-notify PRCs supported by the device 621 must be represented in this table. Notify PRCs may be 622 represented for informational purposes." 624 ::= { frwkBasePibClasses 1 } 626 frwkPrcSupportEntry OBJECT-TYPE 627 SYNTAX FrwkPrcSupportEntry 628 STATUS current 629 DESCRIPTION 630 "An instance of the frwkPrcSupport class that identifies a 631 specific PRC and associated attributes as supported 632 by the device." 634 PIB-INDEX { frwkPrcSupportPrid } 635 UNIQUENESS { frwkPrcSupportSupportedPrc } 637 ::= { frwkPrcSupportTable 1 } 639 FrwkPrcSupportEntry ::= SEQUENCE { 640 frwkPrcSupportPrid InstanceId, 641 frwkPrcSupportSupportedPrc PrcIdentifier, 642 frwkPrcSupportSupportedAttrs OCTET STRING 643 } 645 frwkPrcSupportPrid OBJECT-TYPE 646 SYNTAX InstanceId 647 STATUS current 648 DESCRIPTION 649 "An arbitrary integer index that uniquely identifies an 650 instance of the frwkPrcSupport class." 652 ::= { frwkPrcSupportEntry 1 } 654 frwkPrcSupportSupportedPrc OBJECT-TYPE 655 SYNTAX PrcIdentifier 656 STATUS current 657 DESCRIPTION 658 "The object identifier of a supported PRC. The value is the 659 OID of the table entry. There may not be more than one 660 instance of the frwkPrcSupport class with the same value of 661 frwkPrcSupportSupportedPrc." 663 ::= { frwkPrcSupportEntry 2 } 665 frwkPrcSupportSupportedAttrs OBJECT-TYPE 666 SYNTAX OCTET STRING 667 STATUS current 668 DESCRIPTION 669 "A bit string representing the supported attributes of the 670 class that is identified by the frwkPrcSupportSupportedPrc 671 object. 673 Each bit of this bit string corresponds to a class 674 attribute, with the most significant bit of the i-th octet 675 of this octet string corresponding to the (8*i - 7)-th 676 attribute, and the least significant bit of the i-th octet 677 corresponding to the (8*i)-th class attribute. Each bit 678 specifies whether or not the corresponding class attribute 679 is currently supported, with a '1' indicating support and a 680 '0' indicating no support. If the value of this bit string 681 is N bits long and there are more than N class attributes 682 then the bit string is logically extended with 0's to the 683 required length." 685 ::= { frwkPrcSupportEntry 3 } 687 -- 688 -- PIB Incarnation Table 689 -- 691 frwkPibIncarnationTable OBJECT-TYPE 692 SYNTAX SEQUENCE OF FrwkPibIncarnationEntry 693 PIB-ACCESS install-notify 694 STATUS current 695 DESCRIPTION 696 "This class contains a single provisioning instance per 697 installed context that identifies the current incarnation 698 of the PIB and the PDP or network manager that installed 699 this incarnation. The instance of this class is reported to 700 the PDP in the REQ message so that the PDP can (attempt to) 701 ascertain the current state of the PIB and the active 702 context. A network manager may use the instance to 703 determine the state of the device." 705 ::= { frwkBasePibClasses 2 } 707 frwkPibIncarnationEntry OBJECT-TYPE 708 SYNTAX FrwkPibIncarnationEntry 709 STATUS current 710 DESCRIPTION 711 "An instance of the frwkPibIncarnation class. Only 712 one instance of this provisioning class is ever 713 instantiated per context" 715 PIB-INDEX { frwkPibIncarnationPrid } 717 ::= { frwkPibIncarnationTable 1 } 719 FrwkPibIncarnationEntry ::= SEQUENCE { 720 frwkPibIncarnationPrid InstanceId, 721 frwkPibIncarnationName SnmpAdminString, 722 frwkPibIncarnationId OCTET STRING, 723 frwkPibIncarnationLongevity Unsigned32, 724 frwkPibIncarnationTtl Unsigned32, 725 frwkPibIncarnationActive TruthValue 726 } 728 frwkPibIncarnationPrid OBJECT-TYPE 729 SYNTAX InstanceId 730 STATUS current 731 DESCRIPTION 732 "An index to uniquely identify an instance of this 733 provisioning class." 735 ::= { frwkPibIncarnationEntry 1 } 737 frwkPibIncarnationName OBJECT-TYPE 738 SYNTAX SnmpAdminString 739 STATUS current 740 DESCRIPTION 741 "The name of the PDP that installed the current incarnation 742 of the PIB into the device. By default, it is the zero 743 length string." 745 ::= { frwkPibIncarnationEntry 2 } 747 frwkPibIncarnationId OBJECT-TYPE 748 SYNTAX OCTET STRING 749 STATUS current 750 DESCRIPTION 751 "An ID to identify the current incarnation. It has meaning 752 to the PDP/manager that installed the PIB and perhaps its 753 standby PDPs/managers. By default, it is the zero-length 754 string." 756 ::= { frwkPibIncarnationEntry 3 } 758 frwkPibIncarnationLongevity OBJECT-TYPE 759 SYNTAX Unsigned32 { 760 expireNever(1), 761 expireImmediate(2), 762 expireOnTimeout(3) 763 } 764 STATUS current 765 DESCRIPTION 766 "This attribute controls what the PEP does with the 767 downloaded policy on a Client Close message or a loss of 768 connection to the PDP. 770 If set to expireNever, the PEP continues to operate with the 771 installed policy indefinitely. If set to expireImmediate, 772 the PEP immediately expires the policy obtained from the PDP 773 and installs policy from local configuration. If set to 774 expireOnTimeout, the PEP continues to operate with the 775 policy installed by the PDP for a period of time specified 776 by frwkPibIncarnationTtl. After this time (and it has not 777 reconnected to the original or new PDP) the PEP expires this 778 policy and reverts to local configuration. 780 For all cases, it is the responsibility of the PDP to check 781 the incarnation and download new policy, if necessary, on a 782 reconnect. On receiving a Remove-State [COPS-PR] for the 783 active context, this attribute value MUST be ignored and the 784 PEP should expire the policy in that active context 785 immediately. 786 Policy enforcement timing only applies to policies that have 787 been installed dynamically (e.g., by a PDP via COPS)." 789 ::= { frwkPibIncarnationEntry 4 } 791 frwkPibIncarnationTtl OBJECT-TYPE 792 SYNTAX Unsigned32 793 UNITS "seconds" 794 STATUS current 795 DESCRIPTION 796 "The number of seconds after a Client Close or TCP timeout 797 for which the PEP continues to enforce the policy in the 798 PIB. After this interval, the PIB is considered expired and 799 the device no longer enforces the policy installed in the 800 PIB. 802 This attribute is only meaningful if 803 frwkPibIncarnationLongevity is set to expireOnTimeout." 805 ::= { frwkPibIncarnationEntry 5 } 807 frwkPibIncarnationActive OBJECT-TYPE 808 SYNTAX TruthValue 809 STATUS current 810 DESCRIPTION 811 "If this attribute is set to TRUE, then the PIB instance 812 to which this PRI belongs becomes the active PIB instance. 813 The previous active instance MUST become inactive and the 814 frwkPibIncarnationActive attribute in that PIB instance 815 MUST be set to false. 817 When the PEP installs an attribute frwkPibIncarnationActive 818 that is 'true' in one PIB instance, the PEP must ensure, 819 re-setting the attribute if necessary, that the 820 frwkPibIncarnationActive attribute is 'false' in all other 821 contexts." 823 ::= { frwkPibIncarnationEntry 6 } 825 -- 826 -- Device Identification Table 827 -- 829 -- This table supports the ability to export general 830 -- purpose device information to facilitate efficient 831 -- communication between the device and a PDP 833 frwkDeviceIdTable OBJECT-TYPE 834 SYNTAX SEQUENCE OF FrwkDeviceIdEntry 835 PIB-ACCESS notify 836 STATUS current 837 DESCRIPTION 838 "This class contains a single provisioning instance that 839 contains device-specific information that is used to 840 facilitate efficient policy installation by a PDP. The 841 instance of this class is reported to the PDP in a COPS 842 request message so that the PDP can take into account 843 certain device characteristics during policy installation." 845 ::= { frwkBasePibClasses 3 } 847 frwkDeviceIdEntry OBJECT-TYPE 848 SYNTAX FrwkDeviceIdEntry 849 STATUS current 850 DESCRIPTION 851 "An instance of the frwkDeviceId class. Only one instance of 852 this provisioning class is ever instantiated." 854 PIB-INDEX { frwkDeviceIdPrid } 856 ::= { frwkDeviceIdTable 1 } 858 FrwkDeviceIdEntry ::= SEQUENCE { 859 frwkDeviceIdPrid InstanceId, 860 frwkDeviceIdDescr SnmpAdminString, 861 frwkDeviceIdMaxMsg Unsigned32, 862 frwkDeviceIdMaxContexts Unsigned32 863 } 865 frwkDeviceIdPrid OBJECT-TYPE 866 SYNTAX InstanceId 867 STATUS current 868 DESCRIPTION 869 "An index to uniquely identify an instance of this 870 provisioning class." 872 ::= { frwkDeviceIdEntry 1 } 874 frwkDeviceIdDescr OBJECT-TYPE 875 SYNTAX SnmpAdminString 876 STATUS current 877 DESCRIPTION 878 "A textual description of the PEP. This value should include 879 the name and version identification of the PEP's hardware 880 and software." 882 ::= { frwkDeviceIdEntry 2 } 884 frwkDeviceIdMaxMsg OBJECT-TYPE 885 SYNTAX Unsigned32 886 UNITS "octets" 887 STATUS current 888 DESCRIPTION 889 "The maximum message size, in octets, that the device 890 is capable of processing. Received messages with a 891 size in excess of this value must cause the PEP to return an 892 error to the PDP containing the global error code 893 'maxMsgSizeExceeded'. This is an additional error-avoidance 894 mechanism to allow the administrator to have the ability to 895 control the message size of messages sent to the device. The 896 device should send NULL for this attributes if it not 897 defined." 899 ::= { frwkDeviceIdEntry 3 } 901 frwkDeviceIdMaxContexts OBJECT-TYPE 902 SYNTAX Unsigned32 903 UNITS "contexts" 904 STATUS current 905 DESCRIPTION 906 "The maximum number of unique contexts supported by 907 the device. This is an additional error-avoidance mechanism 908 to allow the administrators to have the ability to control 909 the number of contexts installed on the device. The device 910 should send NULL for this attribute if it is not 911 specified." 913 ::= { frwkDeviceIdEntry 4 } 915 -- 916 -- Component Limitations Table 917 -- 919 -- This table supports the ability to export information 920 -- detailing provisioning class/attribute implementation limitations 921 -- to the policy management system. Instances of this PRC apply only 922 -- for PRCs with access type 'install' or 'install-notify'. 924 frwkCompLimitsTable OBJECT-TYPE 925 SYNTAX SEQUENCE OF FrwkCompLimitsEntry 926 PIB-ACCESS notify 927 STATUS current 928 DESCRIPTION 929 "Each instance of this class identifies a provisioning class 930 or attribute and a limitation related to the implementation 931 of the class/attribute in the device. Additional information 932 providing guidance related to the limitation may also be 933 present. These PRIs are sent to the PDP to indicate which 934 PRCs or PRC attributes the device supports in a restricted 935 manner." 937 ::= { frwkBasePibClasses 4 } 939 frwkCompLimitsEntry OBJECT-TYPE 940 SYNTAX FrwkCompLimitsEntry 941 STATUS current 942 DESCRIPTION 943 "An instance of the frwkCompLimits class that identifies 944 a PRC or PRC attribute and a limitation related to the PRC 945 or PRC attribute implementation supported by the device. 946 [COPS-PR] lists the error codes that MUST be returned (if 947 applicable)for policy installation that don't abide by the 948 restrictions indicated by the limitations exported. [SPPI] 949 defines an INSTALL-ERRORS clause that allows PIB designers 950 to define PRC specific error codes that can be returned for 951 policy installation. This allows efficient debugging of PIB 952 implementations." 954 PIB-INDEX { frwkCompLimitsPrid } 955 UNIQUENESS { frwkCompLimitsComponent, 956 frwkCompLimitsAttrPos, 957 frwkCompLimitsNegation, 958 frwkCompLimitsType, 959 frwkCompLimitsSubType, 960 frwkCompLimitsGuidance } 962 ::= { frwkCompLimitsTable 1 } 964 FrwkCompLimitsEntry ::= SEQUENCE { 965 frwkCompLimitsPrid InstanceId, 966 frwkCompLimitsComponent PrcIdentifier, 967 frwkCompLimitsAttrPos Unsigned32, 968 frwkCompLimitsNegation TruthValue, 969 frwkCompLimitsType Unsigned32, 970 frwkCompLimitsSubType Unsigned32, 971 frwkCompLimitsGuidance OCTET STRING 972 } 974 frwkCompLimitsPrid OBJECT-TYPE 975 SYNTAX InstanceId 976 STATUS current 977 DESCRIPTION 978 "An arbitrary integer index that uniquely identifies an 979 instance of the frwkCompLimits class." 981 ::= { frwkCompLimitsEntry 1 } 983 frwkCompLimitsComponent OBJECT-TYPE 984 SYNTAX PrcIdentifier 985 STATUS current 986 DESCRIPTION 987 "The value is the OID of a PRC (the table entry) which is 988 supported in some limited fashion or contains an attribute 989 that is supported in some limited fashion with regard to 990 it's definition in the associated PIB module. The same OID 991 may appear in the table several times, once for each 992 implementation limitation acknowledged by the device." 994 ::= { frwkCompLimitsEntry 2 } 996 frwkCompLimitsAttrPos OBJECT-TYPE 997 SYNTAX Unsigned32 998 STATUS current 999 DESCRIPTION 1000 "The relative position of the attribute within the PRC 1001 specified by the frwkCompLimitsComponent. A value of 1 would 1002 represent the first columnar object in the PRC and a value 1003 of N would represent the Nth columnar object in the PRC. A 1004 NULL value indicates that the limit applies to the PRC 1005 itself and not to a specific attribute." 1007 ::= { frwkCompLimitsEntry 3 } 1009 frwkCompLimitsNegation OBJECT-TYPE 1010 SYNTAX TruthValue 1011 STATUS current 1012 DESCRIPTION 1013 "A boolean value ,if TRUE, negates the component limit 1014 exported." 1016 ::= { frwkCompLimitsEntry 4 } 1018 frwkCompLimitsType OBJECT-TYPE 1019 SYNTAX Unsigned32 { 1020 priSpaceLimited(1), 1021 attrValueSupLimited(2), 1022 attrEnumSupLimited(3), 1023 attrLengthLimited(4), 1024 prcLimitedNotify(5) 1025 } 1026 STATUS current 1027 DESCRIPTION 1028 "A value describing an implementation limitation for the 1029 device related to the PRC or PRC attribute identified by 1030 the frwkCompLimitsComponent and the frwkCompLimitsAttrPos 1031 attributes in this class instance. 1033 Values for this object are one of the following: 1035 priSpaceLimited(1) - No more instances than that specified 1036 by the guidance value may be installed in the given class. 1037 The component identified MUST be a valid PRC. The SubType 1038 used MUST be valueOnly(9). 1040 attrValueSupLimited(2) - Limited values are acceptable for 1041 the identified component. The component identified MUST be a 1042 valid PRC attribute. The guidance OCTET STRING will be 1043 decoded according to the attribute type. 1045 attrEnumSupLimited(3) - Limited enumeration values are legal 1046 for the identified component. The attribute identified MUST 1047 be a valid enum type. 1049 attrLengthLimited(4) - The length of the specified 1050 value for the identified component is limited. The component 1051 identified MUST be a valid PRC attribute of base-type OCTET 1052 STRING. 1054 prcLimitedNotify (5) - The component is currently limited 1055 for use by request or report messages prohibiting decision 1056 installation. The component identified must be a valid PRC." 1058 ::= { frwkCompLimitsEntry 5 } 1060 frwkCompLimitsSubType OBJECT-TYPE 1061 SYNTAX Unsigned32 { 1062 none(1), 1063 lengthMin(2), 1064 lengthMax(3), 1065 rangeMin(4), 1066 rangeMax(5), 1067 enumMin(6), 1068 enumMax(7), 1069 enumOnly(8), 1070 valueOnly(9), 1071 bitMask(10) 1072 } 1073 STATUS current 1074 DESCRIPTION 1075 "This object indicates the type of guidance related 1076 to the noted limitation (as indicated by the 1077 frwkCompLimitsType attribute) that is provided 1078 in the frwkCompLimitsGuidance attribute. 1080 A value of 'none(1)' means that no additional 1081 guidance is provided for the noted limitation type. 1083 A value of 'lengthMin(2)' means that the guidance 1084 attribute provides data related to the minimum 1085 acceptable length for the value of the identified 1086 component. A corresponding class instance 1087 specifying the 'lengthMax(3)' value is required 1088 in conjunction with this sub-type. 1090 A value of 'lengthMax(3)' means that the guidance 1091 attribute provides data related to the maximum 1092 acceptable length for the value of the identified 1093 component. A corresponding class instance 1094 specifying the 'lengthMin(2)' value is required 1095 in conjunction with this sub-type. 1097 A value of 'rangeMin(4)' means that the guidance 1098 attribute provides data related to the lower bound 1099 of the range for the value of the identified 1100 component. A corresponding class instance 1101 specifying the 'rangeMax(5)' value is required 1102 in conjunction with this sub-type. 1104 A value of 'rangeMax(5)' means that the guidance 1105 attribute provides data related to the upper bound 1106 of the range for the value of the identified 1107 component. A corresponding class instance 1108 specifying the 'rangeMin(4)' value is required 1109 in conjunction with this sub-type. 1111 A value of 'enumMin(6)' means that the guidance 1112 attribute provides data related to the lowest 1113 enumeration acceptable for the value of the 1114 identified component. A corresponding 1115 class instance specifying the 'enumMax(7)' 1116 value is required in conjunction with this sub-type. 1118 A value of 'enumMax(7)' means that the guidance 1119 attribute provides data related to the largest 1120 enumeration acceptable for the value of the 1121 identified component. A corresponding 1122 class instance specifying the 'enumMin(6)' 1123 value is required in conjunction with this sub-type. 1125 A value of 'enumOnly(8)' means that the guidance 1126 attribute provides data related to a single 1127 enumeration acceptable for the value of the 1128 identified component. 1130 A value of 'valueOnly(9)' means that the guidance 1131 attribute provides data related to a single 1132 value that is acceptable for the identified 1133 component. 1135 A value of 'bitMask(10)' means that the guidance 1136 attribute is a bit mask such that all the combinations of 1137 bits set in the bitmask are acceptable values for the 1138 identified component which should be an attribute of type 1139 'BITS'. 1141 For example, an implementation of the frwkIpFilter class may 1142 be limited in several ways, such as address mask, protocol 1143 and Layer 4 port options. These limitations could be 1144 exported using this table with the following instances: 1146 Component Type Sub Guidance 1147 Type 1148 ------------------------------------------------------------ 1149 frwkIpFilterDstAddrMask attrValueSupLimited valueOnly 24 1150 frwkIpFilterSrcAddrMask attrValueSupLimited valueOnly 24 1151 frwkIpFilterProtocol attrValueSupLimited rangeMin 10 1152 frwkIpFilterProtocol attrValueSupLimited rangeMax 20 1154 The above entries describe a number of limitations that 1155 may be in effect for the frwkIpFilter class on a given 1156 device. The limitations include restrictions on acceptable 1157 values for certain attributes. 1159 Also, an implementation of a PRC may be limited in the ways 1160 it can be accessed. For instance, for a fictitious PRC 1161 dscpMapEntry, which has a PIB-ACCESS of 'install-notify': 1163 Component Type SubType Guidance 1164 ------------------------------------------------------------ 1165 dscpMapEntry prcLimitedNotify none zero-length string." 1167 ::= { frwkCompLimitsEntry 6 } 1169 frwkCompLimitsGuidance OBJECT-TYPE 1170 SYNTAX OCTET STRING 1171 STATUS current 1172 DESCRIPTION 1173 "A value used to convey additional information related 1174 to the implementation limitation. Note that a guidance 1175 value will not necessarily be provided for all exported 1176 limitations. If a guidance value is not provided, the 1177 value must be a zero-length string. 1179 The format of the guidance value, if one is present as 1180 indicated by the frwkCompLimitsSubType attribute, 1181 is described by the following table. Note that the 1182 type of guidance value is dictated by the type of the 1183 component whose limitation is being exported, interpreted 1184 in the context of the frwkCompLimitsType and 1185 frwkCompLimitsSubType values. 1187 Note that numbers are encoded in network byte order. 1189 Base Type Value 1190 --------- ----- 1191 Unsigned32/Integer32 32-bit value. 1192 Unsigned64/Integer64 64-bit Value. 1193 OCTET STRING octets of data. 1194 OID 32-bit OID components. 1195 BITS Binary octets of length same as 1196 Component specified." 1198 ::= { frwkCompLimitsEntry 7 } 1200 -- 1201 -- The device interface capabilities and role combo classes group 1202 -- 1204 frwkDeviceCapClasses 1205 OBJECT IDENTIFIER ::= { frameworkPib 2 } 1207 -- 1208 -- Interface Capability Set Table 1209 -- 1211 frwkIfCapSetTable OBJECT-TYPE 1212 SYNTAX SEQUENCE OF FrwkIfCapSetEntry 1213 PIB-ACCESS install-notify 1214 STATUS current 1215 DESCRIPTION 1216 "This class describes the interfaces that exist on the 1217 device. Associated with each interface is a set of 1218 capabilities. The capability set is given a unique name that 1219 identifies the interface type. These capabilities are used 1220 by the PDP to determine policy information to be associated 1221 with interfaces of this type." 1223 ::= { frwkDeviceCapClasses 1 } 1225 frwkIfCapSetEntry OBJECT-TYPE 1226 SYNTAX FrwkIfCapSetEntry 1227 STATUS current 1228 DESCRIPTION 1229 "An instance of this class describes the characteristics 1230 of a type of an interface." 1232 PIB-INDEX { frwkIfCapSetPrid } 1233 UNIQUENESS { frwkIfCapSetName, 1234 frwkIfCapSetCapability } 1236 ::= { frwkIfCapSetTable 1 } 1238 FrwkIfCapSetEntry ::= SEQUENCE { 1239 frwkIfCapSetPrid InstanceId, 1240 frwkIfCapSetName SnmpAdminString, 1241 frwkIfCapSetCapability Prid 1242 } 1244 frwkIfCapSetPrid OBJECT-TYPE 1245 SYNTAX InstanceId 1246 STATUS current 1247 DESCRIPTION 1248 "An arbitrary integer index that uniquely identifies a 1249 instance of the class." 1251 ::= { frwkIfCapSetEntry 1 } 1253 frwkIfCapSetName OBJECT-TYPE 1254 SYNTAX SnmpAdminString 1255 STATUS current 1256 DESCRIPTION 1257 "The name for the capability set. The capability set name 1258 is the unique identifier of an interface type." 1260 ::= { frwkIfCapSetEntry 2 } 1262 frwkIfCapSetCapability OBJECT-TYPE 1263 SYNTAX Prid 1264 STATUS current 1265 DESCRIPTION 1266 "The complete PRC OID and instance identifier specifying the 1267 capability PRC instance for the interface." 1269 ::= { frwkIfCapSetEntry 3 } 1271 -- 1272 -- Interface Capabilities Set Name and Role Combination Table 1273 -- 1275 frwkIfCapSetRoleComboTable OBJECT-TYPE 1276 SYNTAX SEQUENCE OF FrwkIfCapSetRoleComboEntry 1277 PIB-ACCESS install-notify 1278 STATUS current 1279 DESCRIPTION 1280 "Policy for an interface depends not only on the 1281 capability set of an interface but also on its roles. This 1282 table specifies all the tuples currently on the device." 1285 ::= { frwkDeviceCapClasses 2 } 1287 frwkIfCapSetRoleComboEntry OBJECT-TYPE 1288 SYNTAX FrwkIfCapSetRoleComboEntry 1289 STATUS current 1290 DESCRIPTION 1291 "An instance of this class describes a combination of an 1292 interface capability set name and a role combination." 1294 PIB-INDEX { frwkIfCapSetRoleComboPrid } 1295 UNIQUENESS { frwkIfCapSetRoleComboName, 1296 frwkIfCapSetRoleComboRoles } 1298 ::= { frwkIfCapSetRoleComboTable 1 } 1300 FrwkIfCapSetRoleComboEntry ::= SEQUENCE { 1301 frwkIfCapSetRoleComboPrid InstanceId, 1302 frwkIfCapSetRoleComboName SnmpAdminString, 1303 frwkIfCapSetRoleComboRoles RoleCombination 1304 } 1306 frwkIfCapSetRoleComboPrid OBJECT-TYPE 1307 SYNTAX InstanceId 1308 STATUS current 1309 DESCRIPTION 1310 "An arbitrary integer index that uniquely identifies an 1311 instance of the class." 1313 ::= { frwkIfCapSetRoleComboEntry 1 } 1315 frwkIfCapSetRoleComboName OBJECT-TYPE 1316 SYNTAX SnmpAdminString 1317 STATUS current 1318 DESCRIPTION 1319 "The name of the interface capability set. This name must 1320 exist in frwkIfCapSetTable." 1322 ::= { frwkIfCapSetRoleComboEntry 2 } 1324 frwkIfCapSetRoleComboRoles OBJECT-TYPE 1325 SYNTAX RoleCombination 1326 STATUS current 1327 DESCRIPTION 1328 "A role combination. The PEP requires policy for interfaces 1329 with this role combination and of capability set name 1330 specified by frwkIfCapSetRoleComboName." 1332 ::= { frwkIfCapSetRoleComboEntry 3 } 1334 -- 1335 -- Interface and Role Combination Table 1336 -- 1338 frwkIfCapSetInterfaceTable OBJECT-TYPE 1339 SYNTAX SEQUENCE OF FrwkIfCapSetInterfaceEntry 1340 PIB-ACCESS install-notify 1341 STATUS current 1342 DESCRIPTION 1343 "This table enumerates the interface to role combination 1344 mapping for all policy managed interfaces of a device." 1346 ::= { frwkDeviceCapClasses 3 } 1348 frwkIfCapSetInterfaceEntry OBJECT-TYPE 1349 SYNTAX FrwkIfCapSetInterfaceEntry 1350 STATUS current 1351 DESCRIPTION 1352 "An instance of this class describes an association of an 1353 interface and a role combination." 1355 PIB-INDEX { frwkIfCapSetInterfacePrid } 1356 UNIQUENESS { frwkIfCapSetInterfaceIfIndex, 1357 frwkIfCapSetInterfaceRoles } 1359 ::= { frwkIfCapSetInterfaceTable 1 } 1361 FrwkIfCapSetInterfaceEntry ::= SEQUENCE { 1362 frwkIfCapSetInterfacePrid InstanceId, 1363 frwkIfCapSetInterfaceIfIndex InterfaceIndex, 1364 frwkIfCapSetInterfaceRoles RoleCombination 1365 } 1367 frwkIfCapSetInterfacePrid OBJECT-TYPE 1368 SYNTAX InstanceId 1369 STATUS current 1370 DESCRIPTION 1371 "An arbitrary integer index that uniquely identifies an 1372 instance of the class." 1374 ::= { frwkIfCapSetInterfaceEntry 1 } 1376 frwkIfCapSetInterfaceIfIndex OBJECT-TYPE 1377 SYNTAX InterfaceIndex 1378 STATUS current 1379 DESCRIPTION 1380 "The ifIndex value for which this conceptual row provides 1381 policy information via the use of role combination." 1383 ::= { frwkIfCapSetInterfaceEntry 2 } 1385 frwkIfCapSetInterfaceRoles OBJECT-TYPE 1386 SYNTAX RoleCombination 1387 STATUS current 1388 DESCRIPTION 1389 "The role combination of a specific interface. This 1390 role combination must exist in frwkIfCapSetRoleComboTable." 1392 ::= { frwkIfCapSetInterfaceEntry 3 } 1394 -- 1395 -- The Classification classes group 1396 -- 1398 frwkClassifierClasses 1399 OBJECT IDENTIFIER ::= { frameworkPib 3 } 1400 -- 1401 -- The Base Filter Table 1402 -- 1404 frwkBaseFilterTable OBJECT-TYPE 1405 SYNTAX SEQUENCE OF FrwkBaseFilterEntry 1406 PIB-ACCESS install 1407 STATUS current 1408 DESCRIPTION 1409 "The Base Filter class. A packet has to match all 1410 fields in an Filter. Wildcards may be specified for those 1411 fields that are not relevant." 1413 ::= { frwkClassifierClasses 1 } 1415 frwkBaseFilterEntry OBJECT-TYPE 1416 SYNTAX FrwkBaseFilterEntry 1417 STATUS current 1418 DESCRIPTION 1419 "An instance of the frwkBaseFilter class." 1421 PIB-INDEX { frwkBaseFilterPrid } 1423 ::= { frwkBaseFilterTable 1 } 1425 FrwkBaseFilterEntry ::= SEQUENCE { 1426 frwkBaseFilterPrid InstanceId, 1427 frwkBaseFilterNegation TruthValue 1428 } 1430 frwkBaseFilterPrid OBJECT-TYPE 1431 SYNTAX InstanceId 1432 STATUS current 1433 DESCRIPTION 1434 "An integer index to uniquely identify this Filter among all 1435 the Filters." 1437 ::= { frwkBaseFilterEntry 1 } 1439 frwkBaseFilterNegation OBJECT-TYPE 1440 SYNTAX TruthValue 1441 STATUS current 1442 DESCRIPTION 1443 "This attribute behaves like a logical NOT for the filter. 1444 If the packet matches this filter and the value of this 1445 attribute is true, the action associated with this filter 1446 is not applied to the packet. If the value of this 1447 attribute is false, then the action is applied to the 1448 packet." 1450 ::= { frwkBaseFilterEntry 2 } 1452 -- 1453 -- The IP Filter Table 1454 -- 1456 frwkIpFilterTable OBJECT-TYPE 1457 SYNTAX SEQUENCE OF FrwkIpFilterEntry 1458 PIB-ACCESS install 1459 STATUS current 1460 DESCRIPTION 1461 "Filter definitions. A packet has to match all fields in a 1462 filter. Wildcards may be specified for those fields that 1463 are not relevant." 1465 INSTALL-ERRORS { 1466 invalidDstL4PortData(1), 1467 invalidSrcL4PortData(2) 1468 } 1469 ::= { frwkClassifierClasses 2 } 1471 frwkIpFilterEntry OBJECT-TYPE 1472 SYNTAX FrwkIpFilterEntry 1473 STATUS current 1474 DESCRIPTION 1475 "An instance of the frwkIpFilter class." 1477 EXTENDS { frwkBaseFilterEntry } 1478 UNIQUENESS { frwkBaseFilterNegation, 1479 frwkIpFilterDstAddrType, 1480 frwkIpFilterDstAddr, 1481 frwkIpFilterDstAddrMask, 1482 frwkIpFilterSrcAddrType, 1483 frwkIpFilterSrcAddr, 1484 frwkIpFilterSrcAddrMask, 1485 frwkIpFilterDscp, 1486 frwkIpFilterProtocol, 1487 frwkIpFilterDstL4PortMin, 1488 frwkIpFilterDstL4PortMax, 1489 frwkIpFilterSrcL4PortMin, 1490 frwkIpFilterSrcL4PortMax } 1492 ::= { frwkIpFilterTable 1 } 1494 FrwkIpFilterEntry ::= SEQUENCE { 1495 frwkIpFilterDstAddrType InetAddressType, 1496 frwkIpFilterDstAddr InetAddress, 1497 frwkIpFilterDstAddrMask Unsigned32, 1498 frwkIpFilterSrcAddrType InetAddressType, 1499 frwkIpFilterSrcAddr InetAddress, 1500 frwkIpFilterSrcAddrMask Unsigned32, 1501 frwkIpFilterDscp Integer32, 1502 frwkIpFilterProtocol Integer32, 1503 frwkIpFilterDstL4PortMin Unsigned32, 1504 frwkIpFilterDstL4PortMax Unsigned32, 1505 frwkIpFilterSrcL4PortMin Unsigned32, 1506 frwkIpFilterSrcL4PortMax Unsigned32 1507 } 1509 frwkIpFilterDstAddrType OBJECT-TYPE 1511 SYNTAX InetAddressType 1512 STATUS current 1513 DESCRIPTION 1514 "The address type enumeration value [INETADDR] to specify 1515 the type of the packet's destination IP address." 1517 ::= { frwkIpFilterEntry 1 } 1519 frwkIpFilterDstAddr OBJECT-TYPE 1521 SYNTAX InetAddress 1522 STATUS current 1523 DESCRIPTION 1524 "The IP address [INETADDR] to match against the packet's 1525 destination IP address." 1527 ::= { frwkIpFilterEntry 2 } 1529 frwkIpFilterDstAddrMask OBJECT-TYPE 1530 SYNTAX Unsigned32 (0..128) 1531 STATUS current 1532 DESCRIPTION 1533 "The length of a mask for the matching of the destination 1534 IP address. Masks are constructed by setting bits in 1535 sequence from the most-significant bit downwards for 1536 frwkIpFilterDstAddrMask bits length. All other bits in the 1537 mask, up to the number needed to fill the length of the 1538 address frwkIpFilterDstAddr are cleared to zero. A zero bit 1539 in the mask then means that the corresponding bit in the 1540 address always matches." 1542 ::= { frwkIpFilterEntry 3 } 1544 frwkIpFilterSrcAddrType OBJECT-TYPE 1546 SYNTAX InetAddressType 1547 STATUS current 1548 DESCRIPTION 1549 "The address type enumeration value to specify the type of 1550 the packet's source IP address." 1552 ::= { frwkIpFilterEntry 4 } 1554 frwkIpFilterSrcAddr OBJECT-TYPE 1555 SYNTAX InetAddress 1556 STATUS current 1557 DESCRIPTION 1558 "The IP address to match against the packet's source IP 1559 address." 1561 ::= { frwkIpFilterEntry 5 } 1563 frwkIpFilterSrcAddrMask OBJECT-TYPE 1564 SYNTAX Unsigned32 (0..128) 1565 STATUS current 1566 DESCRIPTION 1567 "The length of a mask for the matching of the source IP 1568 address. Masks are constructed by setting bits in sequence 1569 from the most-significant bit downwards for 1570 frwkIpFilterSrcAddrMask bits length. All other bits in the 1571 mask, up to the number needed to fill the length of the 1572 address frwkIpFilterSrcAddr are cleared to zero. A zero bit 1573 in the mask then means that the corresponding bit in the 1574 address always matches." 1576 ::= { frwkIpFilterEntry 6 } 1578 frwkIpFilterDscp OBJECT-TYPE 1579 SYNTAX Integer32 (-1 | 0..63) 1580 STATUS current 1581 DESCRIPTION 1582 "The value that the DSCP in the packet can have and 1583 match this filter. A value of -1 indicates that a specific 1584 DSCP value has not been defined and thus all DSCP values 1585 are considered a match." 1587 ::= { frwkIpFilterEntry 7 } 1589 frwkIpFilterProtocol OBJECT-TYPE 1590 SYNTAX Integer32 (-1 | 0..255) 1591 STATUS current 1592 DESCRIPTION 1593 "The IP protocol to match against the packet's protocol. 1594 A value of -1 means match all." 1596 ::= { frwkIpFilterEntry 8 } 1598 frwkIpFilterDstL4PortMin OBJECT-TYPE 1599 SYNTAX Unsigned32 (0..65535) 1600 STATUS current 1601 DESCRIPTION 1602 "The minimum value that the packet's layer 4 destination 1603 port number can have and match this filter. This value must 1604 be equal to or lesser that the value specified for this 1605 filter in frwkIpFilterDstL4PortMax." 1607 ::= { frwkIpFilterEntry 9 } 1609 frwkIpFilterDstL4PortMax OBJECT-TYPE 1610 SYNTAX Unsigned32 (0..65535) 1611 STATUS current 1612 DESCRIPTION 1613 "The maximum value that the packet's layer 4 destination 1614 port number can have and match this filter. This value must 1615 be equal to or greater that the value specified for this 1616 filter in frwkIpFilterDstL4PortMin." 1618 ::= { frwkIpFilterEntry 10 } 1620 frwkIpFilterSrcL4PortMin OBJECT-TYPE 1621 SYNTAX Unsigned32 (0..65535) 1622 STATUS current 1623 DESCRIPTION 1624 "The minimum value that the packet's layer 4 source port 1625 number can have and match this filter. This value must 1626 be equal to or lesser that the value specified for this 1627 filter in frwkIpFilterSrcL4PortMax." 1629 ::= { frwkIpFilterEntry 11 } 1631 frwkIpFilterSrcL4PortMax OBJECT-TYPE 1632 SYNTAX Unsigned32 (0..65535) 1633 STATUS current 1634 DESCRIPTION 1635 "The maximum value that the packet's layer 4 source port 1636 number can have and match this filter. This value must be 1637 equal to or greater that the value specified for this filter 1638 in frwkIpFilterSrcL4PortMin." 1640 ::= { frwkIpFilterEntry 12 } 1642 -- 1643 -- The IEEE 802 Filter Table 1644 -- 1646 -- The IEEE 802 Filter Table supports the specification of IEEE 1647 -- 802-based [802] (e.g., 802.3) information that is used to perform 1648 -- traffic classification. 1649 -- 1651 frwk802FilterTable OBJECT-TYPE 1652 SYNTAX SEQUENCE OF Frwk802FilterEntry 1653 PIB-ACCESS install 1654 STATUS current 1655 DESCRIPTION 1656 "IEEE 802-based filter definitions. A class that contains 1657 attributes of IEEE 802 (e.g., 802.3) traffic that form 1658 filters that are used to perform traffic classification." 1660 ::= { frwkClassifierClasses 3 } 1662 frwk802FilterEntry OBJECT-TYPE 1663 SYNTAX Frwk802FilterEntry 1664 STATUS current 1665 DESCRIPTION 1666 "IEEE 802-based filter definitions. An entry specifies 1667 (potentially) several distinct matching components. Each 1668 component is tested against the data in a frame 1669 individually. An overall match occurs when all of the 1670 individual components match the data they are compared 1671 against in the frame being processed. A failure of any 1672 one test causes the overall match to fail. 1674 Wildcards may be specified for those fields that are not 1675 relevant." 1677 EXTENDS { frwkBaseFilterEntry } 1678 UNIQUENESS { frwkBaseFilterNegation, 1679 frwk802FilterDstAddr, 1680 frwk802FilterDstAddrMask, 1681 frwk802FilterSrcAddr, 1682 frwk802FilterSrcAddrMask, 1683 frwk802FilterVlanId, 1684 frwk802FilterVlanTagRequired, 1685 frwk802FilterEtherType, 1686 frwk802FilterUserPriority } 1688 ::= { frwk802FilterTable 1 } 1690 Frwk802FilterEntry ::= SEQUENCE { 1691 frwk802FilterDstAddr PhysAddress, 1692 frwk802FilterDstAddrMask PhysAddress, 1693 frwk802FilterSrcAddr PhysAddress, 1694 frwk802FilterSrcAddrMask PhysAddress, 1695 frwk802FilterVlanId Integer32, 1696 frwk802FilterVlanTagRequired Unsigned32, 1697 frwk802FilterEtherType Integer32, 1698 frwk802FilterUserPriority BITS 1699 } 1701 frwk802FilterDstAddr OBJECT-TYPE 1702 SYNTAX PhysAddress 1703 STATUS current 1705 DESCRIPTION 1706 "The 802 address against which the 802 DA of incoming 1707 traffic streams will be compared. Frames whose 802 DA 1708 matches the physical address specified by this object, 1709 taking into account address wildcarding as specified by the 1710 frwk802FilterDstAddrMask object, are potentially subject to 1711 the processing guidelines that are associated with this 1712 entry through the related action class." 1714 ::= { frwk802FilterEntry 1 } 1716 frwk802FilterDstAddrMask OBJECT-TYPE 1717 SYNTAX PhysAddress 1718 STATUS current 1719 DESCRIPTION 1720 "This object specifies the bits in a 802 destination address 1721 that should be considered when performing a 802 DA 1722 comparison against the address specified in the 1723 frwk802FilterDstAddr object. 1725 The value of this object represents a mask that is logically 1726 and'ed with the 802 DA in received frames to derive the 1727 value to be compared against the frwk802FilterDstAddr 1728 address. A zero bit in the mask thus means that the 1729 corresponding bit in the address always matches. The 1730 frwk802FilterDstAddr value must also be masked using this 1731 value prior to any comparisons. 1733 The length of this object in octets must equal the length in 1734 octets of the frwk802FilterDstAddr. Note that a mask with no 1735 bits set (i.e., all zeroes) effectively wildcards the 1736 frwk802FilterDstAddr object." 1738 ::= { frwk802FilterEntry 2 } 1740 frwk802FilterSrcAddr OBJECT-TYPE 1741 SYNTAX PhysAddress 1742 STATUS current 1743 DESCRIPTION 1744 "The 802 MAC address against which the 802 MAC SA of 1745 incoming traffic streams will be compared. Frames whose 802 1746 MAC SA matches the physical address specified by this 1747 object, taking into account address wildcarding as specified 1748 by the frwk802FilterSrcAddrMask object, are potentially 1749 subject to the processing guidelines that are associated 1750 with this entry through the related action class." 1752 ::= { frwk802FilterEntry 3 } 1754 frwk802FilterSrcAddrMask OBJECT-TYPE 1755 SYNTAX PhysAddress 1756 STATUS current 1757 DESCRIPTION 1758 "This object specifies the bits in a 802 MAC source address 1759 that should be considered when performing a 802 MAC SA 1760 comparison against the address specified in the 1761 frwk802FilterSrcAddr object. 1763 The value of this object represents a mask that is logically 1764 and'ed with the 802 MAC SA in received frames to derive the 1765 value to be compared against the frwk802FilterSrcAddr 1766 address. A zero bit in the mask thus means that the 1767 corresponding bit in the address always matches. The 1768 frwk802FilterSrcAddr value must also be masked using this 1769 value prior to any comparisons. 1771 The length of this object in octets must equal the length in 1772 octets of the frwk802FilterSrcAddr. Note that a mask with no 1773 bits set (i.e., all zeroes) effectively wildcards the 1774 frwk802FilterSrcAddr object." 1776 ::= { frwk802FilterEntry 4 } 1778 frwk802FilterVlanId OBJECT-TYPE 1779 SYNTAX Integer32 (-1 | 1..4094) 1780 STATUS current 1781 DESCRIPTION 1782 "The VLAN ID (VID) that uniquely identifies a VLAN 1783 within the device. This VLAN may be known or unknown 1784 (i.e., traffic associated with this VID has not yet 1785 been seen by the device) at the time this entry 1786 is instantiated. 1788 Setting the frwk802FilterVlanId object to -1 indicates that 1789 VLAN data should not be considered during traffic 1790 classification." 1792 ::= { frwk802FilterEntry 5 } 1794 frwk802FilterVlanTagRequired OBJECT-TYPE 1795 SYNTAX Unsigned32 { 1796 taggedOnly(1), 1797 priorityTaggedPlus(2), 1798 untaggedOnly(3), 1799 ignoreTag(4) 1800 } 1801 STATUS current 1802 DESCRIPTION 1803 "This object indicates whether the presence of an 1804 IEEE 802.1Q VLAN tag in data link layer frames must 1805 be considered when determining if a given frame 1806 matches this 802 filter entry. 1808 A value of 'taggedOnly(1)' means that only frames 1809 containing a VLAN tag with a non-Null VID (i.e., a 1810 VID in the range 1..4094) will be considered a match. 1812 A value of 'priorityTaggedPlus(2)' means that only 1813 frames containing a VLAN tag, regardless of the value 1814 of the VID, will be considered a match. 1816 A value of 'untaggedOnly(3)' indicates that only 1817 untagged frames will match this filter component. 1819 The presence of a VLAN tag is not taken into 1820 consideration in terms of a match if the value is 1821 'ignoreTag(4)'." 1823 ::= { frwk802FilterEntry 6 } 1825 frwk802FilterEtherType OBJECT-TYPE 1826 SYNTAX Integer32 (-1 | 0..'ffff'h) 1827 STATUS current 1828 DESCRIPTION 1829 "This object specifies the value that will be compared 1830 against the value contained in the EtherType field of an 1831 IEEE 802 frame. Example settings would include 'IP' 1832 (0x0800), 'ARP' (0x0806) and 'IPX' (0x8137). 1834 Setting the frwk802FilterEtherTypeMin object to -1 indicates 1835 that EtherType data should not be considered during traffic 1836 classification. 1838 Note that the position of the EtherType field depends on 1839 the underlying frame format. For Ethernet-II encapsulation, 1840 the EtherType field follows the 802 MAC source address. For 1841 802.2 LLC/SNAP encapsulation, the EtherType value follows 1842 the Organization Code field in the 802.2 SNAP header. The 1843 value that is tested with regard to this filter component 1844 therefore depends on the data link layer frame format being 1845 used. If this 802 filter component is active when there is 1846 no EtherType field in a frame (e.g., 802.2 LLC), a match is 1847 implied." 1849 ::= { frwk802FilterEntry 7 } 1851 frwk802FilterUserPriority OBJECT-TYPE 1852 SYNTAX BITS { 1853 matchPriority0(0), 1854 matchPriority1(1), 1855 matchPriority2(2), 1856 matchPriority3(3), 1857 matchPriority4(4), 1858 matchPriority5(5), 1859 matchPriority6(6), 1860 matchPriority7(7) 1861 } 1862 STATUS current 1863 DESCRIPTION 1864 "The set of values, representing the potential range 1865 of user priority values, against which the value contained 1866 in the user priority field of a tagged 802.1 frame is 1867 compared. A test for equality is performed when determining 1868 if a match exists between the data in a data link layer 1869 frame and the value of this 802 filter component. Multiple 1870 values may be set at one time such that potentially several 1871 different user priority values may match this 802 filter 1872 component. 1874 Setting all of the bits that are associated with this 1875 object causes all user priority values to match this 1876 attribute. This essentially makes any comparisons 1877 with regard to user priority values unnecessary. Untagged 1878 frames are treated as an implicit match." 1880 ::= { frwk802FilterEntry 8 } 1882 -- 1883 -- Conformance Section 1884 -- 1886 frwkBasePibConformance 1887 OBJECT IDENTIFIER ::= { frameworkPib 4 } 1889 frwkBasePibCompliances 1890 OBJECT IDENTIFIER ::= { frwkBasePibConformance 1 } 1892 frwkBasePibGroups 1893 OBJECT IDENTIFIER ::= { frwkBasePibConformance 2 } 1895 frwkBasePibCompliance MODULE-COMPLIANCE 1896 STATUS current 1897 DESCRIPTION 1898 "Describes the requirements for conformance to the 1899 Framework PIB." 1901 MODULE -- this module 1902 MANDATORY-GROUPS { frwkPrcSupportGroup, 1903 frwkPibIncarnationGroup, 1904 frwkDeviceIdGroup, 1905 frwkCompLimitsGroup, 1906 frwkIfCapSetGroup, 1907 frwkIfCapSetRoleComboGroup, 1908 frwkIfCapSetInterfaceGroup } 1910 OBJECT frwkPibIncarnationLongevity 1911 PIB-MIN-ACCESS notify 1912 DESCRIPTION "Install support is not required." 1914 OBJECT frwkPibIncarnationTtl 1915 PIB-MIN-ACCESS notify 1916 DESCRIPTION "Install support is not required." 1918 OBJECT frwkPibIncarnationActive 1919 PIB-MIN-ACCESS notify 1920 DESCRIPTION "Install support is not required." 1922 GROUP frwkBaseFilterGroup 1923 DESCRIPTION 1924 "The frwkBaseFilterGroup is mandatory if filtering 1925 based on traffic components is supported." 1927 GROUP frwkIpFilterGroup 1928 DESCRIPTION 1929 "The frwkIpFilterGroup is mandatory if filtering 1930 based on IP traffic components is supported." 1932 GROUP frwk802FilterGroup 1933 DESCRIPTION 1934 "The frwk802FilterGroup is mandatory if filtering 1935 based on 802 traffic criteria is supported." 1937 ::= { frwkBasePibCompliances 1 } 1939 frwkPrcSupportGroup OBJECT-GROUP 1940 OBJECTS { 1941 frwkPrcSupportSupportedPrc, 1942 frwkPrcSupportSupportedAttrs } 1943 STATUS current 1944 DESCRIPTION 1945 "Objects from the frwkPrcSupportTable." 1947 ::= { frwkBasePibGroups 1 } 1949 frwkPibIncarnationGroup OBJECT-GROUP 1950 OBJECTS { 1951 frwkPibIncarnationName, 1952 frwkPibIncarnationId, 1953 frwkPibIncarnationLongevity, 1954 frwkPibIncarnationTtl, 1955 frwkPibIncarnationActive } 1956 STATUS current 1957 DESCRIPTION 1958 "Objects from the frwkDevicePibIncarnationTable." 1960 ::= { frwkBasePibGroups 2 } 1962 frwkDeviceIdGroup OBJECT-GROUP 1963 OBJECTS { 1964 frwkDeviceIdDescr, 1965 frwkDeviceIdMaxMsg, 1966 frwkDeviceIdMaxContexts } 1967 STATUS current 1968 DESCRIPTION 1969 "Objects from the frwkDeviceIdTable." 1971 ::= { frwkBasePibGroups 3 } 1973 frwkCompLimitsGroup OBJECT-GROUP 1974 OBJECTS { 1975 frwkCompLimitsComponent, 1976 frwkCompLimitsAttrPos, 1977 frwkCompLimitsNegation, 1978 frwkCompLimitsType, 1979 frwkCompLimitsSubType, 1980 frwkCompLimitsGuidance } 1981 STATUS current 1982 DESCRIPTION 1983 "Objects from the frwkCompLimitsTable." 1985 ::= { frwkBasePibGroups 4 } 1987 frwkIfCapSetGroup OBJECT-GROUP 1988 OBJECTS { 1989 frwkIfCapSetName, 1990 frwkIfCapSetCapability } 1991 STATUS current 1992 DESCRIPTION 1993 "Objects from the frwkIfCapSetTable." 1995 ::= { frwkBasePibGroups 5 } 1997 frwkIfCapSetRoleComboGroup OBJECT-GROUP 1998 OBJECTS { 1999 frwkIfCapSetRoleComboName, 2000 frwkIfCapSetRoleComboRoles } 2001 STATUS current 2002 DESCRIPTION 2003 "Objects from the frwkIfCapSetRoleComboTable." 2005 ::= { frwkBasePibGroups 6 } 2007 frwkIfCapSetInterfaceGroup OBJECT-GROUP 2008 OBJECTS { 2009 frwkIfCapSetInterfaceIfIndex, 2010 frwkIfCapSetInterfaceRoles } 2011 STATUS current 2012 DESCRIPTION 2013 "Objects from the frwkIfCapSetInterfaceTable." 2015 ::= { frwkBasePibGroups 7 } 2017 frwkBaseFilterGroup OBJECT-GROUP 2018 OBJECTS { 2019 frwkBaseFilterNegation } 2020 STATUS current 2021 DESCRIPTION 2022 "Objects from the frwkBaseFilterTable." 2024 ::= { frwkBasePibGroups 8 } 2026 frwkIpFilterGroup OBJECT-GROUP 2027 OBJECTS { 2028 frwkIpFilterDstAddrType, 2029 frwkIpFilterDstAddr, 2030 frwkIpFilterDstAddrMask, 2031 frwkIpFilterSrcAddrType, 2032 frwkIpFilterSrcAddr, 2033 frwkIpFilterSrcAddrMask, 2034 frwkIpFilterDscp, 2035 frwkIpFilterProtocol, 2036 frwkIpFilterDstL4PortMin, 2037 frwkIpFilterDstL4PortMax, 2038 frwkIpFilterSrcL4PortMin, 2039 frwkIpFilterSrcL4PortMax } 2040 STATUS current 2041 DESCRIPTION 2042 "Objects from the frwkIpFilterTable." 2044 ::= { frwkBasePibGroups 9 } 2046 frwk802FilterGroup OBJECT-GROUP 2047 OBJECTS { 2048 frwk802FilterDstAddr, 2049 frwk802FilterDstAddrMask, 2050 frwk802FilterSrcAddr, 2051 frwk802FilterSrcAddrMask, 2052 frwk802FilterVlanId, 2053 frwk802FilterVlanTagRequired, 2054 frwk802FilterEtherType, 2055 frwk802FilterUserPriority } 2056 STATUS current 2057 DESCRIPTION 2058 "Objects from the frwk802FilterTable." 2060 ::= { frwkBasePibGroups 10 } 2062 END 2064 7. Security Considerations 2066 It is clear that this PIB is used for configuration using [COPS-PR], 2067 and anything that can be configured can be misconfigured, with 2068 potentially disastrous effect. At this writing, no security holes 2069 have been identified beyond those that the COPS base protocol 2070 security is itself intended to address. These relate primarily to 2071 controlled access to sensitive information and the ability to 2072 configure a device - or which might result from operator error, 2073 which is beyond the scope of any security architecture. 2075 There are a number of provisioning classes defined in this PIB that 2076 have a PIB-ACCESS clause of install (read-create). Such objects may 2077 be considered sensitive or vulnerable in some network environments. 2078 The support for "Install" decisions sent over [COPS-PR] in a non- 2079 secure environment without proper protection can have a negative 2080 effect on network operations. There are a number of provisioning 2081 classes in this PIB that may contain information that may be 2082 sensitive from a business perspective, in that they may represent a 2083 customer's service contract or the filters that the service provider 2084 chooses to apply to a customer's ingress or egress traffic. There 2085 are no PRCs that are sensitive in their own right, such as passwords 2086 or monetary amounts. It may be important to control even 2087 "Notify"(read-only) access to these PRCs and possibly to even 2088 encrypt the values of these PRIs when sending them over the network 2089 via COPS-PR. The use of IPSEC between the PDP and the PEP, as 2090 described in [COPS], provides the necessary protection against 2091 security threats. However, even if the network itself is secure, 2092 there is no control as to who on the secure network is allowed to 2093 "Install/Notify" (read/change/create/delete) the PRIs in this PIB. 2095 It is then a customer/user responsibility to ensure that the PEP/PDP 2096 giving access to an instance of this PIB, is properly configured to 2097 give access to the PRIs only to those principals (users) that have 2098 legitimate rights to indeed "Install" or "Notify" (change/create/ 2099 delete) them. 2101 8. Author Information and Acknowledgments 2103 Michael Fine 2104 Cisco Systems, Inc. 2105 170 West Tasman Drive 2106 San Jose, CA 95134-1706 USA 2107 Phone: +1 408 527 8218 2108 Email: mfine@cisco.com 2110 Keith McCloghrie 2111 Cisco Systems, Inc. 2112 170 West Tasman Drive 2113 San Jose, CA 95134-1706 USA 2114 Phone: +1 408 526 5260 2115 Email: kzm@cisco.com 2116 John Seligson 2117 Nortel Networks, Inc. 2118 4401 Great America Parkway 2119 Santa Clara, CA 95054 USA 2120 Phone: +1 408 495 2992 2121 Email: jseligso@nortelnetworks.com 2123 Kwok Ho Chan 2124 Nortel Networks, Inc. 2125 600 Technology Park Drive 2126 Billerica, MA 01821 USA 2127 Phone: +1 978 288 8175 2128 Email: khchan@nortelnetworks.com 2130 Scott Hahn 2131 Intel Corp. 2132 2111 NE 25th Avenue 2133 Hillsboro, OR 97124 USA 2134 Phone: +1 503 264 8231 2135 Email: scott.hahn@intel.com 2137 Ravi Sahita 2138 Intel Corp. 2139 2111 NE 25th Avenue 2140 Hillsboro, OR 97124 USA 2141 Phone: +1 503 712 1554 2142 Email: ravi.sahita@intel.com 2144 Andrew Smith 2145 Allegro Networks 2146 6399 San Ignacio Ave. 2147 San Jose 2148 CA 95119 2149 FAX: 415 345 1827 2150 Email: andrew@allegronetworks.com 2152 Francis Reichmeyer 2153 PFN, Inc. 2154 University Park at MIT 2155 26 Landsdowne Street 2156 Cambridge, MA 02139 2157 Phone: +1 617 494 9980 2158 Email: franr@pfn.com 2160 Special thanks to Carol Bell and David Durham for their many 2161 significant comments. 2163 9. References 2165 [COPS] 2166 Boyle, J., Cohen, R., Durham, D., Herzog, S., Rajan, R., and 2167 A. Sastry, "The COPS (Common Open Policy Service) Protocol" 2168 RFC 2748, January 2000. 2170 [COPS-PR] 2171 K. Chan, D. Durham, S. Gai, S. Herzog, K. McCloghrie, 2172 F. Reichmeyer, J. Seligson, A. Smith, R. Yavatkar, "COPS Usage 2173 for Policy Provisioning," RFC 3084, March 2001. 2175 [SPPI] 2176 K. McCloghrie, M. Fine, J. Seligson, K. Chan, S. Hahn, 2177 R. Sahita, A. Smith, F. Reichmeyer, "Structure of Policy 2178 Provisioning Information," draft-ietf-rap-sppi-07.txt, 2179 May 2001. 2181 [RAP-FRAMEWORK] 2182 R. Yavatkar, D. Pendarakis, "A Framework for Policy-based 2183 Admission Control", RFC 2753, January 2000. 2185 [SNMP-SMI] 2186 K. McCloghrie, D. Perkins, J. Schoenwaelder, J. Case, M. Rose 2187 and S. Waldbusser, "Structure of Management Information 2188 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 2190 [INETADDR] 2191 M. Daniele, B. Haberman, S. Routhier and J. Schoenwaelder " 2192 Textual Conventions for Internet Network Addresses" RFC 2851, 2193 June 2000 2195 [IFMIB] 2196 K. McCloghrie, F. Kastenholz, "The Interface Group MIB using 2197 SMIv2" RFC 2233, November 1977. 2199 [802] 2200 IEEE Standards for Local and Metropolitan Area Networks: 2201 Overview and Architecture, ANSI/IEEE Std 802, 1990. 2203 [SNMPFRWK] 2204 Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture 2205 for Describing SNMP Management Frameworks", RFC 2571, 2206 May 1999 2208 [STD17] 2209 K. McCloghrie, M. Rose "Management Information Base for Network 2210 Management of TCP/IP-based internets: MIB-II" STD 17, RFC 1213, 2211 March 1991 2213 10. Full Copyright 2215 Copyright (C) The Internet Society (2000). All Rights Reserved. This 2216 document and translations of it may be copied and furnished to 2217 others, and derivative works that comment on or otherwise explain it 2218 or assist in its implementation may be prepared, copied, published 2219 and distributed, in whole or in part, without restriction of any 2220 kind, provided that the above copyright notice and this paragraph 2221 are included on all such copies and derivative works. However, this 2222 document itself may not be modified in any way, such as by removing 2223 the copyright notice or references to the Internet Society or other 2224 Internet organizations, except as needed for the purpose of 2225 developing Internet standards in which case the procedures for 2226 copyrights defined in the Internet Standards process must be 2227 followed, or as required to translate it into languages other than 2228 English. 2230 The limited permissions granted above are perpetual and will not be 2231 revoked by the Internet Society or its successors or assigns. 2233 This document and the information contained herein is provided on an 2234 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2235 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2236 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2237 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2238 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2240 Table of Contents 2242 Status of this Memo...............................................1 2243 1. Glossary.......................................................2 2244 2. Introduction...................................................2 2245 3. General PIB Concepts...........................................2 2246 3.1. Roles........................................................2 2247 3.1.1. An Example.................................................4 2248 3.2. Multiple PIB Instances.......................................5 2249 3.3. Reporting and Configuring of Device Capabilities.............6 2250 3.4. Reporting of Device Limitations..............................6 2251 4. The Framework Role PIB module..................................7 2252 5. Summary of the Framework PIB...................................9 2253 6. The Framework PIB Module......................................12 2254 7. Security Considerations.......................................43 2255 8. Author Information and Acknowledgments........................43 2256 9. References....................................................45 2257 10. Full Copyright...............................................46