[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 RFC 3318

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]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/