Network Working Group M. Fine Internet Draft K. McCloghrie Expires September 2000 Cisco Systems J. Seligson K. Chan Nortel Networks S. Hahn Intel A. Smith Extreme Networks Francis Reichmeyer IPHighway March 10, 2000 Framework Policy Information Base draft-ietf-rap-frameworkpib-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' To view the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in an Internet-Drafts Shadow Directory, see http://www.ietf.org/shadow.html. [Page 1] Framework Policy Information Base March 2000 1. Glossary PRC Policy Rule Class. A type of policy data. PRI Policy Rule Instance. An instance of a PRC. PIB Policy Information Base. The database of policy information. PDP Policy Decision Point. See [RAP-FRAMEWORK]. PEP Policy Enforcement Point. See [RAP-FRAMEWORK]. PRID Policy Rule Instance Identifier. Uniquely identifies an instance of a a PRC. 2. Introduction [SPPI] describes a structure for specifying policy information that can then be transmitted to a network device for the purpose of configuring policy at that device. The model underlying this structure is one of well defined policy rule classes and instances of these classes residing in a virtual information store called the Policy Information Base (PIB). One way to provision policy is by means of the COPS protocol [COPS] with the extensions for provisioning [COPS-PR]. This protocol supports multiple clients, each of which may provision policy for a specific policy domain such as QoS, virtual private networks, or security. As described in [COPS-PR], each client supports a non-overlapping and independent PIB. However, some policy rule classes are common to all client types and replicated in each. This document presents the PIB classes that are common to all clients that provision policy using COPS for Provisioning. 3. General PIB Concepts 3.1. Roles The policy to apply to an interface may depend on many factors such as immutable characteristics of the interface (e.g., ethernet or frame relay), the status of the interface (e.g., half or full duplex), or user configuration (e.g., branch office or headquarters interface). Rather than specifying policies explicitly for each interface of all devices in the network, policies are specified in terms of interface functionality. To describe these functionalities of an interface we use the concept of "roles". A role is simply a string that is associated with an interface. A given interface may have any number of roles simultaneously. Policy rule classes have an attribute called a "role- [Page 2] Framework Policy Information Base March 2000 combination" which is an unordered set of roles. Instances of a given policy rule class are applied to an interface if and only if the set of roles in the role combination is identical to the set of the roles of the interface. Thus, roles provide a way to bind policy to interfaces without having to explicitly identify interfaces in a consistent manner across all network devices. (The SNMP experience with ifIndex has proved this to be a difficult task.) That is, roles provide a level of indirection to the application of a set of policies to specific interfaces. Furthermore, if the same policy is being applied to several interfaces, that policy need be pushed to the device only once, rather than once per interface, as long as the interfaces are configured with the same role combination. We point out that, in the event that the administrator needs to have unique policy for each interface, this can be achieved by configuring each interface with a unique role. The PEP reports all its role combinations to the PDP at connect time or whenever they change. The comparing of roles (or role combinations) is case sensitive. The concept and usage of roles in this document is consistent with that specified in [POLICY]. Roles are currently under discussion in the IETF's Policy WG; as and when that discussion reaches a conclusion, this PIB will be updated in accordance with that conclusion. 3.1.1. An Example The functioning of roles might be best understood by an example. Suppose I have a device with three interfaces, with roles as follows: IF1: "finance" IF2: "finance" IF3: "manager" Suppose, I also have a PDP with two policies: P1: Packets from finance department (role "finance") get PHB 5 P2: Packets from managers (role "manager") get PHB 6 To obtain policy, the PEP reports to the PDP that it has some interfaces with role combination "finance" and some with role combination [Page 3] Framework Policy Information Base March 2000 "manager". In response, the PDP downloads policy P1 associated with role combination "finance" and downloads a second policy P2 associated with role combination "manager". Now suppose the finance person attached to IF2 is promoted to manager and so the system administrator adds the role "manager" to IF2. The PEP now reports to the PDP that it has three role combinations: some interfaces with role combination "finance", some with role combination "manager" and some with role combination "finance+manager". In response, the PDP downloads an additional third policy associated with the new role combination "finance+manager". How the PDP determines the policy for this new role combination is entirely the responsibility of the PDP. It could do so algorithmically or by rule. For example, there might be a rule that specifies that manager policy takes preference over depertment policy. Or there might be a third policy installed in the PDP as follows: P3: Packets from finance managers (role "finance" and role "manager") get PHB 7 The point here is that the PDP is required to determine what policy applies to this new role combination and to download a third policy to the PEP for the role combination "finance+manager" even if that policy is the same as one already downloaded. The PEP is not required (or allowed) to construct policy for new role combinations from existing policy. 3.2. Multiple PIB Instances Similar to SNMP contexts, [COPS-PR] supports multiple, disjoint, independent instances of the PIB to represent multiple instances of configured policy. The intent is to allow for the pre-provisioning of policy which can then be made active by a single, short decision from the PDP. With the COPS-PR protocol, each of these instances is identified by a unique client handle. The creation and deletion of these PIB instances is controlled by the PDP as described in [COPS-PR]. The intent is to allow for the pre-provisioning of policy which can then be made active by a single, short decision from the PDP. Although many PIB instances may be configured on a device (the maximum [Page 4] Framework Policy Information Base March 2000 number of these instances being determined by the device itself) only one of them can be active at any given time, the active one being selected by the PDP. To facilitate this selection, the Framework PIB supports an attribute to make a PIB instance the active one and, similarly, to report the active PIB instance to the PDP at connect time. This attribute is in the Incarnation Table described below. Setting the attribute policyPibIncarnationActive to 'true' in one PIB instance automatically ensures that the attribute is 'false' in all other contexts. 3.3. Reporting of Device Capabilities Each network device providing policy-based services has its own inherent capabilities. These capabilities can be hardware specific, e.g., an ethernet interface supporting input classification, or can be statically configured, e.g., supported queuing disciplines. These capabilities are communicated to the PDP when initial policy is requested by the PEP. Knowing device capabilities, the PDP can send the policy rule instances (PRIs) relevant to the specific device, rather than sending the entire PIB. The PIB indicates which capabilities the PEP must report to the PDP by means of the POLICY-ACCESS clause as described in [SPPI]. 3.4. Reporting of Device Limitations To facilitate efficient policy installation, it is important to understand a device's limitations in relation to the advertised device capabilities. Limitations may be class-based, e.g., an "install" class is supported as a "notify" or only a limited number of class instances may be created, or attribute-based. Attribute limitations, such as supporting a restricted set of enumerations or requiring related attributes to have certain values, detail implementation limitations at a fine level of granularity. A PDP can avoid certain installation issues in a proactive fashion by taking into account a device's limitations prior to policy installation rather than in a reactive mode during installation. As with device capabilities, device limitations are communicated to the PDP when initial policy is requested. [Page 5] Framework Policy Information Base March 2000 Reported device limitations may be accompanied by guidance values that can be used by a PDP to determine acceptable values for the identified attributes. The format of the guidance information must be specified where the errors used to signal implementation limitations are defined. 4. Summary of the Framework PIB The Framework PIB comprises four PRCs intended to describe the capabilities of the device and its current configuration. The PRC Support Table 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 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. PIB Incarnation Table This table contains exactly one row (corresponding to one PRI). It identifies the PDP that was the last to download policy into the device and also contains an identifier to identify the version of the policy currently downloaded. This identifier, both its syntax and value, is meaningful only to the PDPs. It is intended to be a mechanism whereby a PDP, on connecting to a PEP, can easily identify a known incarnation of policy. The incarnation PRC also includes an attribute to indicate which context is the active one at any given time. Policy Attribute Limitations Table Some devices may not be able to implement the full range of values for all attributes. In principle, each PRC supports a set of errors that the PEP can report to the PDP in the event that the specified policy is not implementable. There are two problems with this: it may be preferable for the PDP to be informed of the device limitations before actually attempting to install policy, and while the error can indicate that a particular attribute value is unacceptable to the PEP, this does not help the PDP ascertain which values would be acceptable. [Page 6] Framework Policy Information Base March 2000 To alleviate these limitations, the PEP can report some limitations of attribute values in the Attribute Limitations Table. Policy Device Identification This class contains a single policy rule instance that contains device-specific information that is used to facilitate efficient policy installation by a PDP. The instance of this class is reported to the PDP at client connect time so that the PDP can take into account certain device characteristics during policy installation. 5. PIB Operational Overview All PRCs in this Framework PIB have POLICY-ACCESS values of notify or install-notify. Consequently the entire contents of these tables are reported to the PDP as part of each REQ message. 6. The Policy Framework PIB Module POLICY-FRAMEWORK-PIB PIB-DEFINITIONS ::= BEGIN IMPORTS Unsigned32, Integer32, PolicyInstanceId, MODULE-IDENTITY, MODULE-COMPLIANCE, OBJECT-TYPE, FROM COPS-PR-SPPI TruthValue, TEXTUAL-CONVENTION FROM SNMPv2-TC Role, RoleCombination FROM POLICY-DEVICE-AUX-MIB SnmpAdminString FROM SNMP-FRAMEWORK-MIB OBJECT-GROUP FROM SNMPv2-CONF; policyFrameworkPib MODULE-IDENTITY CLIENT-TYPE { all } LAST-UPDATED "200003101800Z" ORGANIZATION "IETF RAP WG" CONTACT-INFO " Michael Fine Cisco Systems, Inc. [Page 7] Framework Policy Information Base March 2000 170 West Tasman Drive San Jose, CA 95134-1706 USA Phone: +1 408 527 8218 Email: mfine@cisco.com Keith McCloghrie Cisco Systems, Inc. 170 West Tasman Drive, San Jose, CA 95134-1706 USA Phone: +1 408 526 5260 Email: kzm@cisco.com John Seligson Nortel Networks, Inc. 4401 Great America Parkway Santa Clara, CA 95054 USA Phone: +1 408 495 2992 Email: jseligso@nortelnetworks.com" DESCRIPTION "A PIB module containing the base set of policy rule classes that are required for support of all policies." ::= { tbd } -- -- The root OID for PRCs in the Framework PIB -- policyBasePibClass OBJECT IDENTIFIER ::= { policyFrameworkPib 1 } -- -- Textual Conventions -- -- -- PRC Support Table -- policyPrcSupportTable OBJECT-TYPE SYNTAX SEQUENCE OF PolicyPrcSupportEntry POLICY-ACCESS notify [Page 8] Framework Policy Information Base March 2000 STATUS current DESCRIPTION "Each instance of this class specifies a PRC that the device supports and a bit string to indicate the attributes of the class that are supported. These PRIs are sent to the PDP to indicate to the PDP which PRCs, and which attributes of these PRCs, the device supports. This table can also be downloaded by a network manager when static configuration is used. All install and install-notify PRCs supported by the device must be represented in this table." ::= { policyBasePibClass 1 } policyPrcSupportEntry OBJECT-TYPE SYNTAX PolicyPrcSupportEntry STATUS current DESCRIPTION "An instance of the policyPrcSupport class that identifies a specific policy class and associated attributes as supported by the device." INDEX { policyPrcSupportPrid } UNIQUENESS { policyPrcSupportSupportedPrc } ::= { policyPrcSupportTable 1 } PolicyPrcSupportEntry ::= SEQUENCE { policyPrcSupportPrid PolicyInstanceId, policyPrcSupportSupportedPrc OBJECT IDENTIFIER, policyPrcSupportSupportedAttrs OCTET STRING, policyPrcSupportMaxPris Unsigned32 } policyPrcSupportPrid OBJECT-TYPE SYNTAX PolicyInstanceId STATUS current DESCRIPTION "An arbitrary integer index that uniquely identifies an instance of the policyPrcSupport class." ::= { policyPrcSupportEntry 1 } policyPrcSupportSupportedPrc OBJECT-TYPE SYNTAX OBJECT IDENTIFIER [Page 9] Framework Policy Information Base March 2000 STATUS current DESCRIPTION "The object identifier of a supported PRC. There may not be more than one instance of the policyPrcSupport class with the same value of policyPrcSupportSupportedPrc." ::= { policyPrcSupportEntry 2 } policyPrcSupportSupportedAttrs OBJECT-TYPE SYNTAX OCTET STRING STATUS current DESCRIPTION "A bit string representing the supported attributes of the class that is identified by the policyPrcSupportSupportedPrc object. Each bit of this bit mask corresponds to a class attribute, with the most significant bit of the i-th octet of this octet string corresponding to the (8*i - 7)-th attribute, and the least significant bit of the i-th octet corresponding to the (8*i)-th class attribute. Each bit of this bit mask specifies whether or not the corresponding class attribute is currently supported, with a '1' indicating support and a '0' indicating no support. If the value of this bit mask is N bits long and there are more than N class attributes then the bit mask is logically extended with 0's to the required length." ::= { policyPrcSupportEntry 3 } policyPrcSupportMaxPris OBJECT-TYPE SYNTAX Unsigned32 STATUS current DESCRIPTION "A non-negative value indicating the maximum numbers of policy rule instances that can be installed in the identified policy rule class. Note that actual number of PRIs that can be installed in a PRC at any given time may be less than this value based on the current operational state (e.g., resources currently consumed) of the device." ::= { policyPrcSupportEntry 4 } -- -- PIB Incarnation Table -- [Page 10] Framework Policy Information Base March 2000 policyPibIncarnationTable OBJECT-TYPE SYNTAX SEQUENCE OF PolicyPibIncarnationEntry POLICY-ACCESS install-notify STATUS current DESCRIPTION "This class contains a single policy rule instance that identifies the current incarnation of the PIB and the PDP or network manager that installed this incarnation. The instance of this class is reported to the PDP at client connect time so that the PDP can (attempt to) ascertain the current state of the PIB. A network manager may use the instance to determine the state of the device with regard to existing NMS interactions." ::= { policyBasePibClass 2 } policyPibIncarnationEntry OBJECT-TYPE SYNTAX PolicyPibIncarnationEntry STATUS current DESCRIPTION "An instance of the policyPibIncarnation class. Only one instance of this policy class is ever instantiated." INDEX { policyPibIncarnationPrid } UNIQUENESS { policyPibIncarnationName } ::= { policyPibIncarnationTable 1 } PolicyPibIncarnationEntry ::= SEQUENCE { policyPibIncarnationPrid PolicyInstanceId, policyPibIncarnationName SnmpAdminString, policyPibIncarnationId OCTET STRING, policyPibIncarnationLongevity INTEGER, policyPibIncarnationTtl Unsigned32, policyPibIncarnationActive TruthValue } policyPibIncarnationPrid OBJECT-TYPE SYNTAX PolicyInstanceId STATUS current DESCRIPTION "An index to uniquely identify an instance of this policy class." ::= { policyPibIncarnationEntry 1 } [Page 11] Framework Policy Information Base March 2000 policyPibIncarnationName OBJECT-TYPE SYNTAX SnmpAdminString STATUS current DESCRIPTION "The name of the PDP that installed the current incarnation of the PIB into the device. By default, it is the zero length string." ::= { policyPibIncarnationEntry 2 } policyPibIncarnationId OBJECT-TYPE SYNTAX OCTET STRING STATUS current DESCRIPTION "An ID to identify the current incarnation. It has meaning to the PDP/manager that installed the PIB and perhaps its standby PDPs/managers. By default, it is the zero-length string." ::= { policyPibIncarnationEntry 3 } policyPibIncarnationLongevity OBJECT-TYPE SYNTAX INTEGER { expireNever(1), expireImmediate(2), expireOnTimeout(3) } STATUS current DESCRIPTION "This attribute controls what the PEP does with the downloaded policy on receipt of a Client Close message or a loss of connection to the PDP. If set to expireNever, the PEP continues to operate with the installed policy indefinitely. If set to expireImmediate, the PEP immediately expires the policy obtained from the PDP and installs policy from local configuration. If set to expireOnTimeout, the PEP continues to operate with the policy installed by the PDP for a period of time specified by policyPibIncarnationTtl. After this time (and it has not reconnected to the original or new PDP) the PEP expires this policy and reverts to local configuration. For all cases, it is the responsibility of the PDP to check the incarnation and download new policy, if necessary, on a [Page 12] Framework Policy Information Base March 2000 reconnect. Policy enforcement timing only applies to policies that have been installed dynamically (e.g., by a PDP via COPS)." ::= { policyPibIncarnationEntry 3 } policyPibIncarnationTtl OBJECT-TYPE SYNTAX Unsigned32 STATUS current DESCRIPTION "The number of seconds after a Client Close or TCP timeout for which the PEP continues to enforce the policy in the PIB. After this interval, the PIB is considered expired and the device no longer enforces the policy installed in the PIB. This attribute is only meaningful if policyPibIncarnationLongevity is set to expireOnTimeout." ::= { policyPibIncarnationEntry 4 } policyPibIncarnationActive OBJECT-TYPE SYNTAX TruthValue STATUS current DESCRIPTION "If this attribute is set to TRUE, then the PIB instance to which this PRI belongs becomes the active PIB instance. The previous active instance becomes inactive and the policyPibIncarnationActive attribute in that PIB instance is automatically set to false." ::= { policyPibIncarnationEntry 5 } -- -- Device Identification Table -- -- This table supports the ability to export general -- purpose device information to facilitate efficient -- communication between the device and a PDP -- policyDeviceIdentificationTable OBJECT-TYPE SYNTAX SEQUENCE OF PolicyDeviceIdentificationEntry POLICY-ACCESS notify [Page 13] Framework Policy Information Base March 2000 STATUS current DESCRIPTION "This class contains a single policy rule instance that contains device-specific information that is used to facilitate efficient policy installation by a PDP. The instance of this class is reported to the PDP at client connect time so that the PDP can take into account certain device characteristics during policy installation." ::= { policyDeviceConfig 3 } policyDeviceIdentificationEntry OBJECT-TYPE SYNTAX PolicyDeviceIdentificationEntry STATUS current DESCRIPTION "An instance of the policyDeviceIdentification class. Only one instance of this policy class is ever instantiated." INDEX { policyDeviceIdentificationPrid } UNIQUENESS { policyDeviceIdentificationDescr, policyDeviceIdentificationMaxMsg } ::= { policyDeviceIdentificationTable 1 } PolicyDeviceIdentificationEntry ::= SEQUENCE { policyDeviceIdentificationPrid PolicyInstanceId, policyDeviceIdentificationDescr SnmpAdminString, policyDeviceIdentificationMaxMsg Unsigned32 } policyDeviceIndentificationPrid OBJECT-TYPE SYNTAX PolicyInstanceId STATUS current DESCRIPTION "An index to uniquely identify an instance of this policy class." ::= { policyDeviceIdentificationEntry 1 } policyDeviceIdentificationDescr OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(0..255)) STATUS current DESCRIPTION "A textual description of the PEP. This value should include the name and version identification of the PEP's hardware and [Page 14] Framework Policy Information Base March 2000 software." ::= { policyDeviceIdentificationEntry 2 } policyDeviceIdentificationMaxMsg OBJECT-TYPE SYNTAX Unsigned32 STATUS current DESCRIPTION "The maximum message size, in octets, that the device is capable of processing. Received messages with a size in excess of this value must cause the PEP to return an error to the PDP containing the global error code 'maxMsgSizeExceeded'." ::= { policyDeviceIdentificationEntry 3 } -- -- Policy Component Limitations Table -- -- This table supports the ability to export information -- detailing policy class/attribute implementation limitations -- to the policy management system. -- policyCompLimitsTable OBJECT-TYPE SYNTAX SEQUENCE OF PolicyCompLimitsEntry POLICY-ACCESS notify STATUS current DESCRIPTION "Each instance of this class identifies a policy class or attribute and a limitation related to the implementaion of the class/attribute in the device. Additional information providing guidance related to the limitation may also be present. These PRIs are sent to the PDP to indicate which PRCs or PRC attributes the device supports in a restricted manner." ::= { policyDeviceConfig 4 } policyCompLimitsEntry OBJECT-TYPE SYNTAX PolicyCompLimitsEntry STATUS current DESCRIPTION "An instance of the policyCompLimits class that identifies a PRC or PRC attribute and a limitation related to the PRC [Page 15] Framework Policy Information Base March 2000 or PRC attribute implementation supported by the device. All PRIs of this class represent errors that would be returned in relation to the identified component for policy installation requests that don't abide by the restrictions indicated by the error code and, possibly, a provided guidance value." INDEX { policyCompLimitsPrid } UNIQUENESS { policyCompLimitsComponent, policyCompLimitsType, policyCompLimitsGuidance } ::= { policyCompLimitsTable 1 } PolicyCompLimitsEntry ::= SEQUENCE { policyCompLimitsPrid PolicyInstanceId, policyCompLimitsComponent OBJECT IDENTIFIER, policyCompLimitsType Integer32, policyCompLimitsGuidance OCTET STRING } policyCompLimitsPrid OBJECT-TYPE SYNTAX PolicyInstanceId STATUS current DESCRIPTION "An arbitrary integer index that uniquely identifies an instance of the policyCompLimits class." ::= { policyCompLimitsEntry 1 } policyCompLimitsComponent OBJECT-TYPE SYNTAX OBJECT IDENTIFIER STATUS current DESCRIPTION "The object identifier of a PRC or PRC attribute that is supported in some limited fashion with regard to it's definition in the associated PIB module. The same PRC or PRC attribute identifier may appear in the table several times, once for each implementation limitation acknowledged by the device." ::= { policyCompLimitsEntry 2 } policyCompLimitsType OBJECT-TYPE SYNTAX Integer32 [Page 16] Framework Policy Information Base March 2000 STATUS current DESCRIPTION "A value describing an implementation limitation for the device related to the PRC or PRC attribute identified by the policyCompLimitsComponent data in this class instance. Values for this object are derived from the defined error values associated with the PRC of the identified attribute or the PRC itself. All genericPrc and specificPrc (defined in a PRC INSTALL-ERRORS clause) error codes represent valid limitation type values. For example, an implementation of the qosIpAce class may be limited in several ways, such as address mask, protocol and Layer 4 port options. These limitations could be exported using this table with the following instances: Prid Component Type Guidance 1 'qosIpAceDstAddrMask' 'valueSupLimited' 0xFFFFFFFF 2 'qosIpAceSrcAddrMask' 'valueSupLimited' 0xFFFFFFFF 3 'qosIpAceProtocol' 'valueSupLimited' 0x06 -- TCP 4 'qosIpAceProtocol' 'valueSupLimited' 0x17 -- UDP 5 'qosIpAceDstL4PortMin' 'invalidDstL4PortData' 6 'qosIpAceDstL4PortMax' 'invalidDstL4PortData' 7 'qosIpAcePermit' 'enumSupLimited' 'true' The above entries describe a number of limitations that may be in effect for the qosIpAce class on a given device. The limitations include restrictions on acceptable values for certain attributes and indications of the relationship between related attributes." ::= { policyCompLimitsEntry 3 } policyCompLimitsGuidance OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..64)) STATUS current DESCRIPTION "A value used to convey additional information related to the implementation limitation noted by the policyCompLimitsType attribute. The value of this attribute must interpreted in the context of the policyCompLimitsType value. Note that a guidance value will not necessarily be provided for all exported limitations. [Page 17] Framework Policy Information Base March 2000 Well-known genericPrc error codes that are applicable to all PRCs, such as 'attrValueSupLimited' and 'attrEnumSupLimited', have guidance value semantics as follows: genericPrc Guidance Semantics attrValueSupLimited Integer32 (4 octets) with supported value attrEnumSupLimited Integer32 (4 octets) with supported enumeration attrMaxLengthExceeded Integer32 (4 octets) with maximum supported length for attribute The specificPrc error codes have the semantics of the associated guidance value specified where the installation error is defined if appropriate. Errors for which the semantics of the guidance value are not specified require this value to be treated in an implementation dependent manner." ::= { policyCompLimitsEntry 4 } -- -- Conformance Section -- policyBasePibConformance OBJECT IDENTIFIER ::= { policyFrameworkPib 2 } policyBasePibCompliances OBJECT IDENTIFIER ::= { policyBasePibConformance 1 } policyBasePibGroups OBJECT IDENTIFIER ::= { policyBasePibConformance 2 } policyBasePibCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "Describes the requirements for conformance to the Policy Framework PIB." MODULE -- this module MANDATORY-GROUPS { policyPrcSupportGroup, policyDevicePibIncarnationGroup, policyDeviceIdentificationGroup, policyCompLimitsGroup } [Page 18] Framework Policy Information Base March 2000 OBJECT policyDevicePibIncarnationLongevity MIN-ACCESS notify DESCRIPTION "Install support is not required." OBJECT policyDevicePibIncarnationTtl MIN-ACCESS notify DESCRIPTION "Install support is not required." OBJECT policyDevicePibIncarnationActiveContext MIN-ACCESS notify DESCRIPTION "Install support is not required." ::= { policyBasePibCompliances 1 } policyPrcSupportGroup OBJECT-GROUP OBJECTS { policyPrcSupportSupportedPrc, policyPrcSupportSupportedAttrs, policyPrcSupportMaxPris } STATUS current DESCRIPTION "Objects from the policyPrcSupportTable." ::= { policyBasePibGroups 1 } policyDevicePibIncarnationGroup OBJECT-GROUP OBJECTS { policyDevicePibIncarnationName, policyDevicePibIncarnationId, policyDevicePibIncarnationLongevity, policyDevicePibIncarnationTtl, policyDevicePibIncarnationActiveContext } STATUS current DESCRIPTION "Objects from the policyDevicePibIncarnationTable." ::= { policyBasePibGroups 2 } policyDeviceIdentificationGroup OBJECT-GROUP OBJECTS { policyDeviceIdentificationDescr, policyDeviceIdentificationMaxMsg } [Page 19] Framework Policy Information Base March 2000 STATUS current DESCRIPTION "Objects from the policyDeviceIdentificationTable." ::= { policyBasePibGroups 3 } policyCompLimitsGroup OBJECT-GROUP OBJECTS { policyCompLimitsComponent, policyCompLimitsType, policyCompLimitsGuidance } STATUS current DESCRIPTION "Objects from the policyCompLimitsTable." ::= { policyBasePibGroups 4 } END [Page 20] Framework Policy Information Base March 2000 7. Security Considerations The information contained in a PIB when transported by the COPS protocol [COPS-PR] may be sensitive, and its function of provisioning a PEP requires that only authorized communication take place. The use of IPSEC between PDP and PEP, as described in [COPS], provides the necessary protection against these threats. 8. Intellectual Property Considerations The IETF is being notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights. 9. Authors' Addresses Michael Fine Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 USA Phone: +1 408 527 8218 Email: mfine@cisco.com Keith McCloghrie Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 USA Phone: +1 408 526 5260 Email: kzm@cisco.com John Seligson Nortel Networks, Inc. 4401 Great America Parkway Santa Clara, CA 95054 USA Phone: +1 408 495 2992 Email: jseligso@nortelnetworks.com Kwok Ho Chan Nortel Networks, Inc. 600 Technology Park Drive Billerica, MA 01821 USA Phone: +1 978 288 8175 Email: khchan@nortelnetworks.com [Page 21] Framework Policy Information Base March 2000 Scott Hahn Intel 2111 NE 25th Avenue Hillsboro, OR 97124 USA Phone: +1 503 264 8231 Email: scott.hahn@intel.com Andrew Smith Extreme Networks 10460 Bandley Drive Cupertino CA 95014 USA Phone: +1 408 342 0999 Email: andrew@extremenetworks.com Francis Reichmeyer IPHighway Inc. Parker Plaza, 16th Floor 400 Kelby St. Fort-Lee, NJ 07024 Phone: (201) 585-0800 Email: FranR@iphighway.com 10. References [COPS] Boyle, J., Cohen, R., Durham, D., Herzog, S., Rajan, R., and A. Sastry, "The COPS (Common Open Policy Service) Protocol" RFC 2748, January 2000. [COPS-PR] K. Chan, D. Durham, S. Gai, S. Herzog, K. McCloghrie, F. Reichmeyer, J. Seligson, A. Smith, R. Yavatkar, "COPS Usage for Policy Provisioning," draft-ietf-rap-cops-pr-02.txt, March 2000. [SPPI] K. McCloghrie, et.al., "Structure of Policy Provisioning Information," draft-ietf-rap-sppi-00.txt, march 2000. [POLICY] M. Stevens, W. Weiss H. Mahon, B. Moore, J. Strassner, G. Waters, A. Westerinen, J. Wheeler, "Policy Framework", draft-ietf-policy-framework-00.txt, September 1999. [RAP-FRAMEWORK] R. Yavatkar, D. Pendarakis, "A Framework for Policy-based Admission Control", draft-ietf-rap-framework-03.txt, April 1999. [Page 22] Framework Policy Information Base March 2000 [SNMP-SMI] K. McCloghrie, D. Perkins, J. Schoenwaelder, J. Case, M. Rose and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [Page 23] Framework Policy Information Base March 2000 Table of Contents 1 Glossary ........................................................ 2 2 Introduction .................................................... 2 3 General PIB Concepts ............................................ 2 3.1 Roles ......................................................... 2 3.1.1 An Example .................................................. 3 3.2 Multiple PIB Instances ........................................ 4 3.3 Reporting of Device Capabilities .............................. 5 3.4 Reporting of Device Limitations ............................... 5 4 Summary of the Framework PIB .................................... 6 5 PIB Operational Overview ........................................ 7 6 The Policy Framework PIB Module ................................. 7 7 Security Considerations ......................................... 21 8 Intellectual Property Considerations ............................ 21 9 Authors' Addresses .............................................. 21 10 References ..................................................... 22 [Page 24]