idnits 2.17.1 draft-ietf-rap-frameworkpib-04.txt: -(88): 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 is 1 instance 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 60 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 157: '...ct, then the PEP MUST reject the insta...' RFC 2119 keyword, line 175: '...ters "+" and "*" MUST not be used in a...' RFC 2119 keyword, line 250: '... instance MUST ensure that the attri...' RFC 2119 keyword, line 357: '...tifies a PRC. The value MUST be an OID...' RFC 2119 keyword, line 390: '...ved over COPS-PR MUST be the unique SU...' (12 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 142 has weird spacing: '... PRI of a fic...' == Line 1087 has weird spacing: '...ddrMask attrV...' == Line 1088 has weird spacing: '...ddrMask attrV...' == Line 1089 has weird spacing: '...Limited range...' == Line 1090 has weird spacing: '...Limited range...' == (4 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: 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 (March 1, 2001) is 8456 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 2047, but no explicit reference was found in the text == Unused Reference: 'SNMPFRWK' is defined on line 2061, but no explicit reference was found in the text ** Downref: Normative reference to an Historic draft: draft-ietf-rap-pr (ref. 'COPS-PR') == Outdated reference: A later version (-07) exists of draft-ietf-rap-sppi-05 ** 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) -- Possible downref: Non-RFC (?) normative reference: ref. '802' ** Obsolete normative reference: RFC 2571 (ref. 'SNMPFRWK') (Obsoleted by RFC 3411) Summary: 14 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 September 2001 K. McCloghrie 4 File: draft-ietf-rap-frameworkpib-04.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 March 1, 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/ietf/1id-abstracts.txt 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 reports all its role combinations to the PDP in the initial 108 COPS request (REQ) message and in subsequent request messages 109 generated in response to COPS state synchronization (SSQ) requests 110 and local configuration changes. 112 The comparing of roles (or role combinations) is case sensitive. 114 By convention, when formatting the role-combination for exchange 115 within a protocol message, within a PIB/MIB object's value, or as a 116 printed value, the set is formatted in lexicographical order of the 117 role's ASCII values; that is, the role that is first is formatted 118 first. For example, "a+b" and "b+a" are NOT different role- 119 combinations; rather, they are different formatting of the same 120 role-combination, and hence for this example: 121 - "a+b" is the valid formatting of that role-combination, 122 - "b+a" is an invalid formatting of that role-combination. 124 The role-combination of interfaces to which no roles have been 125 assigned is known as the "null" role-combination. (Note the 126 deliberate use of lower-case letters for "null" so that it avoids 127 confusion with the ASCII NULL character that has a value of zero but 128 a length of one.) 130 In an "install" or an "install-notify" class, the wildcard role- 131 combination "*" can be used. In addition to providing for interface- 132 specific roles, it also allows for other optimizations in reducing 133 the number of role-combinations for which a policy has to be 134 specified. For example: 136 Suppose we have three interfaces: 138 Roles A, B and R1 are assigned to interface I1 139 Roles A, B and R2 are assigned to interface I2 140 Roles A, B and R3 are assigned to interface I3 142 Then, a PRI of a fictional IfDscpAssignTable that has the following 143 values for its attributes: 145 ifDscpAssignPrid = 1 146 ifDscpAssignRoles = "*+A+B" 147 ifDscpAssignName = "4queues" 148 ifDscpAssignDscpMap = 1 150 will apply to all three interfaces, because "*" matches with R1, R2 151 and R3. The policies can be assigned to an interface due to more 152 than one wild-carded role combo matching a given interface's role 153 combo string. The PDP should attempt to resolve conflicts between 154 policies before sending policies to the PEP. In the situation where 155 the PDP sends multiple policies to a PEP and they do conflict, 156 either because of an error by the PDP or because of a device- 157 specific conflict, then the PEP MUST reject the installation of the 158 conflicting policies and return an error. 160 Formally, 161 - The wildcard Role is denoted by "*", 162 - The "*" Role is not allowed to be defined as part of the role- 163 combination of an interface as notified by the PEP to the PDP; it 164 is only allowed in policies installed/deleted via COPS-PR from 165 the PDP to the PEP. 166 - For a policy to apply to an interface when the policy's role- 167 combination is "*+a+b", then the interface's role-combination: 168 - Must include "a" and "b", and 169 - Can include zero or more other roles. 170 - The wildcard character "*" is listed before the other roles as 171 "*" is lexicographically before "a"; however, the wildcard matches 172 any zero or more roles, irrespective of lexicographical order. 173 For example: "*+b+e+g" would match "a+b+c+e+f+g" 175 Note that the characters "+" and "*" MUST not be used in an 176 interface Role. The Framework Role PIB module in section 4 of this 177 document contains the Role and RoleCombination Textual Conventions. 179 3.1.1. An Example 181 The functioning of roles might be best understood by an example. 182 Suppose I have a device with three interfaces, with roles as 183 follows: 185 IF1: "finance" 186 IF2: "finance" 187 IF3: "manager" 189 Suppose, I also have a PDP with two policies: 191 P1: Packets from finance department (role "finance") get DSCP 5 192 P2: Packets from managers (role "manager") get DSCP 6 194 To obtain policy, the PEP reports to the PDP that it has some 195 interfaces with role combination "finance" and some with role 196 combination "manager". In response, the PDP downloads policy P1 197 associated with role combination "finance" and downloads a second 198 policy P2 associated with role combination "manager". 200 Now suppose the finance person attached to IF2 is promoted to 201 manager and so the system administrator adds the role "manager" to 202 IF2. The PEP now reports to the PDP that it has three role 203 combinations: some interfaces with role combination "finance", some 204 with role combination "manager" and some with role combination 205 "finance+manager". In response, the PDP downloads an additional 206 third policy associated with the new role combination 207 "finance+manager". 209 How the PDP determines the policy for this new role combination is 210 entirely the responsibility of the PDP. It could do so 211 algorithmically or by rule. For example, there might be a rule that 212 specifies that manager policy takes preference over department 213 policy. Or there might be a third policy installed in the PDP as 214 follows: 216 P3: Packets from finance managers (role "finance" and role 217 "manager") get DSCP 7 219 The point here is that the PDP is required to determine what policy 220 applies to this new role combination and to download a third policy 221 to the PEP for the role combination "finance+manager" even if that 222 policy is the same as one already downloaded. The PEP is not 223 required (or allowed) to construct policy for new role combinations 224 from existing policy. 226 3.2. Multiple PIB Instances 228 [COPS-PR] supports multiple, disjoint, independent instances of the 229 PIB to represent multiple instances of configured policy. The 230 intent is to allow for the pre-provisioning of policy that can then 231 be made active by a single, short decision from the PDP. 233 A COPS context can be defined as an independent COPS request state 234 for a particular subject category (client-type). 236 With the COPS-PR protocol, each of these states is identified by a 237 unique client handle. The creation and deletion of these PIB 238 instances is controlled by the PDP as described in [COPS-PR]. 240 Although many PIB instances may be configured on a device (the 241 maximum number of these instances being determined by the device 242 itself) only one of them can be active at any given time, the active 243 one being selected by the PDP. To facilitate this selection, the 244 Framework PIB supports an attribute to make a PIB instance the 245 active one and, similarly, to report the active PIB instance to the 246 PDP in a COPS request message. This attribute is in the Incarnation 247 Table described below. 249 Setting the attribute frwkPibIncarnationActive to 'true' in one PIB 250 instance MUST ensure that the attribute is 'false' in all other 251 contexts. 253 3.3. Reporting of Device Capabilities 255 Each network device providing policy-based services has its own 256 inherent capabilities. These capabilities can be hardware specific, 257 e.g., an ethernet interface supporting input classification, or can 258 be statically configured, e.g., supported queuing disciplines. 259 These capabilities are communicated to the PDP when initial policy 260 is requested by the PEP. Knowing device capabilities, the PDP can 261 send the provisioning instances (PRIs) relevant to the specific 262 device, rather than sending the entire PIB. 264 The PIB indicates which capabilities the PEP must report to the PDP 265 by means of the PIB-ACCESS clause as described in [SPPI]. 267 3.4. Reporting of Device Limitations 269 To facilitate efficient policy installation, it is important to 270 understand a device's limitations in relation to the advertised 271 device capabilities. Limitations may be class-based, e.g., an 272 "install" class is supported as a "notify" or only a limited number 273 of class instances may be created, or attribute-based. Attribute 274 limitations, such as supporting a restricted set of enumerations or 275 requiring related attributes to have certain values, detail 276 implementation limitations at a fine level of granularity. 278 A PDP can avoid certain installation issues in a proactive fashion 279 by taking into account a device's limitations prior to policy 280 installation rather than in a reactive mode during installation. As 281 with device capabilities, device limitations are communicated to the 282 PDP when initial policy is requested. 284 Reported device limitations may be accompanied by guidance values 285 that can be used by a PDP to determine acceptable values for the 286 identified attributes. 288 4. The Framework Role PIB module 290 FRAMEWORK-ROLE-PIB PIB-DEFINITIONS ::= BEGIN 292 IMPORTS MODULE-IDENTITY, TEXTUAL-CONVENTION FROM COPS-PR-SPPI 293 SnmpAdminString FROM SNMP-FRAMEWORK-MIB; 295 frwkRolePib MODULE-IDENTITY 296 SUBJECT-CATEGORIES { all } 297 LAST-UPDATED "200003010400Z" 298 ORGANIZATION "IETF RAP WG" 299 CONTACT-INFO "Keith McCloghrie 300 Cisco Systems, Inc. 301 170 West Tasman Drive, 302 San Jose, CA 95134-1706 USA 303 Phone: +1 408 526 5260 304 Email: kzm@cisco.com 306 John Seligson 307 Nortel Networks, Inc. 308 4401 Great America Parkway 309 Santa Clara, CA 95054 USA 310 Phone: +1 408 495 2992 311 Email: jseligso@nortelnetworks.com" 312 DESCRIPTION 313 "The PIB module containing the Role and 314 RoleCombination Textual Conventions and other 315 required TCs." 316 ::= { tbd } 318 Role ::= TEXTUAL-CONVENTION 319 STATUS current 320 DESCRIPTION 321 "A role represents a functionality characteristic or 322 capability of a resource to which policies are applied. 323 Examples of roles include Backbone_interface, 324 Frame_Relay_interface, BGP-capable-router, web-server, 325 firewall, etc. 326 Valid characters are a-z, A-Z, 0-9, period, hyphen and 327 underscore. A role must not start with an underscore." 328 SYNTAX SnmpAdminString (SIZE (1..31)) 330 RoleCombination ::= TEXTUAL-CONVENTION 331 STATUS current 332 DESCRIPTION 333 "A Display string consisting of a set of roles concatenated 334 with a '+' character where the roles are in lexicographic 335 order from minimum to maximum. 336 For example, a+b and b+a are NOT different 337 role-combinations; rather, they are different formatting of 338 the same (one) role-combination. 340 Notice the roles within a role-combination are in 341 Lexicographic order from minimum to maximum, hence, we 342 declare: 343 a+b is the valid formatting of the role-combination, 344 b+a is an invalid formatting of the role-combination. 346 Notice the need of zero-length role-combination as the role- 347 combination of interfaces to which no roles have been 348 assigned. This role-combination is also known as the null 349 role-combination. (Note the deliberate use of lower case 350 letters to avoid confusion with the ASCII NULL character 351 which has a value of zero but length of one.)" 352 SYNTAX SnmpAdminString (SIZE (0..255)) 354 PrcIdentifier ::= TEXTUAL-CONVENTION 355 STATUS current 356 DESCRIPTION 357 "An OID that identifies a PRC. The value MUST be an OID 358 assigned to a PRC's row definition. An attribute with this 359 syntax can have the value 0.0 to indicate that it currently 360 does not identify a PRC." 361 SYNTAX OBJECT IDENTIFIER 363 END 365 5. Summary of the Framework PIB 367 The Framework PIB comprises of three groups: 369 1. Base PIB classes Group 371 This contains PRCs intended to describe the PRCs supported 372 by the PEP, PRC and/or attribute limitations and its current 373 configuration. 375 PRC Support Table 377 As the technology evolves, we expect devices to be enhanced 378 with new PIBs, existing PIBs to add new PRCs and existing PRCs 379 to be augmented or extended with new attributes. Also, it is 380 likely that some existing PRCs or individual attributes of PRCs 381 will be deprecated. The PRC Support Table describes the PRCs 382 that the device supports as well as the individual attributes 383 of each PRC. Using this information the PDP can potentially 384 tailor the policy to more closely match the capabilities of the 385 device. The PRC Support Table instances are specific to the 386 particular Subject Category (Client-Type). That is, the PRC 387 Support Table for Subject Category 'A' will not include 388 instances for classes supported by the Subject Category 'B'. 389 Note that the COPS client-type [COPS] used for Framework PIB 390 PRIs sent/received over COPS-PR MUST be the unique SUBJECT- 391 CATEGORY number assigned for the area of policy being managed 392 (eg. QoS, Security etc). 394 The PEP MUST ignore the attributes that it reports as not 395 Supported in the decision from the PDP. The PEP SHOULD not send 396 duplicate PRC support instances in a COPS Request and the PDP 397 MUST ignore duplicate instances and MUST use the first instance 398 received for a supported PRC in a COPS Request. 400 PIB Incarnation Table 402 This table contains exactly one row (corresponding to one PRI) 403 per context. It identifies the PDP that was the last to 404 download policy into the device and also contains an identifier 405 to identify the version of the policy currently downloaded. 406 This identifier, both its syntax and value, is meaningful only 407 to the PDPs. It is intended to be a mechanism whereby a PDP, 408 on connecting to a PEP, can easily identify a known incarnation 409 of policy. The incarnation PRC also includes an attribute to 410 indicate which context is the active one at the present time. 411 The incarnation instance is specific to the particular Subject 412 Category (Client-Type). 414 Component Limitations Table 416 Some devices may not be able to implement the full range of 417 values for all attributes. In principle, each PRC supports a 418 set of errors that the PEP can report to the PDP in the event 419 that the specified policy is not implementable. It may be 420 preferable for the PDP to be informed of the device limitations 421 before actually attempting to install policy, and while the 422 error can indicate that a particular attribute value is 423 unacceptable to the PEP, this does not help the PDP ascertain 424 which values would be acceptable. To alleviate these 425 limitations, the PEP can report some limitations of attribute 426 values and/or classes and possibly guidance values for the 427 attribute in the Component Limitations Table 429 Device Identification Table 431 This class contains a single provisioning instance that 432 contains device-specific information that is used to facilitate 433 efficient policy installation by a PDP. The instance of this 434 class is reported to the PDP in a COPS request message so that 435 the PDP can take into account certain device characteristics 436 during policy installation. 438 2. Device Capabilities group 440 This group contains the PRCs that describe the characteristics of 441 interfaces of the device and the Role Combinations assigned to 442 them. 444 Interface Capabilities Set Table 446 The interfaces the PEP supports are described by rows in 447 this table (frwkIfCapSetTable). Each row, or instance of this 448 class, associates a unique interface name with a set of 449 capabilities that the interface supports. The unique name is 450 used to form a set of capabilities that the name represents. 451 The capability references can specify instances in relevant 452 capability tables in any PIB. The PEP notifies the PDP of these 453 interface names and capabilities and then the PDP configures 454 the interfaces, per role combination. The unique name 455 (IfCapSetName) is not to be confused with the IfType object in 456 MIB-II [STD17]. 458 Interface Capability and Role Combo Table 460 The Interface Capabilities Set Table (explained above) 461 describes the interfaces the PEP supports by their 462 capabilities, by assigning the capability sets a unique name. 463 It is possible to tailor the behavior of interfaces by 464 assigning specific roles to the capability sets. This allows 465 interfaces with the same capability sets to be assigned 466 different policies, based on the current roles assigned to 467 them. At the PDP, configuration is done in terms of these 468 interface capability set names (ifCapSetName) and the role 469 combinations assigned to them; The PDP does not deal with 470 individual interfaces on the device. Thus, each row of this 471 class is a two- 472 tuple, that indicates the roles that have been assigned to a 473 particular capability set (as identified by IfCapSetName). The 474 ifCapSetName is the grouping attribute used to form a set of 475 role combinations that apply to this capability set. 477 3. Classifier group 479 This group contains the IP and IEEE 802 Classifier elements. The 480 set of tables consist of a Base Filter table that contains the 481 Index InstanceId and the Negation flag for the filter. This 482 frwkBaseFilterTable is extended to form the IP Filter table and 483 the 802 Filter table [802]. Filters may also be defined outside 484 this document and used to extend the Base Filter table. 486 The Extended classes do not have a separate Index value. 487 Instances of the extended classes have the same indices as their 488 base class instance. Inheritance is achieved using the EXTENDS 489 keyword as defined in [SPPI]. 491 6. The Framework PIB Module 493 FRAMEWORK-PIB PIB-DEFINITIONS ::= BEGIN 495 IMPORTS 496 Unsigned32, Integer32, MODULE-IDENTITY, 497 MODULE-COMPLIANCE, OBJECT-TYPE, OBJECT-GROUP 498 FROM COPS-PR-SPPI 499 InstanceId, Prid 500 FROM COPS-PR-SPPI-TC 501 RoleCombination, PrcIdentifier 502 FROM FRAMEWORK-ROLE-PIB 503 InetAddress, InetAddressType 504 FROM INET-ADDRESS-MIB 505 TruthValue, PhysAddress 506 FROM SNMPv2-TC 507 SnmpAdminString 508 FROM SNMP-FRAMEWORK-MIB; 510 frameworkPib MODULE-IDENTITY 511 SUBJECT-CATEGORIES { all } 512 LAST-UPDATED "200003010400Z" 513 ORGANIZATION "IETF RAP WG" 514 CONTACT-INFO " 515 Michael Fine 516 Cisco Systems, Inc. 517 170 West Tasman Drive 518 San Jose, CA 95134-1706 USA 519 Phone: +1 408 527 8218 520 Email: mfine@cisco.com 522 Keith McCloghrie 523 Cisco Systems, Inc. 524 170 West Tasman Drive, 525 San Jose, CA 95134-1706 USA 526 Phone: +1 408 526 5260 527 Email: kzm@cisco.com 529 John Seligson 530 Nortel Networks, Inc. 531 4401 Great America Parkway 532 Santa Clara, CA 95054 USA 533 Phone: +1 408 495 2992 534 Email: jseligso@nortelnetworks.com" 535 DESCRIPTION 536 "A PIB module containing the base set of provisioning 537 classes that are required for support of policies for 538 all subject-categories." 540 ::= { tbd } 542 -- 543 -- The root OID for PRCs in the Framework PIB 544 -- 546 frwkBasePibClasses 547 OBJECT IDENTIFIER ::= { frameworkPib 1 } 549 -- 550 -- Textual Conventions 551 -- 553 -- 554 -- PRC Support Table 555 -- 557 frwkPrcSupportTable OBJECT-TYPE 558 SYNTAX SEQUENCE OF FrwkPrcSupportEntry 559 PIB-ACCESS notify 560 STATUS current 561 DESCRIPTION 562 "Each instance of this class specifies a PRC that the device 563 supports and a bit string to indicate the attributes of the 564 class that are supported. These PRIs are sent to the PDP to 565 indicate to the PDP which PRCs, and which attributes of 566 these PRCs, the device supports. This table can also be 567 downloaded by a network manager when static configuration is 568 used. 570 All install and install-notify PRCs supported by the device 571 must be represented in this table. Notify PRCs may be 572 represented for informational purposes." 574 ::= { frwkBasePibClasses 1 } 576 frwkPrcSupportEntry OBJECT-TYPE 577 SYNTAX FrwkPrcSupportEntry 578 STATUS current 579 DESCRIPTION 580 "An instance of the frwkPrcSupport class that identifies a 581 specific PRC and associated attributes as supported 582 by the device." 584 PIB-INDEX { frwkPrcSupportPrid } 585 UNIQUENESS { frwkPrcSupportSupportedPrc } 587 ::= { frwkPrcSupportTable 1 } 589 FrwkPrcSupportEntry ::= SEQUENCE { 590 frwkPrcSupportPrid InstanceId, 591 frwkPrcSupportSupportedPrc PrcIdentifier, 592 frwkPrcSupportSupportedAttrs OCTET STRING 593 } 595 frwkPrcSupportPrid OBJECT-TYPE 596 SYNTAX InstanceId 597 STATUS current 598 DESCRIPTION 599 "An arbitrary integer index that uniquely identifies an 600 instance of the frwkPrcSupport class." 602 ::= { frwkPrcSupportEntry 1 } 604 frwkPrcSupportSupportedPrc OBJECT-TYPE 605 SYNTAX PrcIdentifier 606 STATUS current 607 DESCRIPTION 608 "The object identifier of a supported PRC. The value is the 609 OID of the table entry. There may not be more than one 610 instance of the frwkPrcSupport class with the same value of 611 frwkPrcSupportSupportedPrc." 613 ::= { frwkPrcSupportEntry 2 } 615 frwkPrcSupportSupportedAttrs OBJECT-TYPE 616 SYNTAX OCTET STRING 617 STATUS current 618 DESCRIPTION 619 "A bit string representing the supported attributes of the 620 class that is identified by the frwkPrcSupportSupportedPrc 621 object. 623 Each bit of this bit string corresponds to a class 624 attribute, with the most significant bit of the i-th octet 625 of this octet string corresponding to the (8*i - 7)-th 626 attribute, and the least significant bit of the i-th octet 627 corresponding to the (8*i)-th class attribute. Each bit 628 specifies whether or not the corresponding class attribute 629 is currently supported, with a '1' indicating support and a 630 '0' indicating no support. If the value of this bit string 631 is N bits long and there are more than N class attributes 632 then the bit string is logically extended with 0's to the 633 required length." 635 ::= { frwkPrcSupportEntry 3 } 637 -- 638 -- PIB Incarnation Table 639 -- 641 frwkPibIncarnationTable OBJECT-TYPE 642 SYNTAX SEQUENCE OF FrwkPibIncarnationEntry 643 PIB-ACCESS install-notify 644 STATUS current 645 DESCRIPTION 646 "This class contains a single provisioning instance per 647 installed context that identifies the current incarnation 648 of the PIB and the PDP or network manager that installed 649 this incarnation. The instance of this class is reported to 650 the PDP in the REQ message so that the PDP can (attempt to) 651 ascertain the current state of the PIB and the active 652 context. A network manager may use the instance to 653 determine the state of the device." 655 ::= { frwkBasePibClasses 2 } 657 frwkPibIncarnationEntry OBJECT-TYPE 658 SYNTAX FrwkPibIncarnationEntry 659 STATUS current 660 DESCRIPTION 661 "An instance of the frwkPibIncarnation class. Only 662 one instance of this provisioning class is ever 663 instantiated per context" 665 PIB-INDEX { frwkPibIncarnationPrid } 666 UNIQUENESS { frwkPibIncarnationName } 668 ::= { frwkPibIncarnationTable 1 } 670 FrwkPibIncarnationEntry ::= SEQUENCE { 671 frwkPibIncarnationPrid InstanceId, 672 frwkPibIncarnationName SnmpAdminString, 673 frwkPibIncarnationId OCTET STRING, 674 frwkPibIncarnationLongevity Unsigned32, 675 frwkPibIncarnationTtl Unsigned32, 676 frwkPibIncarnationActive TruthValue 677 } 679 frwkPibIncarnationPrid OBJECT-TYPE 680 SYNTAX InstanceId 681 STATUS current 682 DESCRIPTION 683 "An index to uniquely identify an instance of this 684 provisioning class." 686 ::= { frwkPibIncarnationEntry 1 } 688 frwkPibIncarnationName OBJECT-TYPE 689 SYNTAX SnmpAdminString 690 STATUS current 691 DESCRIPTION 692 "The name of the PDP that installed the current incarnation 693 of the PIB into the device. By default, it is the zero 694 length string." 696 ::= { frwkPibIncarnationEntry 2 } 698 frwkPibIncarnationId OBJECT-TYPE 699 SYNTAX OCTET STRING 700 STATUS current 701 DESCRIPTION 702 "An ID to identify the current incarnation. It has meaning 703 to the PDP/manager that installed the PIB and perhaps its 704 standby PDPs/managers. By default, it is the zero-length 705 string." 707 ::= { frwkPibIncarnationEntry 3 } 709 frwkPibIncarnationLongevity OBJECT-TYPE 710 SYNTAX Unsigned32 { 711 expireNever(1), 712 expireImmediate(2), 713 expireOnTimeout(3) 714 } 715 STATUS current 716 DESCRIPTION 717 "This attribute controls what the PEP does with the 718 downloaded policy on a Client Close message or a loss of 719 connection to the PDP. 721 If set to expireNever, the PEP continues to operate with the 722 installed policy indefinitely. If set to expireImmediate, 723 the PEP immediately expires the policy obtained from the PDP 724 and installs policy from local configuration. If set to 725 expireOnTimeout, the PEP continues to operate with the 726 policy installed by the PDP for a period of time specified 727 by frwkPibIncarnationTtl. After this time (and it has not 728 reconnected to the original or new PDP) the PEP expires this 729 policy and reverts to local configuration. 731 For all cases, it is the responsibility of the PDP to check 732 the incarnation and download new policy, if necessary, on a 733 reconnect. On receiving a Remove-State [COPS-PR] for the 734 active context, this attribute value MUST be ignored and the 735 PEP should expire the policy in that active context 736 immediately. 737 Policy enforcement timing only applies to policies that have 738 been installed dynamically (e.g., by a PDP via COPS)." 740 ::= { frwkPibIncarnationEntry 4 } 742 frwkPibIncarnationTtl OBJECT-TYPE 743 SYNTAX Unsigned32 744 UNITS "seconds" 745 STATUS current 746 DESCRIPTION 747 "The number of seconds after a Client Close or TCP timeout 748 for which the PEP continues to enforce the policy in the 749 PIB. After this interval, the PIB is considered expired and 750 the device no longer enforces the policy installed in the 751 PIB. 753 This attribute is only meaningful if 754 frwkPibIncarnationLongevity is set to expireOnTimeout." 756 ::= { frwkPibIncarnationEntry 5 } 758 frwkPibIncarnationActive OBJECT-TYPE 759 SYNTAX TruthValue 760 STATUS current 761 DESCRIPTION 762 "If this attribute is set to TRUE, then the PIB instance 763 to which this PRI belongs becomes the active PIB instance. 764 The previous active instance MUST become inactive and the 765 frwkPibIncarnationActive attribute in that PIB instance 766 MUST be set to false." 768 ::= { frwkPibIncarnationEntry 6 } 770 -- 771 -- Device Identification Table 772 -- 774 -- This table supports the ability to export general 775 -- purpose device information to facilitate efficient 776 -- communication between the device and a PDP 778 frwkDeviceIdTable OBJECT-TYPE 779 SYNTAX SEQUENCE OF FrwkDeviceIdEntry 780 PIB-ACCESS notify 781 STATUS current 782 DESCRIPTION 783 "This class contains a single provisioning instance that 784 contains device-specific information that is used to 785 facilitate efficient policy installation by a PDP. The 786 instance of this class is reported to the PDP in a COPS 787 request message so that the PDP can take into account 788 certain device characteristics during policy installation." 790 ::= { frwkBasePibClasses 3 } 792 frwkDeviceIdEntry OBJECT-TYPE 793 SYNTAX FrwkDeviceIdEntry 794 STATUS current 795 DESCRIPTION 796 "An instance of the frwkDeviceId class. Only one instance of 797 this provisioning class is ever instantiated." 799 PIB-INDEX { frwkDeviceIdPrid } 800 UNIQUENESS { frwkDeviceIdDescr } 802 ::= { frwkDeviceIdTable 1 } 804 FrwkDeviceIdEntry ::= SEQUENCE { 805 frwkDeviceIdPrid InstanceId, 806 frwkDeviceIdDescr SnmpAdminString, 807 frwkDeviceIdMaxMsg Unsigned32, 808 frwkDeviceIdMaxContexts Unsigned32 809 } 811 frwkDeviceIdPrid OBJECT-TYPE 812 SYNTAX InstanceId 813 STATUS current 814 DESCRIPTION 815 "An index to uniquely identify an instance of this 816 provisioning class." 818 ::= { frwkDeviceIdEntry 1 } 820 frwkDeviceIdDescr OBJECT-TYPE 821 SYNTAX SnmpAdminString 822 STATUS current 823 DESCRIPTION 824 "A textual description of the PEP. This value should include 825 the name and version identification of the PEP's hardware 826 and software." 828 ::= { frwkDeviceIdEntry 2 } 830 frwkDeviceIdMaxMsg OBJECT-TYPE 831 SYNTAX Unsigned32 832 UNITS "octets" 833 STATUS current 834 DESCRIPTION 835 "The maximum message size, in octets, that the device 836 is capable of processing. Received messages with a 837 size in excess of this value must cause the PEP to return an 838 error to the PDP containing the global error code 839 'maxMsgSizeExceeded'. This is an additional error-avoidance 840 mechanism to allow the administrator to have the ability to 841 control the message size of messages sent to the device. The 842 device should send NULL for this attributes if it not 843 defined." 845 ::= { frwkDeviceIdEntry 3 } 847 frwkDeviceIdMaxContexts OBJECT-TYPE 848 SYNTAX Unsigned32 849 UNITS "contexts" 850 STATUS current 851 DESCRIPTION 852 "The maximum number of unique contexts supported by 853 the device. This is an additional error-avoidance mechanism 854 to allow the administrators to have the ability to control 855 the number of contexts installed on the device. The device 856 should send NULL for this attribute if it is not 857 specified." 859 ::= { frwkDeviceIdEntry 4 } 861 -- 862 -- Component Limitations Table 863 -- 865 -- This table supports the ability to export information 866 -- detailing provisioning class/attribute implementation limitations 867 -- to the policy management system. 869 frwkCompLimitsTable OBJECT-TYPE 870 SYNTAX SEQUENCE OF FrwkCompLimitsEntry 871 PIB-ACCESS notify 872 STATUS current 873 DESCRIPTION 874 "Each instance of this class identifies a provisioning class 875 or attribute and a limitation related to the implementation 876 of the class/attribute in the device. Additional information 877 providing guidance related to the limitation may also be 878 present. These PRIs are sent to the PDP to indicate which 879 PRCs or PRC attributes the device supports in a restricted 880 manner." 882 ::= { frwkBasePibClasses 4 } 884 frwkCompLimitsEntry OBJECT-TYPE 885 SYNTAX FrwkCompLimitsEntry 886 STATUS current 887 DESCRIPTION 888 "An instance of the frwkCompLimits class that identifies 889 a PRC or PRC attribute and a limitation related to the PRC 890 or PRC attribute implementation supported by the device. 891 [COPS-PR] lists the error codes that MUST be returned (if 892 applicable)for policy installation that don't abide by the 893 restrictions indicated by the limitations exported. [SPPI] 894 defines an INSTALL-ERRORS clause that allows PIB designers 895 to define PRC specific error codes that can be returned for 896 policy installation. This allows efficient debugging of PIB 897 implementations." 899 PIB-INDEX { frwkCompLimitsPrid } 900 UNIQUENESS { frwkCompLimitsComponent, 901 frwkCompLimitsAttrPos, 902 frwkCompLimitsNegation, 903 frwkCompLimitsType, 904 frwkCompLimitsSubType, 905 frwkCompLimitsGuidance } 907 ::= { frwkCompLimitsTable 1 } 909 FrwkCompLimitsEntry ::= SEQUENCE { 910 frwkCompLimitsPrid InstanceId, 911 frwkCompLimitsComponent PrcIdentifier, 912 frwkCompLimitsAttrPos Unsigned32, 913 frwkCompLimitsNegation TruthValue, 914 frwkCompLimitsType Unsigned32, 915 frwkCompLimitsSubType Unsigned32, 916 frwkCompLimitsGuidance OCTET STRING 917 } 919 frwkCompLimitsPrid OBJECT-TYPE 920 SYNTAX InstanceId 921 STATUS current 922 DESCRIPTION 923 "An arbitrary integer index that uniquely identifies an 924 instance of the frwkCompLimits class." 926 ::= { frwkCompLimitsEntry 1 } 928 frwkCompLimitsComponent OBJECT-TYPE 929 SYNTAX PrcIdentifier 930 STATUS current 931 DESCRIPTION 932 "The value is the OID of a PRC (the table entry) which is 933 supported in some limited fashion or contains an attribute 934 that is supported in some limited fashion with regard to 935 it's definition in the associated PIB module. The same OID 936 may appear in the table several times, once for each 937 implementation limitation acknowledged by the device." 939 ::= { frwkCompLimitsEntry 2 } 941 frwkCompLimitsAttrPos OBJECT-TYPE 942 SYNTAX Unsigned32 943 STATUS current 944 DESCRIPTION 945 "The relative position of the attribute within the PRC 946 specified by the frwkCompLimitsComponent. A value of 1 would 947 represent the first columnar object in the PRC and a value 948 of N would represent the Nth columnar object in the PRC. A 949 NULL value indicates that the limit applies to the PRC 950 itself and not to a specific attribute." 952 ::= { frwkCompLimitsEntry 3 } 954 frwkCompLimitsNegation OBJECT-TYPE 955 SYNTAX TruthValue 956 STATUS current 957 DESCRIPTION 958 "A boolean value ,if TRUE, negates the component limit 959 exported." 961 ::= { frwkCompLimitsEntry 4 } 963 frwkCompLimitsType OBJECT-TYPE 964 SYNTAX Unsigned32 { 965 priSpaceLimited(1), 966 attrValueSupLimited(2), 967 attrEnumSupLimited(3), 968 attrLengthLimited(4), 969 prcLimitedNotify(5) 970 } 971 STATUS current 972 DESCRIPTION 973 "A value describing an implementation limitation for the 974 device related to the PRC or PRC attribute identified by 975 the frwkCompLimitsComponent and the frwkCompLimitsAttrPos 976 attributes in this class instance. 978 Values for this object are one of the following: 980 priSpaceLimited(1) - No more instances than that specified 981 by the guidance value may be installed in the given class. 982 The component identified MUST be a valid PRC. The SubType 983 used MUST be valueOnly(9). 985 attrValueSupLimited(2) - Limited values are acceptable for 986 the identified component. The component identified MUST be a 987 valid PRC attribute. The guidance OCTET STRING will be 988 decoded according to the attribute type. 990 attrEnumSupLimited(3) - Limited enumeration values are legal 991 for the identified component. The attribute identified MUST 992 be a valid enum type. 994 attrLengthLimited(4) - The length of the specified 995 value for the identified component is limited. The component 996 identified MUST be a valid PRC attribute of base-type OCTET 997 STRING. 999 prcLimitedNotify (5) - The component is currently limited 1000 for use by request or report messages prohibiting decision 1001 installation. The component identified must be a valid PRC." 1003 ::= { frwkCompLimitsEntry 5 } 1005 frwkCompLimitsSubType OBJECT-TYPE 1006 SYNTAX Unsigned32 { 1007 none(1), 1008 lengthMin(2), 1009 lengthMax(3), 1010 rangeMin(4), 1011 rangeMax(5), 1012 enumMin(6), 1013 enumMax(7), 1014 enumOnly(8), 1015 valueOnly(9) 1016 } 1017 STATUS current 1018 DESCRIPTION 1019 "This object indicates the type of guidance related 1020 to the noted limitation (as indicated by the 1021 frwkCompLimitsType attribute) that is provided 1022 in the frwkCompLimitsGuidance attribute. 1024 A value of 'none(1)' means that no additional 1025 guidance is provided for the noted limitation type. 1027 A value of 'lengthMin(2)' means that the guidance 1028 attribute provides data related to the minimum 1029 acceptable length for the value of the identified 1030 component. A corresponding class instance 1031 specifying the 'lengthMax(3)' value is required 1032 in conjunction with this sub-type. 1034 A value of 'lengthMax(3)' means that the guidance 1035 attribute provides data related to the maximum 1036 acceptable length for the value of the identified 1037 component. A corresponding class instance 1038 specifying the 'lengthMin(2)' value is required 1039 in conjunction with this sub-type. 1041 A value of 'rangeMin(4)' means that the guidance 1042 attribute provides data related to the lower bound 1043 of the range for the value of the identified 1044 component. A corresponding class instance 1045 specifying the 'rangeMax(5)' value is required 1046 in conjunction with this sub-type. 1048 A value of 'rangeMax(5)' means that the guidance 1049 attribute provides data related to the upper bound 1050 of the range for the value of the identified 1051 component. A corresponding class instance 1052 specifying the 'rangeMin(4)' value is required 1053 in conjunction with this sub-type. 1055 A value of 'enumMin(6)' means that the guidance 1056 attribute provides data related to the lowest 1057 enumeration acceptable for the value of the 1058 identified component. A corresponding 1059 class instance specifying the 'enumMax(7)' 1060 value is required in conjunction with this sub-type. 1062 A value of 'enumMax(7)' means that the guidance 1063 attribute provides data related to the largest 1064 enumeration acceptable for the value of the 1065 identified component. A corresponding 1066 class instance specifying the 'enumMin(6)' 1067 value is required in conjunction with this sub-type. 1069 A value of 'enumOnly(8)' means that the guidance 1070 attribute provides data related to a single 1071 enumeration acceptable for the value of the 1072 identified component. 1074 A value of 'valueOnly(9)' means that the guidance 1075 attribute provides data related to a single 1076 value that is acceptable for the identified 1077 component. 1079 For example, an implementation of the frwkIpFilter class may 1080 be limited in several ways, such as address mask, protocol 1081 and Layer 4 port options. These limitations could be 1082 exported using this table with the following instances: 1084 Component Type Sub Guidance 1085 Type 1086 ------------------------------------------------------------ 1087 frwkIpFilterDstAddrMask attrValueSupLimited valueOnly 24 1088 frwkIpFilterSrcAddrMask attrValueSupLimited valueOnly 24 1089 frwkIpFilterProtocol attrValueSupLimited rangeMin 10 1090 frwkIpFilterProtocol attrValueSupLimited rangeMax 20 1092 The above entries describe a number of limitations that 1093 may be in effect for the frwkIpFilter class on a given 1094 device. The limitations include restrictions on acceptable 1095 values for certain attributes. 1097 Also, an implementation of a PRC may be limited in the ways 1098 it can be accessed. For instance, for a fictitious PRC 1099 dscpMapEntry, which has a PIB-ACCESS of 'install-notify': 1101 Component Type SubType Guidance 1102 ------------------------------------------------------------ 1103 dscpMapEntry prcLimitedNotify none zero-length string." 1105 ::= { frwkCompLimitsEntry 6 } 1107 frwkCompLimitsGuidance OBJECT-TYPE 1108 SYNTAX OCTET STRING 1109 STATUS current 1110 DESCRIPTION 1111 "A value used to convey additional information related 1112 to the implementation limitation. Note that a guidance 1113 value will not necessarily be provided for all exported 1114 limitations. If a guidance value is not provided, the 1115 value must be a zero-length string. 1117 The format of the guidance value, if one is present as 1118 indicated by the frwkCompLimitsSubType attribute, 1119 is described by the following table. Note that the 1120 type of guidance value is dictated by the type of the 1121 component whose limitation is being exported, interpreted 1122 in the context of the frwkCompLimitsType and 1123 frwkCompLimitsSubType values. 1125 Note that numbers are encoded in network byte order. 1127 Base Type Value 1128 --------- ----- 1129 Unsigned32/Integer32 32-bit value. 1130 Unsigned64/Integer64 64-bit Value. 1131 OCTET STRING octets of data. 1132 OID 32-bit OID components." 1134 ::= { frwkCompLimitsEntry 7 } 1136 -- 1137 -- The device interface capabilities and role combo classes group 1138 -- 1140 frwkDeviceCapClasses 1141 OBJECT IDENTIFIER ::= { frameworkPib 2 } 1143 -- 1144 -- Interface Capability Set Table 1145 -- 1146 frwkIfCapSetTable OBJECT-TYPE 1147 SYNTAX SEQUENCE OF FrwkIfCapSetEntry 1148 PIB-ACCESS notify 1149 STATUS current 1150 DESCRIPTION 1151 "This class describes the interfaces that exist on the 1152 device. Associated with each interface is a set of 1153 capabilities. The capability set is given a unique name that 1154 identifies the interface type. These capabilities are used 1155 by the PDP to determine policy information to be associated 1156 with interfaces of this type." 1158 ::= { frwkDeviceCapClasses 1 } 1160 frwkIfCapSetEntry OBJECT-TYPE 1161 SYNTAX FrwkIfCapSetEntry 1162 STATUS current 1163 DESCRIPTION 1164 "An instance of this class describes the characteristics 1165 of a type of an interface." 1167 PIB-INDEX { frwkIfCapSetPrid } 1168 UNIQUENESS { frwkIfCapSetName, 1169 frwkIfCapSetCapability } 1171 ::= { frwkIfCapSetTable 1 } 1173 FrwkIfCapSetEntry ::= SEQUENCE { 1174 frwkIfCapSetPrid InstanceId, 1175 frwkIfCapSetName SnmpAdminString, 1176 frwkIfCapSetCapability Prid 1177 } 1179 frwkIfCapSetPrid OBJECT-TYPE 1180 SYNTAX InstanceId 1181 STATUS current 1182 DESCRIPTION 1183 "An arbitrary integer index that uniquely identifies a 1184 instance of the class." 1186 ::= { frwkIfCapSetEntry 1 } 1188 frwkIfCapSetName OBJECT-TYPE 1189 SYNTAX SnmpAdminString 1190 STATUS current 1191 DESCRIPTION 1192 "The name for the capability set. The capability set name 1193 is the unique identifier of an interface type." 1195 ::= { frwkIfCapSetEntry 2 } 1197 frwkIfCapSetCapability OBJECT-TYPE 1198 SYNTAX Prid 1199 STATUS current 1200 DESCRIPTION 1201 "The complete PRC OID and instance identifier specifying the 1202 capability PRC instance for the interface." 1204 ::= { frwkIfCapSetEntry 3 } 1206 -- 1207 -- Interface Capabilities Set Name and Role Combination Table 1208 -- 1210 frwkIfCapSetRoleComboTable OBJECT-TYPE 1211 SYNTAX SEQUENCE OF FrwkIfCapSetRoleComboEntry 1212 PIB-ACCESS notify 1213 STATUS current 1214 DESCRIPTION 1215 "Policy for an interface depends not only on the 1216 capability set of an interface but also on its roles. This 1217 table specifies all the tuples currently on the device." 1220 ::= { frwkDeviceCapClasses 2 } 1222 frwkIfCapSetRoleComboEntry OBJECT-TYPE 1223 SYNTAX FrwkIfCapSetRoleComboEntry 1224 STATUS current 1225 DESCRIPTION 1226 "An instance of this class describes a combination of an 1227 interface capability set name and a role combination." 1229 PIB-INDEX { frwkIfCapSetRoleComboPrid } 1230 UNIQUENESS { frwkIfCapSetRoleComboName, 1231 frwkIfCapSetRoleComboRoles } 1233 ::= { frwkIfCapSetRoleComboTable 1 } 1235 FrwkIfCapSetRoleComboEntry ::= SEQUENCE { 1236 frwkIfCapSetRoleComboPrid InstanceId, 1237 frwkIfCapSetRoleComboName SnmpAdminString, 1238 frwkIfCapSetRoleComboRoles RoleCombination 1239 } 1240 frwkIfCapSetRoleComboPrid OBJECT-TYPE 1241 SYNTAX InstanceId 1242 STATUS current 1243 DESCRIPTION 1244 "An arbitrary integer index that uniquely identifies a 1245 instance of the class." 1247 ::= { frwkIfCapSetRoleComboEntry 1 } 1249 frwkIfCapSetRoleComboName OBJECT-TYPE 1250 SYNTAX SnmpAdminString 1251 STATUS current 1252 DESCRIPTION 1253 "The name of the interface capability set. This name must 1254 exist in frwkIfCapSetTable." 1256 ::= { frwkIfCapSetRoleComboEntry 2 } 1258 frwkIfCapSetRoleComboRoles OBJECT-TYPE 1259 SYNTAX RoleCombination 1260 STATUS current 1261 DESCRIPTION 1262 "A role combination. The PEP requires policy for interfaces 1263 with this role combination and of capability set name 1264 specified by frwkIfCapSetRoleComboName." 1266 ::= { frwkIfCapSetRoleComboEntry 3 } 1268 -- 1269 -- The Classification classes group 1270 -- 1272 frwkClassifierClasses 1273 OBJECT IDENTIFIER ::= { frameworkPib 3 } 1274 -- 1275 -- The Base Filter Table 1276 -- 1278 frwkBaseFilterTable OBJECT-TYPE 1279 SYNTAX SEQUENCE OF FrwkBaseFilterEntry 1280 PIB-ACCESS install 1281 STATUS current 1282 DESCRIPTION 1283 "The Base Filter class. A packet has to match all 1284 fields in an Filter. Wildcards may be specified for those 1285 fields that are not relevant." 1287 ::= { frwkClassifierClasses 1 } 1288 frwkBaseFilterEntry OBJECT-TYPE 1289 SYNTAX FrwkBaseFilterEntry 1290 STATUS current 1291 DESCRIPTION 1292 "An instance of the frwkBaseFilter class." 1294 PIB-INDEX { frwkBaseFilterPrid } 1296 ::= { frwkBaseFilterTable 1 } 1298 FrwkBaseFilterEntry ::= SEQUENCE { 1299 frwkBaseFilterPrid InstanceId, 1300 frwkBaseFilterNegation TruthValue 1301 } 1303 frwkBaseFilterPrid OBJECT-TYPE 1304 SYNTAX InstanceId 1305 STATUS current 1306 DESCRIPTION 1307 "An integer index to uniquely identify this Filter among all 1308 the Filters." 1310 ::= { frwkBaseFilterEntry 1 } 1312 frwkBaseFilterNegation OBJECT-TYPE 1313 SYNTAX TruthValue 1314 STATUS current 1315 DESCRIPTION 1316 "This attribute behaves like a logical NOT for the filter. 1317 If the packet matches this filter and the value of this 1318 attribute is true, the action associated with this filter 1319 is not applied to the packet. If the value of this 1320 attribute is false, then the action is applied to the 1321 packet." 1323 ::= { frwkBaseFilterEntry 2 } 1325 -- 1326 -- The IP Filter Table 1327 -- 1329 frwkIpFilterTable OBJECT-TYPE 1330 SYNTAX SEQUENCE OF FrwkIpFilterEntry 1331 PIB-ACCESS install 1332 STATUS current 1333 DESCRIPTION 1334 "Filter definitions. A packet has to match all fields in a 1335 filter. Wildcards may be specified for those fields that 1336 are not relevant." 1338 INSTALL-ERRORS { 1339 invalidDstL4PortData(1), 1340 invalidSrcL4PortData(2) 1341 } 1342 ::= { frwkClassifierClasses 2 } 1344 frwkIpFilterEntry OBJECT-TYPE 1345 SYNTAX FrwkIpFilterEntry 1346 STATUS current 1347 DESCRIPTION 1348 "An instance of the frwkIpFilter class." 1350 EXTENDS { frwkBaseFilterEntry } 1351 UNIQUENESS { frwkBaseFilterNegation, 1352 FrwkIpFilterDstAddrType, 1353 frwkIpFilterDstAddr, 1354 frwkIpFilterDstAddrMask, 1355 frwkIpFilterSrcAddrType, 1356 frwkIpFilterSrcAddr, 1357 frwkIpFilterSrcAddrMask, 1358 frwkIpFilterDscp, 1359 frwkIpFilterProtocol, 1360 frwkIpFilterDstL4PortMin, 1361 frwkIpFilterDstL4PortMax, 1362 frwkIpFilterSrcL4PortMin, 1363 frwkIpFilterSrcL4PortMax } 1365 ::= { frwkIpFilterTable 1 } 1367 FrwkIpFilterEntry ::= SEQUENCE { 1368 frwkIpFilterDstAddrType InetAddressType, 1369 frwkIpFilterDstAddr InetAddress, 1370 frwkIpFilterDstAddrMask Unsigned32, 1371 frwkIpFilterSrcAddrType InetAddressType, 1372 frwkIpFilterSrcAddr InetAddress, 1373 frwkIpFilterSrcAddrMask Unsigned32, 1374 frwkIpFilterDscp Integer32, 1375 frwkIpFilterProtocol Integer32, 1376 frwkIpFilterDstL4PortMin Unsigned32, 1377 frwkIpFilterDstL4PortMax Unsigned32, 1378 frwkIpFilterSrcL4PortMin Unsigned32, 1379 frwkIpFilterSrcL4PortMax Unsigned32 1380 } 1382 frwkIpFilterDstAddrType OBJECT-TYPE 1384 SYNTAX InetAddressType 1385 STATUS current 1386 DESCRIPTION 1387 "The address type enumeration value [INETADDR] to specify 1388 the type of the packet's destination IP address." 1390 ::= { frwkIpFilterEntry 1 } 1392 frwkIpFilterDstAddr OBJECT-TYPE 1394 SYNTAX InetAddress 1395 STATUS current 1396 DESCRIPTION 1397 "The IP address [INETADDR] to match against the packet's 1398 destination IP address." 1400 ::= { frwkIpFilterEntry 2 } 1402 frwkIpFilterDstAddrMask OBJECT-TYPE 1403 SYNTAX Unsigned32 (0..128) 1404 STATUS current 1405 DESCRIPTION 1406 "The length of a mask for the matching of the destination 1407 IP address. Masks are constructed by setting bits in 1408 sequence from the most-significant bit downwards for 1409 frwkIpFilterDstAddrMask bits length. All other bits in the 1410 mask, up to the number needed to fill the length of the 1411 address frwkIpFilterDstAddr are cleared to zero. A zero bit 1412 in the mask then means that the corresponding bit in the 1413 address always matches." 1415 ::= { frwkIpFilterEntry 3 } 1417 frwkIpFilterSrcAddrType OBJECT-TYPE 1419 SYNTAX InetAddressType 1420 STATUS current 1421 DESCRIPTION 1422 "The address type enumeration value to specify the type of 1423 the packet's source IP address." 1425 ::= { frwkIpFilterEntry 4 } 1427 frwkIpFilterSrcAddr OBJECT-TYPE 1428 SYNTAX InetAddress 1429 STATUS current 1430 DESCRIPTION 1431 "The IP address to match against the packet's source IP 1432 address." 1434 ::= { frwkIpFilterEntry 5 } 1436 frwkIpFilterSrcAddrMask OBJECT-TYPE 1437 SYNTAX Unsigned32 (0..128) 1438 STATUS current 1439 DESCRIPTION 1440 "The length of a mask for the matching of the source IP 1442 address. Masks are constructed by setting bits in sequence 1443 from the most-significant bit downwards for 1444 frwkIpFilterSrcAddrMask bits length. All other bits in the 1445 mask, up to the number needed to fill the length of the 1446 address frwkIpFilterSrcAddr are cleared to zero. A zero bit 1447 in the mask then means that the corresponding bit in the 1448 address always matches." 1450 ::= { frwkIpFilterEntry 6 } 1452 frwkIpFilterDscp OBJECT-TYPE 1453 SYNTAX Integer32 (-1 | 0..63) 1454 STATUS current 1455 DESCRIPTION 1456 "The value that the DSCP in the packet can have and 1457 match this filter. A value of -1 indicates that a specific 1458 DSCP value has not been defined and thus all DSCP values 1459 are considered a match." 1461 ::= { frwkIpFilterEntry 7 } 1463 frwkIpFilterProtocol OBJECT-TYPE 1464 SYNTAX Integer32 (-1 | 0..255) 1465 STATUS current 1466 DESCRIPTION 1467 "The IP protocol to match against the packet's protocol. 1468 A value of -1 means match all." 1470 ::= { frwkIpFilterEntry 8 } 1472 frwkIpFilterDstL4PortMin OBJECT-TYPE 1473 SYNTAX Unsigned32 (0..65535) 1474 STATUS current 1475 DESCRIPTION 1476 "The minimum value that the packet's layer 4 destination 1477 port number can have and match this filter. This value must 1478 be equal to or lesser that the value specified for this 1479 filter in frwkIpFilterDstL4PortMax." 1481 ::= { frwkIpFilterEntry 9 } 1483 frwkIpFilterDstL4PortMax OBJECT-TYPE 1484 SYNTAX Unsigned32 (0..65535) 1485 STATUS current 1486 DESCRIPTION 1487 "The maximum value that the packet's layer 4 destination 1488 port number can have and match this filter. This value must 1489 be equal to or greater that the value specified for this 1490 filter in frwkIpFilterDstL4PortMin." 1492 ::= { frwkIpFilterEntry 10 } 1494 frwkIpFilterSrcL4PortMin OBJECT-TYPE 1495 SYNTAX Unsigned32 (0..65535) 1496 STATUS current 1497 DESCRIPTION 1498 "The minimum value that the packet's layer 4 source port 1499 number can have and match this filter. This value must 1500 be equal to or lesser that the value specified for this 1501 filter in frwkIpFilterSrcL4PortMax." 1503 ::= { frwkIpFilterEntry 11 } 1505 frwkIpFilterSrcL4PortMax OBJECT-TYPE 1506 SYNTAX Unsigned32 (0..65535) 1507 STATUS current 1508 DESCRIPTION 1509 "The maximum value that the packet's layer 4 source port 1510 number can have and match this filter. This value must be 1511 equal to or greater that the value specified for this filter 1512 in frwkIpFilterSrcL4PortMin." 1514 ::= { frwkIpFilterEntry 12 } 1516 -- 1517 -- The IEEE 802 Filter Table 1518 -- 1520 -- The IEEE 802 Filter Table supports the specification of IEEE 1521 -- 802-based [802] (e.g., 802.3) information that is used to perform 1522 -- traffic classification. 1523 -- 1525 frwk802FilterTable OBJECT-TYPE 1526 SYNTAX SEQUENCE OF Frwk802FilterEntry 1527 PIB-ACCESS install 1528 STATUS current 1529 DESCRIPTION 1530 "IEEE 802-based filter definitions. A class that contains 1531 attributes of IEEE 802 (e.g., 802.3) traffic that form 1532 filters that are used to perform traffic classification." 1534 ::= { frwkClassifierClasses 3 } 1536 frwk802FilterEntry OBJECT-TYPE 1537 SYNTAX Frwk802FilterEntry 1538 STATUS current 1539 DESCRIPTION 1540 "IEEE 802-based filter definitions. An entry specifies 1541 (potentially) several distinct matching components. Each 1542 component is tested against the data in a frame 1543 individually. An overall match occurs when all of the 1544 individual components match the data they are compared 1545 against in the frame being processed. A failure of any 1546 one test causes the overall match to fail. 1548 Wildcards may be specified for those fields that are not 1549 relevant." 1551 EXTENDS { frwkBaseFilterEntry } 1552 UNIQUENESS { frwkBaseFilterNegation, 1553 frwk802FilterDstAddr, 1554 frwk802FilterDstAddrMask, 1555 frwk802FilterSrcAddr, 1556 frwk802FilterSrcAddrMask, 1557 frwk802FilterVlanId, 1558 frwk802FilterVlanTagRequired, 1559 frwk802FilterEtherType, 1560 frwk802FilterUserPriority } 1562 ::= { frwk802FilterTable 1 } 1564 Frwk802FilterEntry ::= SEQUENCE { 1565 frwk802FilterDstAddr PhysAddress, 1566 frwk802FilterDstAddrMask PhysAddress, 1567 frwk802FilterSrcAddr PhysAddress, 1568 frwk802FilterSrcAddrMask PhysAddress, 1569 frwk802FilterVlanId Integer32, 1570 frwk802FilterVlanTagRequired Unsigned32, 1571 frwk802FilterEtherType Integer32, 1572 frwk802FilterUserPriority BITS 1573 } 1575 frwk802FilterDstAddr OBJECT-TYPE 1576 SYNTAX PhysAddress 1577 STATUS current 1579 DESCRIPTION 1580 "The 802 address against which the 802 DA of incoming 1581 traffic streams will be compared. Frames whose 802 DA 1582 matches the physical address specified by this object, 1583 taking into account address wildcarding as specified by the 1584 frwk802FilterDstAddrMask object, are potentially subject to 1585 the processing guidelines that are associated with this 1586 entry through the related action class." 1588 ::= { frwk802FilterEntry 1 } 1590 frwk802FilterDstAddrMask OBJECT-TYPE 1591 SYNTAX PhysAddress 1592 STATUS current 1593 DESCRIPTION 1594 "This object specifies the bits in a 802 destination address 1595 that should be considered when performing a 802 DA 1596 comparison against the address specified in the 1597 frwk802FilterDstAddr object. 1599 The value of this object represents a mask that is logically 1600 and'ed with the 802 DA in received frames to derive the 1601 value to be compared against the frwk802FilterDstAddr 1602 address. A zero bit in the mask thus means that the 1603 corresponding bit in the address always matches. The 1604 frwk802FilterDstAddr value must also be masked using this 1605 value prior to any comparisons. 1607 The length of this object in octets must equal the length in 1608 octets of the frwk802FilterDstAddr. Note that a mask with no 1609 bits set (i.e., all zeroes) effectively wildcards the 1610 frwk802FilterDstAddr object." 1612 ::= { frwk802FilterEntry 2 } 1614 frwk802FilterSrcAddr OBJECT-TYPE 1615 SYNTAX PhysAddress 1616 STATUS current 1617 DESCRIPTION 1618 "The 802 MAC address against which the 802 MAC SA of 1619 incoming traffic streams will be compared. Frames whose 802 1620 MAC SA matches the physical address specified by this 1621 object, taking into account address wildcarding as specified 1622 by the frwk802FilterSrcAddrMask object, are potentially 1623 subject to the processing guidelines that are associated 1624 with this entry through the related action class." 1626 ::= { frwk802FilterEntry 3 } 1628 frwk802FilterSrcAddrMask OBJECT-TYPE 1629 SYNTAX PhysAddress 1630 STATUS current 1631 DESCRIPTION 1632 "This object specifies the bits in a 802 MAC source address 1633 that should be considered when performing a 802 MAC SA 1634 comparison against the address specified in the 1635 frwk802FilterSrcAddr object. 1637 The value of this object represents a mask that is logically 1638 and'ed with the 802 MAC SA in received frames to derive the 1639 value to be compared against the frwk802FilterSrcAddr 1640 address. A zero bit in the mask thus means that the 1641 corresponding bit in the address always matches. The 1642 frwk802FilterSrcAddr value must also be masked using this 1643 value prior to any comparisons. 1645 The length of this object in octets must equal the length in 1646 octets of the frwk802FilterSrcAddr. Note that a mask with no 1647 bits set (i.e., all zeroes) effectively wildcards the 1648 frwk802FilterSrcAddr object." 1650 ::= { frwk802FilterEntry 4 } 1652 frwk802FilterVlanId OBJECT-TYPE 1653 SYNTAX Integer32 (-1 | 1..4094) 1654 STATUS current 1655 DESCRIPTION 1656 "The VLAN ID (VID) that uniquely identifies a VLAN 1657 within the device. This VLAN may be known or unknown 1658 (i.e., traffic associated with this VID has not yet 1659 been seen by the device) at the time this entry 1660 is instantiated. 1662 Setting the frwk802FilterVlanId object to -1 indicates that 1663 VLAN data should not be considered during traffic 1664 classification." 1666 ::= { frwk802FilterEntry 5 } 1668 frwk802FilterVlanTagRequired OBJECT-TYPE 1669 SYNTAX Unsigned32 { 1670 taggedOnly(1), 1671 priorityTaggedPlus(2), 1672 untaggedOnly(3), 1673 ignoreTag(4) 1674 } 1675 STATUS current 1676 DESCRIPTION 1677 "This object indicates whether the presence of an 1678 IEEE 802.1Q VLAN tag in data link layer frames must 1679 be considered when determining if a given frame 1680 matches this 802 filter entry. 1682 A value of 'taggedOnly(1)' means that only frames 1683 containing a VLAN tag with a non-Null VID (i.e., a 1684 VID in the range 1..4094) will be considered a match. 1686 A value of 'priorityTaggedPlus(2)' means that only 1687 frames containing a VLAN tag, regardless of the value 1688 of the VID, will be considered a match. 1690 A value of 'untaggedOnly(3)' indicates that only 1691 untagged frames will match this filter component. 1693 The presence of a VLAN tag is not taken into 1694 consideration in terms of a match if the value is 1695 'ignoreTag(4)'." 1697 ::= { frwk802FilterEntry 6 } 1699 frwk802FilterEtherType OBJECT-TYPE 1700 SYNTAX Integer32 (-1 | 0..'ffff'h) 1701 STATUS current 1702 DESCRIPTION 1703 "This object specifies the value that will be compared 1704 against the value contained in the EtherType field of an 1705 IEEE 802 frame. Example settings would include 'IP' 1706 (0x0800), 'ARP' (0x0806) and 'IPX' (0x8137). 1708 Setting the frwk802FilterEtherTypeMin object to -1 indicates 1709 that EtherType data should not be considered during traffic 1710 classification. 1712 Note that the position of the EtherType field depends on 1713 the underlying frame format. For Ethernet-II encapsulation, 1714 the EtherType field follows the 802 MAC source address. For 1715 802.2 LLC/SNAP encapsulation, the EtherType value follows 1716 the Organization Code field in the 802.2 SNAP header. The 1717 value that is tested with regard to this filter component 1718 therefore depends on the data link layer frame format being 1719 used. If this 802 filter component is active when there is 1720 no EtherType field in a frame (e.g., 802.2 LLC), a match is 1721 implied." 1723 ::= { frwk802FilterEntry 7 } 1725 frwk802FilterUserPriority OBJECT-TYPE 1726 SYNTAX BITS { 1727 matchPriority0(0), 1728 matchPriority1(1), 1729 matchPriority2(2), 1730 matchPriority3(3), 1731 matchPriority4(4), 1732 matchPriority5(5), 1733 matchPriority6(6), 1734 matchPriority7(7) 1735 } 1736 STATUS current 1737 DESCRIPTION 1738 "The set of values, representing the potential range 1739 of user priority values, against which the value contained 1740 in the user priority field of a tagged 802.1 frame is 1741 compared. A test for equality is performed when determining 1742 if a match exists between the data in a data link layer 1743 frame and the value of this 802 filter component. Multiple 1744 values may be set at one time such that potentially several 1745 different user priority values may match this 802 filter 1746 component. 1748 Setting all of the bits that are associated with this 1749 object causes all user priority values to match this 1750 attribute. This essentially makes any comparisons 1751 with regard to user priority values unnecessary. Untagged 1752 frames are treated as an implicit match." 1754 ::= { frwk802FilterEntry 8 } 1756 -- 1757 -- Conformance Section 1758 -- 1760 frwkBasePibConformance 1761 OBJECT IDENTIFIER ::= { frameworkPib 4 } 1763 frwkBasePibCompliances 1764 OBJECT IDENTIFIER ::= { frwkBasePibConformance 1 } 1766 frwkBasePibGroups 1767 OBJECT IDENTIFIER ::= { frwkBasePibConformance 2 } 1769 frwkBasePibCompliance MODULE-COMPLIANCE 1770 STATUS current 1771 DESCRIPTION 1772 "Describes the requirements for conformance to the 1773 Framework PIB." 1775 MODULE -- this module 1776 MANDATORY-GROUPS { frwkPrcSupportGroup, 1777 frwkPibIncarnationGroup, 1778 frwkDeviceIdGroup, 1779 frwkCompLimitsGroup, 1780 frwkIfCapSetGroup, 1781 frwkIfCapSetRoleComboGroup } 1783 OBJECT frwkPibIncarnationLongevity 1784 PIB-MIN-ACCESS notify 1785 DESCRIPTION "Install support is not required." 1787 OBJECT frwkPibIncarnationTtl 1788 PIB-MIN-ACCESS notify 1789 DESCRIPTION "Install support is not required." 1791 OBJECT frwkPibIncarnationActive 1792 PIB-MIN-ACCESS notify 1793 DESCRIPTION "Install support is not required." 1795 GROUP frwkBaseFilterGroup 1796 DESCRIPTION 1797 "The frwkBaseFilterGroup is mandatory if filtering 1798 based on traffic components is supported." 1800 GROUP frwkIpFilterGroup 1801 DESCRIPTION 1802 "The frwkIpFilterGroup is mandatory if filtering 1803 based on IP traffic components is supported." 1805 GROUP frwk802FilterGroup 1806 DESCRIPTION 1807 "The frwk802FilterGroup is mandatory if filtering 1808 based on 802 traffic criteria is supported." 1810 ::= { frwkBasePibCompliances 1 } 1812 frwkPrcSupportGroup OBJECT-GROUP 1813 OBJECTS { 1814 frwkPrcSupportSupportedPrc, 1815 frwkPrcSupportSupportedAttrs } 1816 STATUS current 1817 DESCRIPTION 1818 "Objects from the frwkPrcSupportTable." 1820 ::= { frwkBasePibGroups 1 } 1822 frwkPibIncarnationGroup OBJECT-GROUP 1823 OBJECTS { 1824 frwkPibIncarnationName, 1825 frwkPibIncarnationId, 1826 frwkPibIncarnationLongevity, 1827 frwkPibIncarnationTtl, 1828 frwkPibIncarnationActive } 1829 STATUS current 1830 DESCRIPTION 1831 "Objects from the frwkDevicePibIncarnationTable." 1833 ::= { frwkBasePibGroups 2 } 1835 frwkDeviceIdGroup OBJECT-GROUP 1836 OBJECTS { 1837 frwkDeviceIdDescr, 1838 frwkDeviceIdMaxMsg, 1839 frwkDeviceIdMaxContexts } 1840 STATUS current 1841 DESCRIPTION 1842 "Objects from the frwkDeviceIdTable." 1844 ::= { frwkBasePibGroups 3 } 1846 frwkCompLimitsGroup OBJECT-GROUP 1847 OBJECTS { 1848 frwkCompLimitsComponent, 1849 frwkCompLimitsAttrPos, 1850 frwkCompLimitsNegation, 1851 frwkCompLimitsType, 1852 frwkCompLimitsSubType, 1853 frwkCompLimitsGuidance } 1854 STATUS current 1855 DESCRIPTION 1856 "Objects from the frwkCompLimitsTable." 1858 ::= { frwkBasePibGroups 4 } 1860 frwkIfCapSetGroup OBJECT-GROUP 1861 OBJECTS { 1862 frwkIfCapSetName, 1863 frwkIfCapSetCapability } 1864 STATUS current 1865 DESCRIPTION 1866 "Objects from the frwkIfCapSetTable." 1868 ::= { frwkBasePibGroups 5 } 1870 frwkIfCapSetRoleComboGroup OBJECT-GROUP 1871 OBJECTS { 1872 frwkIfCapSetRoleComboName, 1873 frwkIfCapSetRoleComboRoles } 1874 STATUS current 1875 DESCRIPTION 1876 "Objects from the frwkIfCapSetRoleComboTable." 1878 ::= { frwkBasePibGroups 6 } 1880 frwkBaseFilterGroup OBJECT-GROUP 1881 OBJECTS { 1882 frwkBaseFilterNegation } 1883 STATUS current 1884 DESCRIPTION 1885 "Objects from the frwkBaseFilterTable." 1887 ::= { frwkBasePibGroups 7 } 1889 frwkIpFilterGroup OBJECT-GROUP 1890 OBJECTS { 1891 frwkIpFilterDstAddrType, 1892 frwkIpFilterDstAddr, 1893 frwkIpFilterDstAddrMask, 1894 frwkIpFilterSrcAddrType, 1895 frwkIpFilterSrcAddr, 1896 frwkIpFilterSrcAddrMask, 1897 frwkIpFilterDscp, 1898 frwkIpFilterProtocol, 1899 frwkIpFilterDstL4PortMin, 1900 frwkIpFilterDstL4PortMax, 1901 frwkIpFilterSrcL4PortMin, 1902 frwkIpFilterSrcL4PortMax } 1903 STATUS current 1904 DESCRIPTION 1905 "Objects from the frwkIpFilterTable." 1907 ::= { frwkBasePibGroups 8 } 1909 frwk802FilterGroup OBJECT-GROUP 1910 OBJECTS { 1911 frwk802FilterDstAddr, 1912 frwk802FilterDstAddrMask, 1913 frwk802FilterSrcAddr, 1914 frwk802FilterSrcAddrMask, 1915 frwk802FilterVlanId, 1916 frwk802FilterVlanTagRequired, 1917 frwk802FilterEtherType, 1918 frwk802FilterUserPriority } 1919 STATUS current 1920 DESCRIPTION 1921 "Objects from the frwk802FilterTable." 1923 ::= { frwkBasePibGroups 9 } 1925 END 1927 7. Security Considerations 1929 It is clear that this PIB is used for configuration using [COPS-PR], 1930 and anything that can be configured can be misconfigured, with 1931 potentially disastrous effect. At this writing, no security holes 1932 have been identified beyond those that the COPS base protocol 1933 security is itself intended to address. These relate primarily to 1934 controlled access to sensitive information and the ability to 1935 configure a device - or which might result from operator error, 1936 which is beyond the scope of any security architecture. 1938 There are a number of provisioning classes defined in this PIB that 1939 have a PIB-ACCESS clause of install (read-create). Such objects may 1940 be considered sensitive or vulnerable in some network environments. 1941 The support for "Install" decisions sent over [COPS-PR] in a non- 1942 secure environment without proper protection can have a negative 1943 effect on network operations. There are a number of provisioning 1944 classes in this PIB that may contain information that may be 1945 sensitive from a business perspective, in that they may represent a 1946 customer's service contract or the filters that the service provider 1947 chooses to apply to a customer's ingress or egress traffic. There 1948 are no PRCs that are sensitive in their own right, such as passwords 1949 or monetary amounts. It may be important to control even 1950 "Notify"(read-only) access to these PRCs and possibly to even 1951 encrypt the values of these PRIs when sending them over the network 1952 via COPS-PR. The use of IPSEC between the PDP and the PEP, as 1953 described in [COPS], provides the necessary protection against 1954 security threats. However, even if the network itself is secure, 1955 there is no control as to who on the secure network is allowed to 1956 "Install/Notify" (read/change/create/delete) the PRIs in this PIB. 1958 It is then a customer/user responsibility to ensure that the PEP/PDP 1959 giving access to an instance of this PIB, is properly configured to 1960 give access to the PRIs only to those principals (users) that have 1961 legitimate rights to indeed "Install" or "Notify" (change/create/ 1962 delete) them. 1964 8. Author Information and Acknowledgments 1966 Michael Fine 1967 Cisco Systems, Inc. 1968 170 West Tasman Drive 1969 San Jose, CA 95134-1706 USA 1970 Phone: +1 408 527 8218 1971 Email: mfine@cisco.com 1973 Keith McCloghrie 1974 Cisco Systems, Inc. 1975 170 West Tasman Drive 1976 San Jose, CA 95134-1706 USA 1977 Phone: +1 408 526 5260 1978 Email: kzm@cisco.com 1980 John Seligson 1981 Nortel Networks, Inc. 1982 4401 Great America Parkway 1983 Santa Clara, CA 95054 USA 1984 Phone: +1 408 495 2992 1985 Email: jseligso@nortelnetworks.com 1987 Kwok Ho Chan 1988 Nortel Networks, Inc. 1989 600 Technology Park Drive 1990 Billerica, MA 01821 USA 1991 Phone: +1 978 288 8175 1992 Email: khchan@nortelnetworks.com 1993 Scott Hahn 1994 Intel Corp. 1995 2111 NE 25th Avenue 1996 Hillsboro, OR 97124 USA 1997 Phone: +1 503 264 8231 1998 Email: scott.hahn@intel.com 2000 Ravi Sahita 2001 Intel Corp. 2002 2111 NE 25th Avenue 2003 Hillsboro, OR 97124 USA 2004 Phone: +1 503 712 1554 2005 Email: ravi.sahita@intel.com 2007 Andrew Smith 2008 Allegro Networks 2009 6399 San Ignacio Ave. 2010 San Jose 2011 CA 95119 2012 FAX: 415 345 1827 2013 Email: andrew@allegronetworks.com 2015 Francis Reichmeyer 2016 PFN, Inc. 2017 University Park at MIT 2018 26 Landsdowne Street 2019 Cambridge, MA 02139 2020 Phone: +1 617 494 9980 2021 Email: franr@pfn.com 2023 Special thanks to Carol Bell and David Durham for their many 2024 significant comments. 2026 9. References 2028 [COPS] 2029 Boyle, J., Cohen, R., Durham, D., Herzog, S., Rajan, R., and 2030 A. Sastry, "The COPS (Common Open Policy Service) Protocol" 2031 RFC 2748, January 2000. 2033 [COPS-PR] 2034 K. Chan, D. Durham, S. Gai, S. Herzog, K. McCloghrie, 2035 F. Reichmeyer, J. Seligson, A. Smith, R. Yavatkar, "COPS Usage 2036 for Policy Provisioning," draft-ietf-rap-pr-05.txt, 2037 October 30, 2000. 2039 [SPPI] 2040 K. McCloghrie, et.al., "Structure of Policy Provisioning 2041 Information," draft-ietf-rap-sppi-05.txt, February 2001. 2043 [RAP-FRAMEWORK] 2044 R. Yavatkar, D. Pendarakis, "A Framework for Policy-based 2045 Admission Control", RFC 2753, January 2000. 2047 [SNMP-SMI] 2048 K. McCloghrie, D. Perkins, J. Schoenwaelder, J. Case, M. Rose 2049 and S. Waldbusser, "Structure of Management Information 2050 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 2052 [INETADDR] 2053 M. Daniele, B. Haberman, S. Routhier and J. Schoenwaelder " 2054 Textual Conventions for Internet Network Addresses" RFC 2851, 2055 June 2000 2057 [802] 2058 IEEE Standards for Local and Metropolitan Area Networks: 2059 Overview and Architecture, ANSI/IEEE Std 802, 1990. 2061 [SNMPFRWK] 2062 Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture 2063 for Describing SNMP Management Frameworks", RFC 2571, 2064 May 1999 2066 [STD17] 2067 K. McCloghrie, M. Rose "Management Information Base for Network 2068 Management of TCP/IP-based internets: MIB-II" STD 17, RFC 1213, 2069 March 1991 2071 10. Full Copyright 2073 Copyright (C) The Internet Society (2000). All Rights Reserved. This 2074 document and translations of it may be copied and furnished to 2075 others, and derivative works that comment on or otherwise explain it 2076 or assist in its implementation may be prepared, copied, published 2077 and distributed, in whole or in part, without restriction of any 2078 kind, provided that the above copyright notice and this paragraph 2079 are included on all such copies and derivative works. However, this 2080 document itself may not be modified in any way, such as by removing 2081 the copyright notice or references to the Internet Society or other 2082 Internet organizations, except as needed for the purpose of 2083 developing Internet standards in which case the procedures for 2084 copyrights defined in the Internet Standards process must be 2085 followed, or as required to translate it into languages other than 2086 English. 2088 The limited permissions granted above are perpetual and will not be 2089 revoked by the Internet Society or its successors or assigns. 2091 This document and the information contained herein is provided on an 2092 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2093 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2094 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2095 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2096 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2098 Table of Contents 2100 Status of this Memo...............................................1 2101 1. Glossary.......................................................2 2102 2. Introduction...................................................2 2103 3. General PIB Concepts...........................................2 2104 3.1. Roles........................................................2 2105 3.1.1. An Example.................................................4 2106 3.2. Multiple PIB Instances.......................................5 2107 3.3. Reporting of Device Capabilities.............................6 2108 3.4. Reporting of Device Limitations..............................6 2109 4. The Framework Role PIB module..................................7 2110 5. Summary of the Framework PIB...................................8 2111 6. The Framework PIB Module......................................11 2112 7. Security Considerations.......................................39 2113 8. Author Information and Acknowledgments........................40 2114 9. References....................................................41 2115 10. Full Copyright...............................................42