tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 3318

Historic
Pages: 70
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: RAP

Framework Policy Information Base

Part 1 of 3, p. 1 to 21
None       Next RFC Part

 


Top       ToC       Page 1 
Network Working Group                                     R. Sahita, Ed.
Request for Comments: 3318                                       S. Hahn
Category: Informational                                       Intel Labs
                                                                 K. Chan
                                                         Nortel Networks
                                                           K. McCloghrie
                                                           Cisco Systems
                                                              March 2003


                   Framework Policy Information Base

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

Abstract

   This document defines a set of PRovisioning Classes (PRCs) and
   textual conventions that are common to all clients that provision
   policy using Common Open Policy Service (COPS) protocol for
   Provisioning.

   Structure of Policy Provisioning Information (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 (PRCs) and instances of these classes (PRIs) residing in a
   virtual information store called the Policy Information Base (PIB).

   One way to provision policy is by means of the (COPS) protocol with
   the extensions for provisioning.  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 usage for Policy Provisioning (COPS-PR), each
   client supports a non-overlapping and independent set of PIB modules.
   However, some PRovisioning Classes are common to all subject-
   categories (client-types) and need to be present in each.

Top       Page 2 
Table of Contents

   Conventions used in this document.................................2
   1. Glossary.......................................................2
   2. General PIB Concepts...........................................3
     2.1. Roles......................................................3
       2.1.1. An Example.............................................5
     2.2. Management of Role-Combinations from the PDP...............6
     2.3. Updating a Request State...................................7
       2.3.1 Full Request State......................................8
       2.3.2 Installing PRIs in a Request............................8
       2.3.3 Updating PRIs in a Request..............................8
       2.3.4 Removing PRIs from a Request............................9
       2.3.5 Removing EXTENDED, AUGMENTED PRIs.......................9
       2.3.6 Error Handling in Request updates.......................9
     2.4. Multiple PIB Instances....................................10
     2.5. Reporting and Configuring of Device Capabilities..........11
     2.6. Reporting of Device Limitations...........................12
   3. The Framework TC PIB module...................................12
   4. Summary of the Framework PIB..................................17
     4.1. Base PIB classes Group....................................17
     4.2. Device Capabilities group.................................19
     4.3. Classifier group..........................................20
     4.4. Marker group..............................................20
   5. The Framework PIB Module......................................21
   6. Security Considerations.......................................66
   7. IANA Considerations...........................................67
   8. References....................................................67
     8.1 Normative References.......................................67
     8.2 Informative References.....................................68
   9. Acknowledgments...............................................68
   10. Authors' Addresses...........................................69
   11. Full Copyright Statement.....................................70

Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

1. Glossary

   PRC    PRovisioning Class.  A type of policy data.  See [POLTERM].
   PRI    PRovisioning Instance.  An instance of a PRC.  See [POLTERM].
   PIB    Policy Information Base.  The database of policy information.
          See [POLTERM]
   PDP    Policy Decision Point.  See [RAP-FRAMEWORK].
   PEP    Policy Enforcement Point.  See [RAP-FRAMEWORK].

Top      ToC       Page 3 
2. General PIB Concepts

2.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.  Provisioning classes have an attribute called a
   "RoleCombination" which is a lexicographically ordered set of roles.
   Instances of a given PRovisioning Class are applied to an interface
   if and only if the set of roles in the role combination matches 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.  That is, roles provide a level of indirection to
   the application of a set of policies to specific interfaces.  This
   separates the policy definition from device implementation specific
   interface identification.  Furthermore, if the same policy is being
   applied to several interfaces, that policy needs to 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
   a unique policy for each interface, the administrator can configure
   each interface with a unique role.

   The PEP sends all its Capability Set Names, Role Combinations, Policy
   Controlled Interfaces, and their relationships to the PDP in the
   first COPS request (REQ) message for a handle, and whenever any
   updates or deletes occur.  The PDP can install new instances or
   change existing instances of these PRIs.  This operation can also
   occur in subsequent request messages generated in response to COPS
   state synchronization (SSQ) requests and local configuration changes.

   The comparing of roles (or role combinations) is case sensitive.

Top      ToC       Page 4 
   By convention, when formatting the role-combination for exchange
   within a protocol message, within a PIB object's value, or as a
   printed value, the set is formatted in lexicographical order of the
   role's ASCII values; that is, the role that is first is formatted
   first.  For example, "a+b" and "b+a" are NOT different role-
   combinations; rather, they are different formatting of the same
   role-combination, and hence for this example:

   - "a+b" is the valid formatting of that role-combination,
   - "b+a" is an invalid formatting of that role-combination.

   The role-combination of interfaces to which no roles have been
   assigned is known as the "null" role-combination.  (Note the
   deliberate use of lower-case letters for "null" so that it avoids
   confusion with the ASCII NULL character that has a value of zero but
   a length of one.)

   In an "install" or an "install-notify" class, the wildcard role-
   combination "*" can be used.  In addition to providing for
   interface-specific roles, it also allows for other optimizations in
   reducing the number of role-combinations for which a policy has to be
   specified.  For example:

   Suppose we have three interfaces:

      Roles A, B and R1 are assigned to interface I1
      Roles A, B and R2 are assigned to interface I2
      Roles A, B and R3 are assigned to interface I3

   Then, a PRI of a fictional IfDscpAssignTable that has the following
   values for its attributes:

      ifDscpAssignPrid    = 1
      ifDscpAssignRoles   = "*+A+B"
      ifDscpAssignName    = "4queues"
      ifDscpAssignDscpMap = 1

   will apply to all three interfaces, because "*" matches with R1, R2
   and R3.  The policies can be assigned to an interface due to more
   than one wild-carded role combo matching a given interface's role
   combo string.  The PDP should attempt to resolve conflicts between
   policies before sending policies to the PEP.  In the situation where
   the PDP sends multiple policies to a PEP and they do conflict, either
   because of an error by the PDP or because of a device specific
   conflict, the PEP MUST reject the installation of the conflicting
   policies and return an error.

Top      ToC       Page 5 
   Formally,
   - The wildcard Role is denoted by "*",
   - The "*" Role is not allowed to be defined as part of the role-
     combination of an interface as notified by the PEP to the PDP; it
     is only allowed in policies installed/deleted via COPS-PR from the
     PDP to the PEP.
   - For a policy to apply to an interface when the policy's role-
     combination is "*+a+b", the interface's role-combination:
      - Must include "a" and "b", and
      - Can include zero or more other roles.
   - The wildcard character "*" is listed before the other roles as "*"
     is lexicographically before "a"; however, the wildcard matches any
     zero or more roles, irrespective of lexicographical order.  For
     example: "*+b+e+g" would match "a+b+c+e+f+g".

     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.

2.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 DSCP 5
         P2: Packets from managers (role "manager") get DSCP 6

   To obtain policy, the PEP reports to the PDP that it has some
   interfaces with role combination "finance" and some with role
   combination "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".

Top      ToC       Page 6 
   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 department
   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 DSCP 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.

2.2. Management of Role-Combinations from the PDP

   The PEP notifies the PDP of the Role-Combination assigned to each
   interface and capability set name in a COPS configuration request
   (instances of the frwkIfRoleComboTable).  The first request sent to
   the PDP must be a 'full state' request.  A 'full state' request for a
   PEP includes notify and install-notify table PRIs for the PEP which
   must be interpreted as the complete state of the PEP and must not be
   interpreted as updates to any previous set of PRIs sent in a previous
   message.  Any previous PRIs from the PEP should be discarded when a
   'full state' request is received for the particular request handle.
   A request is specified as a 'full state' request by setting the
   frwkPibIncarnationFullState attribute in the frwkPibIncarnation PRI
   sent in the request.

   All existing frwkIfRoleCombo instances must be sent to the PDP in the
   first configuration request for a request handle.  If the Role-
   Combinations are not assigned specific values, default ('null')
   Role-Combinations must be sent to the PDP for all ifIndices active on
   the PEP and updates must be sent every time the IfIndices are
   updated.  The PEP may notify the PDP of the Capability sets (if any)
   via the frwkCapabilitySetTable.  If the PEP does not need to notify
   the PDP of capability sets, it must set the capability set name in
   the frwkIfRoleComboTable instances to a zero length string.

   In response to this configuration request, if applicable, the PDP may
   send policies for the PEP in a solicited decision or must send a null
   decision.  The PEP must then send a solicited report message for the
   decision.

Top      ToC       Page 7 
   At any later time, the PDP can update the Role-Combinations assigned
   to a specific interface, identified by IfIndex, or for an aggregate,
   identified by the capability set name, via an unsolicited decision to
   the PEP on any open request handle.  The PDP does this by sending
   updated PRIs for the frwkIfRoleComboTable.

   When the Interface Role Combination associations are updated by the
   PDP, the PEP SHOULD send updated 'full state' requests for all open
   contexts.  A context is an instantiation of the PIB module(s)
   namespace identified by a unique COPS handle for a particular COPS
   client type.  This is true even if the PEP's request state changes
   due to an internal event or if the state is changed by the PDP.  If
   the role-combination updates were sent by the PDP, the PEP SHOULD
   send these updated requests only if it can process the unsolicited
   decision containing the frwkIfRoleCombo PRIs successfully, and it
   MUST do so after sending the success report for the unsolicited
   decision.  If the PEP failed to process the decision (i.e., the
   frwkIfRoleCombo PRIs), it MUST only send a failure report to the PDP.

   On the other hand, the PDP must not expect to receive the updated
   requests with the revised role-combination information until after it
   receives a success report for these updates from the PEP.  If the PDP
   does not receive updated requests on some request handles, the PEP
   must not be sent decision updates for that frwkIfRoleCombo updates,
   i.e., the PDP must have the previous request state that it maintained
   for that request handle.

   Note that, any unsolicited decisions received by the PEP in the time
   period after it receives updates to its Role-Combination associations
   and before receiving solicited decisions for the updated requests it
   sent for all context handles, could possibly contain outdated
   policies corresponding to the old Role-Combination associations as
   notified by this PEP in a previous request state.

   The PDP must respond to the updated requests by solicited decisions,
   sending policies if applicable or null decisions.  The PEP must
   respond to these solicited decisions with solicited reports to
   complete the transaction.

2.3. Updating a Request State

   This section describes the messages exchanged between the PEP and PDP
   when the PEP is updating a previously sent request for a particular
   COPS handle.  Note that a PEP can incrementally update a request only
   if the frwkPibIncarnationFullState attribute is shown to be supported
   via the supported PRC table.  If this attribute is not supported, the
   PDP must treat all PEP requests as the full request state.

Top      ToC       Page 8 
2.3.1 Full Request State

   When the PEP wants to send the entire request state to the PDP (for
   example, in response to a Synchronize State Request from the PDP),
   the PEP MUST send the incarnation instance with the
   frwkPibIncarnationFullState attribute set to 'true'.

   A PDP that receives an incarnation instance in the request message
   with this attribute set to 'true', must clear the request information
   it maintains for this request handle and re-install the information
   received.

   If this attribute is set to 'false' or if the incarnation instance is
   missing in the request message, the request must be interpreted as an
   incremental update to the previous request message.

2.3.2 Installing PRIs in a Request

   If the PEP wants to install additional PRIs for a request handle, the
   PEP MUST ensure that the frwkPibIncarnationFullState attribute is set
   to 'false', and the PEP MUST use new (unused in this context)
   InstanceIds [SPPI] for these PRIs.

   When a PDP receives instances with new InstanceIds for a request with
   the frwkPibIncarnationFullState in the incarnation instance set to
   'false', or if the request has no incarnation information, it must
   interpret these PRIs as an incremental update to the request state
   and add them to the request state it maintains for this handle.

2.3.3 Updating PRIs in a Request

   If the PEP wants to update previously installed PRIs for a request
   handle, the PEP MUST ensure that the frwkPibIncarnationFullState
   attribute is set to 'false' for these PRIs.  Note that the PEP must
   send the same InstanceIds for the PRIs being updated.  If the PEP
   uses new InstanceIds, the PDP must interpret them as Install's for
   this request state.

   When a PDP receives a request with instances having InstanceIds that
   exist in its state for that handle with the
   frwkPibIncarnationFullState in the incarnation instance set to
   'false' or if the request has no incarnation information, it must
   interpret these PRIs as an update to the PRIs in the request state it
   maintains for this handle.

Top      ToC       Page 9 
2.3.4 Removing PRIs from a Request

   If the PEP wants to remove previously installed PRIs for a request
   handle, the PEP MUST ensure that the frwkPibIncarnationFullState
   attribute is set to 'false', and MUST send the PRI bindings with the
   PRID set to the InstanceId of the PRI to be removed, and the length
   field in the EPD object header set to the header length only,
   effectively setting the data length to zero.

   Note that the PEP must send the same InstanceIds for the PRIs being
   removed.  If the PEP sends new InstanceIds and the length field in
   the EPD object header is set to the header length only (implying the
   data length is zero), the PEP is attempting to remove an
   unknown/non-existent PRI.  This SHOULD result in the PDP sending
   error PRIs in the solicited decision (see section 2.3.6 for a
   description of the frwkErrorTable).

   If the PEP sends new InstanceIds, and the length field in the EPD
   object header is greater than the header length only (implying the
   EPD object has some attributes encoded in it), the PDP will interpret
   this as an install of the PRI if it can decode the EPD successfully.

   When a PDP receives a request with instances having InstanceIds that
   exist in its state for that handle with the
   frwkPibIncarnationFullState in the incarnation instance set to
   'false', or if the request has no incarnation information, and the
   length field in the EPD object header is set to the header length
   only (implying the data length is zero), it must remove these PRIs
   from the request state it maintains for this handle.

2.3.5 Removing EXTENDED, AUGMENTED PRIs

   The PEP should remove the extended/augmented PRIs when it removes the
   base PRIs in the same COPS message.  See [SPPI] for a description of
   EXTENDED/AUGMENTED PRCs.  A PDP that receives removes for a base PRI
   must implicitly remove the extensions.

2.3.6 Error Handling in Request updates

   If the PDP cannot process all the request installs/updates/removes in
   the COPS request message successfully, it MUST rollback to its
   previous request state and it MUST send a solicited decision to the
   PEP that contains frwkErrorTable instances.  These instances contain
   an error code and a sub-code as defined in the [COPS-PR] CPERR
   object.  For example, if the PEP tries to remove an instance that
   does not exist, the 'priInstanceInvalid' error code must be sent to
   the PEP in a frwkError PRI.  The frwkError PRIs also contain the PRC
   and the InstanceId of the error-causing PRI.  The PEP may then

Top      ToC       Page 10 
   examine these error PRIs and resend the modified request.  Note that,
   until the PEP resends the request updates/removes, it will have
   configuration information for the last successful request state it
   sent to the PDP.

2.4. Multiple PIB Instances

   [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 that can then be made
   active by a single, short decision from the PDP.

   A COPS context can be defined as an independent COPS request state
   for a particular subject category (client-type).  A context may be an
   outsourcing context or a configuration context.  A configuration
   context is an instance of the PIB triggered and controlled by the
   PDP, which contains device setup information.  This device
   configuration information dictates the device behavior as specified
   by the PDP.  An outsourcing context on the other hand, is a PIB
   instance that is triggered from the PEP side and is a request to the
   PDP for action.  The action requested will be interpreted in the
   domain of the client-type.  Configuration contexts belong to a set of
   configuration contexts for a specific client type - out of which one
   configuration context may be active.  However, multiple outsourcing
   contexts can be active simultaneously.

   With the [COPS-PR] protocol, each of these states is identified by a
   unique client handle.  The creation and deletion of these PIB
   instances can be controlled by the PDP as described in [COPS-PR] or
   can be triggered by an event by the PEP.  A PEP must open at least
   one "request-state" for configuration for a given subject-category
   (client type).  Additional "request-states" at the PEP may be
   initiated by the PDP or asynchronously generated by the PEP for
   outsourcing due to local events, which will be fully specified by the
   PRID/EPD data carried in the request.

   The frwkPibIncarnationInCtxtSet flag defines a set of contexts out of
   which only one context can be active at any given time.  This set is
   called the 'configuration contexts' set.  At most, one context may be
   active from this 'configuration context' set at any given time.
   Contexts that have the frwkPibIncarnationInCtxtSet attribute set to
   'true' belong to this set.  Contexts that do not belong to this set
   have the frwkPibIncarnationInCtxtSet set to 'false' and belong to the
   set of 'outsourcing contexts'.  Note that a PEP can have these two
   sets of contexts only if the frwkPibIncarnationInCtxtSet attribute is
   shown to be supported via the supported PRC table.  If the

Top      ToC       Page 11 
   frwkPibIncarnationInCtxtSet is not supported, a PEP must treat all
   contexts as belonging to the set of 'configuration contexts' i.e., at
   the most one context can be active at any given time.

   Note that in the event that a PEP has a capability change such as a
   card hot swap or any other change in its notify information that may
   warrant a policy refresh, a subsequent complete or incremental
   request must be issued to the PDP containing the new/updated
   capabilities for all the configuration contexts.  A request for re-
   configuration is issued for all request state configuration contexts,
   both for the active configuration context as well as any inactive
   configuration contexts.  This is to ensure that when an inactive
   configuration context is activated, it has been pre-configured with
   policies compatible with the PEP's current capabilities.

   Although many PIB instances may be configured on a device (the
   maximum number of these instances being determined by the device
   itself), only one of the contexts from the 'configuration contexts'
   set can be active at any given time; the active one being selected by
   the PDP.  The Framework PIB supports the attribute
   frwkPibIncarnationActive in the frwkPibIncarnationTable to allow the
   PDP to denote the PIB instance as being active in a COPS decision
   message, and similarly, to report the active state (active or not) of
   the PIB instance to the PDP in a COPS request message.

   When the PEP installs an attribute frwkPibIncarnationActive that is
   'true' in one PIB instance which belongs to the 'configuration
   contexts' set, the PEP must ensure, re-setting the attribute if
   necessary, that the frwkPibIncarnationActive attribute is 'false' in
   all other installed contexts that belong to this set.  To switch
   contexts, the PDP should set the frwkPibIncarnationActive attribute
   to 'true' in the context it wants to make the active context.  The
   PDP should set this attribute in a context to 'false' only if it
   wants to send an inactive context to the PEP or deactivate the active
   context on the PEP.  If an active context is made inactive without
   activating another context, the PEP must not have any policies
   enforced from any configuration contexts installed.

2.5. Reporting and Configuring 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 organized into Capability Sets, with each Capability
   Set given a unique name (frwkCapabilitySetName) and associated with a
   set of Role Combinations.  In that way, each Role Combination may be
   associated with a set of interfaces.  These capabilities are

Top      ToC       Page 12 
   communicated to the PDP when policy is requested by the PEP.  Knowing
   device capabilities, the PDP can send the PRIs relevant to the
   specific device, rather than sending the entire PIB.

   Specific capability PRCs may be defined in other PIBs.  These
   capability instances are grouped via the frwkCapabilitySetTable.  If
   the PEP wishes to send capability information to the PDP, the PIB
   must indicate which capabilities the PEP may send to the PDP by means
   of the 'notify' PIB-ACCESS clause as described in [SPPI].  If a PIB
   does not have any capabilities to communicate to the PDP, it must not
   send any instances for the frwkCapabilitySetTable.  If in this case
   the frwkIfRoleCombo table is used to communicate role combinations
   assigned to interfaces (via IfIndex), the frwkRoleComboCapSetName
   attribute in the frwkIfRoleComboTable instances must be set to a zero
   length string.

2.6. 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 policy is requested.

   Reported device limitations may be accompanied by guidance values
   that can be used by a PDP to determine acceptable values for the
   identified attributes.

3. The Framework TC PIB module

FRAMEWORK-TC-PIB  PIB-DEFINITIONS ::= BEGIN

IMPORTS  MODULE-IDENTITY, TEXTUAL-CONVENTION,
         Unsigned32, pib FROM COPS-PR-SPPI;

frwkTcPib  MODULE-IDENTITY
    SUBJECT-CATEGORIES   { all }
    LAST-UPDATED "200302130000Z"  -- 13 Feb 2003
    ORGANIZATION "IETF RAP WG"

Top      ToC       Page 13 
    CONTACT-INFO "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

                  Ravi Sahita
                  Intel Labs.
                  2111 NE 25th Ave.
                  Hillsboro, OR 97124 USA
                  Phone: +1 503 712 1554
                  Email: ravi.sahita@intel.com

                  RAP WG Mailing list: rap@ops.ietf.org "
    DESCRIPTION
         "The PIB module containing the Role and RoleCombination
         Textual Conventions and other generic TCs.

         Copyright (C) The Internet Society (2003). This version of
         this PIB module is part of RFC 3318; see the RFC itself for
         full legal notices."

    REVISION     "200302130000Z"  -- 13 Feb 2003
    DESCRIPTION  "Initial version, published in RFC 3318."
      ::= { pib 3 }

Role ::= TEXTUAL-CONVENTION
    STATUS       current
    DESCRIPTION
        "A role represents a functionality characteristic or
        capability of a resource to which policies are applied.
        Examples of roles include Backbone_interface,
        Frame_Relay_interface, BGP-capable-router, web-server,
        firewall, etc.
        The only valid character set is US-ASCII. Valid characters
        are a-z, A-Z, 0-9, period, hyphen and underscore. A role
        must always start with a letter (a-z or A-Z). A role must
        not contain the US-ASCII characters '*' or '+' since they
        have special meaning associated with them, explained in the
        RoleCombination TEXTUAL CONVENTION."

Top      ToC       Page 14 
    SYNTAX OCTET STRING (SIZE (1..31))

RoleCombination ::= TEXTUAL-CONVENTION
    STATUS       current
    DESCRIPTION
        "An octet string containing concatenated Roles. For the
        format specification of roles, refer to the 'Role' TEXTUAL-
        CONVENTION. A valid Role Combination must be formed by a set
        of valid Roles, concatenated by the US-ASCII character '+',
        where the roles are in lexicographic order from minimum to
        maximum. For example, 'a+b' and 'b+a' are NOT different
        role-combinations; rather, they are different formatting of
        the same (one) role-combination.

        Notice the roles within a role-combination are in
        Lexicographic order from minimum to maximum, hence, we
        declare:
        'a+b' is the valid formatting of the role-combination,
        'b+a' is an invalid formatting of the role-combination.

        Notice the need of zero-length role-combination as the role-
        combination of interfaces to which no roles have been
        assigned. This role-combination is also known as the 'null'
        role-combination. (Note the deliberate use of lower case
        letters to avoid confusion with the US-ASCII NULL character
        which has a value of zero but length of one.)

        The US-ASCII character '*' is used to specify a wild carded
        Role Combination. '*' must not be used to wildcard Roles.
        Hence, we declare:
        '*+a+b' is a valid wild carded Role Combination.
        'eth*+a+b' is not a valid wild carded Role Combination.
        Note that since Roles are lexicographically listed in a Role
        Combination, the following is an invalid role combination,
        since '*' is lexicographically before 'a': 'a+b+*'."
    SYNTAX OCTET STRING  (SIZE (0..255))

PrcIdentifierOid ::= TEXTUAL-CONVENTION
    STATUS       current
    DESCRIPTION
        "An OID that identifies a PRC. The value MUST be an OID
        assigned to a PRC's entry definition. The Entry definition
        of a PRC has an OID value XxxTable.1 where XxxTable is the
        OID assigned to the PRC table object.

        An attribute with this syntax MUST specify a PRC, which is
        defined in the PIB module(s) registered in the context of
        the client-type used.

Top      ToC       Page 15 
        An attribute with this syntax cannot have the value 0.0
        (zeroDotZero). If the attribute using this syntax can be set
        to 0.0 use the PrcIdentifierOidOrZero TEXTUAL-CONVENTION
        which makes such use explicit."
    SYNTAX    OBJECT IDENTIFIER

PrcIdentifierOidOrZero ::= TEXTUAL-CONVENTION
    STATUS       current
    DESCRIPTION
        "An OID that identifies a PRC or zeroDotZero (0.0). The
        value MUST be an OID assigned to a PRC's entry definition or
        0.0  (zeroDotZero). The Entry definition of a PRC has an OID
        value XxxTable.1 where XxxTable is the OID assigned to the
        PRC table object.

        An attribute with this syntax can have the value 0.0
        (zeroDotZero) to indicate that it currently does not
        identify a PRC."
    SYNTAX    OBJECT IDENTIFIER

AttrIdentifier ::= TEXTUAL-CONVENTION
    STATUS       current
    DESCRIPTION
        "A Unsigned32 value that identifies an attribute in a PRC by
        its sub-id. The sub-id is the OID assigned to this attribute
        in the PRC definition.

        A AttrIdentifier value is always interpreted within the
        context of an attribute of type PrcIdentifierOid or
        PrcIdentifierOidOrZero. The PrcIdentifierOid (or
           PrcIdentifierOidOrZero) object which defines the context
        must be registered immediately before the object which uses
        the AttrIdentifier textual convention. If the context
        defining attribute is of type PrcIdentifierOidOrZero and has
        the value 0.0, then in that case this attribute value has no
        meaning.

        An attribute with this syntax MUST specify a sub-id which
        MUST be defined in the PRC identified (if any) in the
        PrcIdentifierOid (or PrcIdentifierOidOrZero) attribute. The
        PrcIdentifierOid (orZero) and the AttrIdentifier attributes
        together identify a particular attribute in a particular
        PRC.

Top      ToC       Page 16 
        An attribute with this syntax cannot have the value 0
        (zero). If the attribute using this syntax can be set
        to 0 use the AttrIdentifierOrZero TEXTUAL-CONVENTION which
        makes that explicit."
    SYNTAX    Unsigned32 (1..4294967295)

AttrIdentifierOrZero ::= TEXTUAL-CONVENTION
    STATUS       current
    DESCRIPTION
        "A Unsigned32 value that identifies an attribute in a PRC by
        its sub-id or has the value 0 (zero). The sub-id if non-
        zero, is the OID assigned to this attribute in the PRC
        definition.

        An AttrIdentifierOrZero value is always interpreted within
        the context of an attribute of type PrcIdentifierOid or
        PrcIdentifierOidOrZero. The PrcIdentifierOid (or
        PrcIdentifierOidOrZero) object that defines the context must
        be registered immediately before the object which uses the
        AttrIdentifierOrZero textual convention. If the context
        defining attribute is of type PrcIdentifierOidOrZero and has
        the value 0.0, then in that case this attribute value has no
        meaning.

        An attribute with this syntax can have the value 0 (zero) to
        indicate that it currently does not identify a PRC
        attribute. If it has a non-zero value, the
        PrcIdentifierOid (orZero) and the AttrIdentifierOrZero
        attributes together identify a particular attribute in a
        particular PRC."
    SYNTAX    Unsigned32

AttrIdentifierOid ::= TEXTUAL-CONVENTION
    STATUS       current
    DESCRIPTION
        "An OID that identifies an attribute in a PRC. The value
        MUST be an OID assigned to a PRC's attribute definition. The
        last sub-id is the sub-id of the attribute as it is
        defined in the PRC entry definition. The prefix OID (after
        dropping the last sub-id) is the OID assigned to the Entry
        object of a defined PRC. The Entry definition of a PRC has
        an OID value XxxTable.1 where XxxTable is the OID assigned
        to the PRC Table object.

        An attribute with this syntax MUST not have the value 0.0
        (zeroDotZero). If 0.0 is a valid value, the TEXTUAL
        CONVENTION AttrIdentifierOidOrZero must be used which makes
        such use explicit."

Top      ToC       Page 17 
    SYNTAX    OBJECT IDENTIFIER

AttrIdentifierOidOrZero ::= TEXTUAL-CONVENTION
    STATUS       current
    DESCRIPTION
        "An OID that identifies an attribute in a PRC or has a value
         0.0 (zeroDotZero). The value MUST be an OID assigned to a
         PRC's attribute definition or the value 0.0.

         If not 0.0, the last sub-id MUST be the sub-id of the
         attribute as it is defined in the PRC Entry object
         definition. The prefix OID (after dropping the last sub-id)
         is the OID assigned to the Entry object of a defined PRC.
         The Entry definition of a PRC has an OID value XxxTable.1
         Where, XxxTable is the OID assigned to the PRC Table
         object.

         An attribute with this syntax can have the value 0.0
         (zeroDotZero) to indicate that it currently does not
         identify a PRC's attribute."
    SYNTAX    OBJECT IDENTIFIER

ClientType ::= TEXTUAL-CONVENTION
    STATUS       current
    DESCRIPTION
        "An Unsigned32 value that identifies a COPS Client-type. An
        attribute with this syntax must be set to zero if it does
        not specify a COPS client-type for the PRI."
    REFERENCE
        "The COPS (Common Open Policy Service) Protocol, RFC 2748."
    SYNTAX    Unsigned32 (0..65535)

ClientHandle ::= TEXTUAL-CONVENTION
    STATUS       current
    DESCRIPTION
        "An octet string that identifies a COPS Client handle. A
        zero length value implies the attribute does not specify a
        valid client handle."
    REFERENCE
        "The COPS (Common Open Policy Service) Protocol, RFC 2748."
    SYNTAX    OCTET STRING (SIZE(0..65535))

END

Top      ToC       Page 18 
4. Summary of the Framework PIB

   The Framework PIB defines four groups of PRCs:

4.1. Base PIB classes Group

   This contains PRCs intended to describe the PRCs supported by the
   PEP, PRC and/or attribute limitations and its current configuration.

      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 or extended with new attributes.  Also, it is
         likely that some existing PRCs or individual attributes of PRCs
         will be deprecated.  The PRC Support Table describes the PRCs
         that the device supports as well as the individual attributes
         of each PRC.  Using this information the PDP can potentially
         tailor the policy to more closely match the capabilities of the
         device.  The PRC Support Table instances are specific to the
         particular Subject Category (Client-Type).  That is, the PRC
         Support Table for Subject Category 'A' will not include
         instances for classes supported by the Subject Category 'B'.
         Note that the COPS client-type [COPS] used for Framework PIB
         PRIs sent/received over COPS-PR MUST be the unique SUBJECT-
         CATEGORY number assigned for the area of policy being managed
         (e.g., QoS, Security etc). The PEP MUST ignore the attributes
         that it reports as not Supported in the decision from the PDP.
         The PEP SHOULD not send duplicate PRC support instances in a
         COPS Request and the PDP MUST ignore duplicate instances and
         MUST use the first instance received for a supported PRC in a
         COPS Request.

      PIB Incarnation Table

         This PRC contains exactly one row (corresponding to one PRI)
         per context.  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,
         when accepting a connection from a PEP, can easily identify a
         known incarnation of policy.  This PRC defines a flag via which
         the installed contexts are divided into a set of contexts
         ('configuration contexts') out of which only one context is
         active and a the remaining contexts form a set of 'outsourcing
         contexts' which are all active.  The incarnation PRC also
         defines an attribute to indicate which configuration context is

Top      ToC       Page 19 
         the active one at the present time in the 'configuration
         contexts' set.  The incarnation instance is specific to the
         particular Subject Category (Client-Type).

      Component 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.  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.  To alleviate these
         limitations, the PEP can report some limitations of attribute
         values and/or classes and possibly guidance values for the
         attribute in the Component Limitations Table

      Device Identification Table

         This PRC contains a single PRI that contains device-specific
         information that is used to facilitate efficient policy
         installation by a PDP.  The instance of this PRC is reported to
         the PDP in a COPS request message so that the PDP can take into
         account certain device characteristics during policy
         installation.

4.2. Device Capabilities group

   This group contains the PRCs that describe the characteristics of
   interfaces of the device and the Role Combinations assigned to them.

      Capabilities Set Table

         The capabilities the PEP supports are described by rows in this
         PRC (frwkCapabilitySetTable).  Each row, or instance of this
         class, associates a unique capability name with a set of
         capabilities that an entity on the PEP may support.  The unique
         name is used to form a set of capabilities that the name
         represents.  The capability references can specify instances in
         relevant capability tables in any PIB.  The PEP notifies the
         PDP of these capability sets and then the PDP configures the
         interfaces, per role combination.  The unique name
         (frwkCapabilitySetName) is not to be confused with the IfType
         object in the Interfaces Group MIB [RFC2863].

Top      ToC       Page 20 
      Interface and Role Combination Table

         The Capabilities Set Table (explained above) describes the
         entities on the PEP (for example, interfaces) by their
         capabilities, by assigning the capability sets a unique name
         (frwkCapabilitySetName).  It is possible to tailor the behavior
         of interfaces by assigning specific role-combinations to the
         capability sets.  This allows interfaces with the same
         capability sets to be assigned different policies, based on the
         current roles assigned to them.  At the PDP, configuration is
         done in terms of these interface capability set names and the
         role-combinations assigned to them.  Thus, each row of this
         class is a <Interface Index, interface capability set name,
         Role Combo> tuple, that indicates the roles that have been
         assigned to a particular capability set (as identified by
         frwkRoleComboCapSetName) and to a particular interface.  Note
         that the uniqueness criteria for this PRC has all the
         attributes, thus a frwkRoleComboCapSetName may have multiple
         role-combinations that it is associated with.  Via the IfIndex,
         this PRC answers the questions of 'which interfaces have a
         specific role combination?' and 'what role combination a
         specific interface is a part of?'.

4.3. Classifier group

   This group contains the IP, IEEE 802 and Internal Label Classifier
   elements.  The set of tables consist of a Base Filter table that
   contains the Index InstanceId and the Negation flag for the filter.
   This frwkBaseFilterTable is extended to form the IP Filter table, the
   802 Filter table [802] and the Internal Label table.  Filters may
   also be defined outside this document and used to extend the Base
   Filter table.

   The Extended classes do not have a separate Index value. Instances of
   the extended classes have the same indices as their base class
   instance.  Inheritance is achieved using the EXTENDS keyword as
   defined in [SPPI].

4.4. Marker group

   This group contains the 802 marker and internal label marker PRCs.
   The 802 marker may be applied to mark 802 packets with the required
   VLAN Id and/or priority value.  The Internal Label marker is applied
   to traffic in order to label it with a network device specific label.
   Such a label is used to assist the differentiation of an input flow
   after it has been aggregated with other flows.  The label is

Top      ToC       Page 21 
   implementation specific and may be used for other policy related
   functions like flow accounting purposes and/or other data path
   treatments.



(page 21 continued on part 2)

Next RFC Part