Internet Draft Diana Rawlins Expiration: May 2001 Lei Yao File: draft-rawlins-rsvppcc-pib-00.txt Richard McClain WorldCom Amol Kulkarni Intel RSVP Policy Control Criteria PIB November 16, 2000 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 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 [RFC-2119]. Abstract This draft describes the use of COPS-PR for support of a PDP provisioning a PEP with RSVP policy control criteria and defines a RSVP policy control criteria PIB for this purpose. The RSVPCC-PIB described in the document is provided for definition of policies that are currently defined by the outsourcing model [2749]. It is designed to be scalable and flexible as well as extensible for accommodating future policy criteria. Rawlins et al. Expires May 2001 [Page 1] Internet Draft RSVP-PCC-PIB November 2000 Table Of Contents 1 Introduction.....................................................3 2 General Concepts.................................................4 2.1 Overview.......................................................4 2.2 Normal Operation...............................................4 2.3 RSVP Policy Processing Models with local policy criteria.......4 2.4 Session Classification and Reservation Styles..................5 3 PIB Summary......................................................5 3.1 Capabilities Table - policyControlCapsTable....................6 3.2 PPC Linkage Table - pccLinkTable..............................6 3.3 Authorization Policy Tables....................................6 3.5 Example........................................................7 4 The RSVP Policy Control Criteria PIB Module......................7 5 Security Considerations.........................................18 6 Acknowledgements................................................18 7 Authors Addresses...............................................19 8 References......................................................19 Rawlins et al. Expires May 2001 [Page 2] Internet Draft RSVP-PCC-PIB November 2000 1 Introduction The RSVP Policy Control Criteria PIB defines the policy criteria used to authorize an RSVP reservation request. The policy criteria defined by this PIB are enforced by the RSVP enabled Policy Enforcement Point (PEP). These are provisioned by the Policy Decision Point (PDP) rather than outsourced to the PDP. Policy control is an important processing component described in RSVP [2205]. While admission control evaluates the resources available at the RSVP enabled interface, it does not determine if the requested reservation is allowed. Policy control determines whether the policy is allowed (or authorized.) It may base the decision on multiple factors including application identification, policy authentication preemption rules and service level agreements. Two basic models are defined for prescribing policy to a network enforcement device using COPS [2748]. First, there is an outsourcing mechanism for policy control where the network device requests a policy decision from an external policy server and is defined in [2749]. This mechanism can be used in conjunction with a local decision policy scheme that outsources information to the PDP for confirmation of the locally made decision [2753]. There also exists a policy configuration mechanism that does not require the network device to outsource all policy decisions. The device is provisioned with decision policy a priori of the traffic flow. The provisioning model relies upon Policy Information Bases (PIB) that define the policies to be enforced by the PEP. [COPS-PR.] Currently there is no PIB defining RSVP policy control criteria to be conveyed by the provisioning model. Provisioned policy control criteria are useful in topologies where large numbers of signaling flows are transiting a set of well know boundary devices. The sheer volume and nature of the application generating RSVP signals (such as with VoIP) may make outsourcing policy impractical at some boundary devices. The use of local policy control criteria is an attractive alternative to going off-board to another policy device for all PATH and RESV messages and their associated contexts (Incoming / Allocation / Outgoing), which reduces the response time of policy control and the amount of policy control traffic on the network. However, reliance on a network operator to manually provision the policy criteria locally per device is not a preferred solution. It is labor-intensive and time-consuming as well as error prone. It also limits the flexibility of policy control. For example, it prohibits the possibility of customer self-provisioning policy controlled services, which is a provisioning mechanism driven by both service providers and customers. This document proposes a mechanism to automatically provision RSVP policy control criteria on the network devices. Rawlins et al. Expires May 2001 [Page 3] Internet Draft RSVP-PCC-PIB November 2000 2 General Concepts 2.1 Overview This document defines a RSVP Policy Control Criteria PIB. The RSVP Policy Control Criteria PIB provides the policy classes describing the criteria for policy control to the PEP so it does not need to outsource decisions for all RSVP signals. Together with the PIB defined in this document, COPS-PR is used to push RSVP related policy control criteria from a PDP to a PEP. Thus the RSVP policy control criteria are installed on the PEP a priori of the impacted RSVP signals and policy control decisions for RSVP messages passing the PEP can be made locally. The use of provisioned policy criteria does not prohibit the outsourcing of policy decisions. The outsourcing and provisioned policy approaches may be used in combination with each other as defined by three æprocessing modelsÆ: - Take local decisions AND outsource each request to the PDP for confirmation as described in [2753]. - Take local decisions and outsource ONLY IF no relevant local policy is found. - Take local decisions only. Do not outsource. Feedback must be provided to the PDP about the usage of policy at the PEP. The PEP monitors, tracks and provides periodic accounting type reports to the PDP. 2.2 Normal Operation When a PEP is initialized, a COPS session connection is established for SUBJECT_CATEGORY RSVP-PCC between the PEP and PDP. The PEP issues the request for initial configuration describing its basic PIB policy capabilities per [POLFRWK.] The policy classes supported by the PEP are indicated with the PRCSupportTable instances. The PEP also describes the policy model capability associated with that interface using an instance of the RSVPPccCapTable. The Policy Decision Point determines the appropriate policy information to supply the PEP and responds with a decision install. The PEP confirms the success or failure of the configuration decision with a report. The failover operation of the PEP and PDP is described in [COPS-PR.] 2.3 RSVP Policy Processing Models with local policy criteria The policy control processing follows one of three possible models: Rawlins et al. Expires May 2001 [Page 4] Internet Draft RSVP-PCC-PIB November 2000 - One model is the LDP model [2753]. The installed policy criteria are used to make Local Decision. If local policy approves the reservation request the RSVP message continues its normal processing. The LDP then confirms the decision with the PDP by issuing a request with the LPDP Decsion Object. The PDP then issues a final decision which is enforced by the PEP. - The second model is where the PEP performs policy control by approving a reservation request based on installed policy criteria. In the event that no policy exists for the reservation request, the PEP then outsources the request to the PDP. The PDP then decides to approve or deny the request [2749]. In other words, when a PEP receives a RSVP message, it first queries Local RSVP policy control criteria if there is one existing on the PEP. Otherwise, the PEP uses COPS-RSVP to query PDP for outsourcing policy decisions. Note that the PEP must send periodic reports to the PDP informing it of all factors that affect decision-making at the PDP e.g. the resource usage etc. Also, all pending reports should be sent to the PDP before a request is outsourced to it. This helps the PDP maintain an accurate picture of resource availability at the PEP while making decisions. - The third model is where the PEP relies entirely upon the provisioned policy control criteria for its policy control decision- making. If no policies are found for a policy request of a RSVP session, the RSVP session should be rejected. 2.4 Session Classification and Reservation Styles The IP filters, frwkIPFilterTable, described in [POLFRWK] are used to associate the authorization (or enforcement) policy with a RSVP session. These filter instances provide the ability to identify the flow 5-tuple: source address, source port, destination address, destination port and protocol id. The RSVP Sender_Template Class, FilterSpec Class and Session Class can be classified using the frwkIPFilterTable. The 5-tuple filter instances may be defined using a wildcard value for the attribute, which accommodates classification policies for the RSVP reservation styles û Fixed Filter, Shared Explicit and Wildcard. 3 PIB Summary Multiple sets of policy control criteria are installed at the PEP. A set of policy criteria basically contains elements of filter policy, authorization policy, linkage policy and usage policy. The filter policy identifies the signal flows to which to apply the authorization policy. The authorization policy defines the enforcement rules. The linkage policy associates the filter policy with an authorization policy. The usage policy provides feedback to the PDP according to what the PEP has monitored, recorded and reported to the PDP via an accounting type report. Rawlins et al. Expires May 2001 [Page 5] Internet Draft RSVP-PCC-PIB November 2000 A single set of policy authorization rules or usage policies can be associated with a number of filter policies. A filter policy is used to uniquely identify a flow. The basic kinds of policies are capability, PPC linkage and authorization. It would be useful in the future to consider policies that define the monitoring, recording, and reporting of usage information by the PEP to the PDP. These would provide feedback to the PDP on which it could base future configuration decisions. 3.1 Capabilities Table - policyControlCapsTable This table provides a single instance describing the deviceÆs policy model or mode. There are three modes. There is LDP mode where the local policy criteria are the basis of the policy control and then the PEP outsources a confirmation request using an LDPDecison object. Another mode is where the local policy criteria are checked, and if absent; the request is outsourced to the PDP. And a third mode is where only the provisioned policy criteria are used for the decision. No outsourcing is associated with this third mode. 3.2 PPC Linkage Table - pccLinkTable This table defines the association between the filter policy and the authorization policy. The PPC Linkage Class references the filter PRID as well as the PRID of the authorization policy class. It links the two instances. (The PRID is the Object Identifier constructed with the PRC and the instance id as the last sub-identifier.) Note that the same filter may have multiple authorization policies. For example a filter may have a Traffic Specifier policy, a Rate Specifier policy and Preemption policy that should be used as policy criteria for determining if the flow is allowed. There is future work needed to explore the optimization of the association of filters with authorization policies. 3.3 Authorization Policy Tables The Authorization tables contain the enforcement policy classes that determine whether the RSVP reservation is allowed. These policy classes describe the Integrated Services Controlled Load and Guaranteed Services, [2210,2211,2212,2215], the identity authorization user and authorization application policies [2752], and the preemption policies [2751.] The policy classes included in this group are: 1) Traffic Specifier (Tspec) Policies Defines the transmission rate of the traffic flow. 2) RSPEC Limits Rawlins et al. Expires May 2001 [Page 6] Internet Draft RSVP-PCC-PIB November 2000 Defines the requested service rate from the network related with Guaranteed Services. 3) Identification Authentication Data Policy Elements Defines means to securely identify the owner or application making the reservation request. 4) Priority Preemption Policy Elements Defines the relative order of importance of the requested flow and permits the preemption of lesser important flows to allow higher priority flows admission. 3.5 Example Authorization policies are defined in terms of TRAFFIC SPECIFIER and RSPEC characteristics as well as Integrated Services type i.e. Controlled Load or Guaranteed Services. Additional criteria such as Policy Authentication and Priority Preemption can also be specified. An example set of policy control criteria is as follows. The SenderTemplate and Filterspec are compared against the policy control criteria filters by the PEP. The filter is associated with a set of authorization rules with the linkage policies. For example, policy control criteria could establish authorization for the Gold and Silver VoIP services. The Gold VoIP could be defined as allowing a guaranteed service request, within a traffic specifier and rspec limit, with a high preemption priority and high preemption defending priority. A Silver VoIP could be defined as granting a controlled load service request, within a traffic specifier and rspec limit, with a moderate preemption priority and low preemption defending priority. 4 The RSVP Policy Control Criteria PIB Module RSVP-PCC-PIB PIB-DEFINITIONS ::= BEGIN IMPORTS Unsigned32, Unsigned64, Integer32, MODULE-IDENTITY FROM COPS-PR-SPPI InstanceID, ReferenceID, Prid, TagID FROM COPS-PR-SPPI-TC InetAddress, InetAddressType FROM SNMPv2-TC Role, RoleCombination FROM POLICY-DEVICE-AUX-MIB OBJECT-GROUP FROM SNMPv2-CONF MessageSize, BitRate, BurstSize FROM INTEGRATED-SERVICES-MIB FrwkIpFilterTable FROM FRAMEWORK-PIB; Rawlins et al. Expires May 2001 [Page 7] Internet Draft RSVP-PCC-PIB November 2000 RsvpPccPib MODULE-IDENTITY SUBJECT-CATEGORY { RSVP-PCC(tbd) } LAST-UPDATED "200011131600Z" ORGANIZATION "IETF-RAP-WG" CONTACT-INFO " Diana Rawlins 901 International Parkway Richardson, TX 75081 Email: Diana.Rawlins@wcom.com Phone +1 972 729 1044 Lei Yao 22001 Loudoun County Parkway Ashburn, VA 20147 Email: Lei.yao@wcom.com Phone: +1 703 886 1830 Richard McClain 901 International Parkway Richardson, TX 75081 Email: Richard.McClain@wcom.com Phone: +1 972 729 1094 Amol Kulkarni JF3-206 2111 NE 25th Ave Hillsboro, Oregon 97124 Email: amol.kulkarni@intel.com Phone: +1 503 712 1168 " DESCRIPTION "A PIB module containing the policy control classes that are required for support of pushing policy control from the PDP to PEPs." ::= { tbd } -- -- The root OID for PRCs in the RSVP Policy Control Criteria PIB -- rsvpPccBaseClasses OBJECT IDENTIFIER ::= { RsvpPccPib 1 } -- -- Textual Conventions -- -- -- Policy Control Capabilities Table -- policyControlCapsTable OBJECT-TYPE Rawlins et al. Expires May 2001 [Page 8] Internet Draft RSVP-PCC-PIB November 2000 SYNTAX SEQUENCE OF PolicyControlCapsEntry PIB-ACCESS notify,3 STATUS current DESCRIPTION " The policy control capability in terms of the policy control mode supported by the device." ::= { rsvpPccBaseClasses 1 } policyControlCapsEntry OBJECT-TYPE SYNTAX PolicyControlCapsEntry STATUS current DESCRIPTION " The instance defining the policy control mode." PIB-INDEX { policyControlCapsPccId } UNIQUENESS { policyControlCapsPccId } ::= { policyControlCapsTable 1 } PolicyControlCapsEntry ::= SEQUENCE { policyControlCapsPccId InstanceId, policyControlCapsMode INTEGER } policyControlCapsPccId OBJECT-TYPE SYNTAX InstanceId STATUS current DESCRIPTION "An arbitrary integer index that uniquely identifies an instance of the PolicyControlCaps class." ::= { policyControlCapsEntry 1 } policyControlCapsMode OBJECT-TYPE SYNTAX INTEGER { CONFIRM_ALL(1), LOCAL_IF_AVAILABLE(2), LOCAL_ONLY(3) } STATUS current DESCRIPTION "The policy criteria control mode of the device. The valid enumeration values are: (1)Local Decision Policy which makes decision and then outsources confirmation to the PDP (2)local control and if no policy control criteria is available locally, then outsource decision to PDP (3)local policy control only." ::= { policyControlCapsEntry 2} Rawlins et al. Expires May 2001 [Page 9] Internet Draft RSVP-PCC-PIB November 2000 -- -- Policy Control Criteria Linkage Table -- pccLinkTable OBJECT-TYPE SYNTAX SEQUENCE OF PccLinkEntry PIB-ACCESS install-notify,4 STATUS current DESCRIPTION " This table defines the association between the filter, frwkIpFilterTable instance and the authorization policy instance" ::= { rsvpPccBaseClasses 2 } pccLinkEntry OBJECT-TYPE SYNTAX PccLinkEntry STATUS current DESCRIPTION " An entry links the filter and the authorization policy." PIB-INDEX { pccLinkPccId } UNIQUENESS { pccLinkPccId, pccLinkFilterRefId, pccLinkPolicyPrid } ::= { pccLinkTable 1 } PccLinkEntry::= SEQUENCE { pccLinkPccId InstanceId, pccLinkFilterRefId ReferenceId, pccLinkPolicyPrid Prid } pccLinkPccId OBJECT-TYPE SYNTAX InstanceId STATUS current DESCRIPTION " An arbitrary integer index that uniquely identifies an instance of the PccLink class. " ::= { pccLinkEntry 1 } pccLinkFilterRefId OBJECT-TYPE SYNTAX ReferenceId STATUS current DESCRIPTION " References an instance of FrwkIPFilterTable. " Rawlins et al. Expires May 2001 [Page 10] Internet Draft RSVP-PCC-PIB November 2000 ::= { pccLinkEntry 2 } pccLinkPolicy OBJECT-TYPE SYNTAX Prid STATUS current DESCRIPTION " Specifies the specific PRID of the PRC and instance of authorization policy associated with this filter." ::= { pccLinkEntry 3 } -- -- Traffic Specifier Policies Table -- trafficSpecifierPolicyTable OBJECT-TYPE SYNTAX SEQUENCE OF TrafficSpecifierPolicyEntry PIB-ACCESS install-notify,6 STATUS current DESCRIPTION "This table defines the Traffic specifier policy control characteristics that can be used to determine SENDER_TSPEC, Controlled-Load or Guaranteed Services policies." ::= { rsvpPccBaseClasses 3 } trafficSpecifierPolicyEntry OBJECT-TYPE SYNTAX TrafficSpecifierPolicyEntry STATUS current DESCRIPTION " An entry describes a specific limits for a T-SPEC policy. " PIB-INDEX { trafficSpecifierPolicyId } UNIQUENESS {trafficSpecifierPolicyId, trafficSpecifierPOlicyBucketRate, trafficSpecifierPolicyBucketSize, trafficSpecifierPolicyPeakRate, trafficSpecifierPolicyMinPolicedUnit, trafficSpecifierPolicyMaxPacketSize } ::= { trafficSpecifierPoliciesTable 1 } TrafficSpecifierPolicyEntry ::= SEQUENCE { trafficSpecifierPolicyId InstanceId, trafficSpecifierPolicyBucketRate BitRate, trafficSpecifierPolicyBucketSize Unsigned32, trafficSpecifierPolicyPeakRate BurstRate, trafficSpecifierPolicyMinPolicedUnit MessageSize, trafficSpecifierPolicyMaxPacketSize MessageSize Rawlins et al. Expires May 2001 [Page 11] Internet Draft RSVP-PCC-PIB November 2000 } trafficSpecifierPolicyId OBJECT-TYPE SYNTAX InstanceId STATUS current DESCRIPTION "An arbitrary integer index that uniquely identifies an instance of the TrafficSpecifierPolicy class." ::= { trafficSpecifierPolicyEntry 1 } trafficSpecifierPolicyBucketRate OBJECT-TYPE SYNTAX BitRate STATUS current DESCRIPTION " ærÆ bytes per second, the token bucket rate. " ::= { trafficSpecifierPolicyEntry 2 } trafficSpecifierPolicyBucketSize OBJECT-TYPE SYNTAX Unsigned32 STATUS current DESCRIPTION " æbÆ bucket depth in bytes, the token bucket size. " ::= { trafficSpecifierPolicyEntry 3 } trafficSpecifierPolicyPeakRate OBJECT-TYPE SYNTAX BurstSize STATUS current DESCRIPTION " æpÆ peak traffic data rate in bytes. " ::= { trafficSpecifierPolicyEntry 4 } trafficSpecifierPolicyMinPolicedUnit OBJECT-TYPE SYNTAX MessageSize STATUS current DESCRIPTION " æmÆ minimum policed unit û size in bytes of application data and all IP and greater level (UDP, RTP, TCP, etc.) headers. " ::= { trafficSpecifierPolicyEntry 5 } trafficSpecifierPolicyMaxPacketSize OBJECT-TYPE Rawlins et al. Expires May 2001 [Page 12] Internet Draft RSVP-PCC-PIB November 2000 SYNTAX MessageSize STATUS current DESCRIPTION " æMÆ maximum packet size û biggest packet that conforms to traffic specification. " ::= { trafficSpecifierPolicyEntry 6 } -- -- RSPEC Limits Table -- rspecLimitsTable OBJECT-TYPE SYNTAX SEQUENCE OF RspecLimitsEntry PIB-ACCESS install-notify,1 STATUS current DESCRIPTION "This table defines the RSPEC policy control characteristics that are applied to Integrated Services Guaranteed Service." ::= { rsvpPccBaseClasses 6 } rspecLimitsEntry OBJECT-TYPE SYNTAX RspecLimitsEntry STATUS current DESCRIPTION " An entry that defines specific Rate and Slack limits for a Guaranteed Service resource request " EXTENDS { trafficSpecifierPolicyTable } UNIQUENESS { rspecLimitRate, rspecLimitsSlackTerm } ::= { rspecLimitsTable 1 } RspecLimitsEntry ::= SEQUENCE { rspecLimitsRate BitRate, rspecLimitsSlackTerm Unsigned32 } rspecLimitsRate OBJECT-TYPE SYNTAX BitRate STATUS current DESCRIPTION " æRÆ - Rate. Must be greater than or equal to ærÆ rate for the flow " ::= { rspecLimitsEntry 1 } Rawlins et al. Expires May 2001 [Page 13] Internet Draft RSVP-PCC-PIB November 2000 rspecLimitsSlackTerm OBJECT-TYPE SYNTAX Unsigned32 STATUS current DESCRIPTION " æSÆ û Slack Term. Defines in microseconds the difference between desired delay and the delay attained with the reservation level of R" ::= { rspecLimitsEntry 2 } -- -- Authentication Data Policy Element Table -- authDataPolicyElementTable OBJECT-TYPE SYNTAX SEQUENCE OF AuthDataPolicyElementEntry PIB-ACCESS install-notify,6 STATUS current DESCRIPTION "This table specifies policy control to identify and authenticate the owner making resource request." ::= { rsvpPccBaseClasses 7 } authDataPolicyElementEntry OBJECT-TYPE SYNTAX AuthDataPolicyElementEntry STATUS current DESCRIPTION " An entry defines the specific authentication identify used to grant permission for the reservation request." PIB-INDEX { authDataPolicyElementPccId } UNIQUENESS { authDataPolicyElementPccId, authDataPolicyElementPolicySetId, authDataPolicyElementPolicyIdentity, authDataPolicyElementPolicyAuthAttrType, authDataPolicyElementPolicyAuthAttrSubType } ::= { authDataPolicyElementTable 1 } AuthDataPolicyElementEntry::= SEQUENCE { AuthDataPolicyElementPccId InstanceID, AuthDataPolicyElementPolicySetId TagID, authDataPolicyElementPolicyIdentity INTEGER, authDataPolicyElementPolicyAuthAttrType INTEGER, authDataPolicyElementPolicyAuthAttrSubType INTEGER } Rawlins et al. Expires May 2001 [Page 14] Internet Draft RSVP-PCC-PIB November 2000 authDataPolicyElementPccId OBJECT-TYPE SYNTAX InstanceID STATUS current DESCRIPTION "An arbitrary integer index that uniquely identifies an instance of the AuthDataPolicyElement class." ::= { authDataPolicyElementEntry 1 } authDataPolicyElementPolicySetId OBJECT-TYPE SYNTAX TagID STATUS current DESCRIPTION " This associates a set of authentication attributes." ::= { authDataPolicyElementEntry 2 } authDataPolicyElementPolicyIdentity OBJECT-TYPE SYNTAX INTEGER{ AUTH_USER(1), AUTH_APP(2) } STATUS current DESCRIPTION " Identifies the Policy Set Element via enumeration values: (2) AUTH_USER (3) AUTH_APP " ::= { authDataPolicyElementEntry 3 } authDataPolicyElementPolicyAuthAttrType OBJECT-TYPE SYNTAX INTEGER { POLICY_LOCATOR(1), CREDENTIAL(2), DIGITAL_SIGNATURE(3), POLICY_ERROR_object(4) } STATUS current DESCRIPTION " Enumeration values: (1) POLICY_LOCATOR (valid for both AUTH_USER and AUTH_APP) (2) CREDENTIAL (valid for both AUTH_USER and AUTH_APP) (3) DIGITAL_SIGNATURE (4) POLICY_ERROR_OBJECT " ::= { authDataPolicyElementEntry 4 } Rawlins et al. Expires May 2001 [Page 15] Internet Draft RSVP-PCC-PIB November 2000 authDataPolicyElementPolicyAuthAttrSubType OBJECT-TYPE SYNTAX INTEGER { NO_TYPE(0), ASCII_DN(1), UNICODE_DN(2), ASCII_DN_ENCRYPT(3), UNICODE_DN_ENCRYPT(4), ASCII_ID(5), UNICODE_ID(6), KERBEROS_TKT(7), X509_CERT(8), PGP_CERT(9), NO_MORE_INFO(10), UNSUPPORTED_CRED_TYPE(11), INSUFFICIENT_PRIVS(12), EXPIRED_CREDENTIAL(13), IDENTITY_CHANGED(14) } STATUS current DESCRIPTION " For POLICY_LOCATOR valid enumeration values are: (1) ASCII_DN (valid for both AUTH_USER and AUTH_APP) (2) UNICODE_DN (valid for both AUTH_USER and AUTH_APP) (3) ASCII_DN_ENCRYPT (4) UNICODE_DN_ENCRYPT For CREDENTIAL valid enumeration values are: (5) ASCII_ID (valid for both AUTH_USER and AUTH_APP) (6) UNICODE_ID (valid for both AUTH_USER and AUTH_APP) (7) KERBEROS_TKT (8) X509_V3_CERT (9) PGP_CERT For DIGITAL_SIGNATURE: Sub-Type set to 0 For POLICY_ERROR_OBJECT valid enumeration values are: (10) ERROR_NO_MORE_INFO (11) UNSUPPORTED_CREDENTIAL_TYPE (12) INSUFFICIENT_PRIVILEGES (13) EXPIRED_CREDENTIAL (14) IDENTITY_CHANGED " ::= { authDataPolicyElementEntry 5 } -- Rawlins et al. Expires May 2001 [Page 16] Internet Draft RSVP-PCC-PIB November 2000 -- Priority Preemption Policy Element Table -- priorityPreemptionPolicyElementTable OBJECT-TYPE SYNTAX SEQUENCE OF PriorityPreemptionPolicyElementEntry PIB-ACCESS install-notify,5 STATUS current DESCRIPTION "This table defines policy control for priority preemption." ::= { rsvpPccBaseClasses 8 } priorityPreemptionPolicyElementEntry OBJECT-TYPE SYNTAX PriorityPreemptionPolicyElementEntry STATUS current DESCRIPTION " An entry defines the specific preemption priority to admit the flow and the defending priority. " PIB-INDEX { priorityPreemptionPolicyElementPccId } UNIQUENESS { priorityPreemptionPolicyElementPccId, priorityPreemptionPolicyElementMergeStrategy, priorityPreemptionPolicyElementPreemptionPriority, priorityPreemptionPolicyElementDefendingPriority } ::= { priorityPreemptionPolicyElementTable 1 } PriorityPreemptionPolicyElementEntry ::= SEQUENCE { priorityPreemptionPolicyElementPccId InstanceId, priorityPreemptionPolicyElementMergeStrategy INTEGER, priorityPreemptionPolicyElementPreemptionPriority INTEGER, priorityPreemptionPolicyElementDefendingPriority INTEGER } priorityPreemptionPolicyElementPccId OBJECT-TYPE SYNTAX InstanceId STATUS current DESCRIPTION "An arbitrary integer index that uniquely identifies an instance of the PriorityPreemptionPolicyElement class." ::= { priorityPreemptionPolicyElementEntry 1 } priorityPreemptionPolicyElementMergeStrategy OBJECT-TYPE SYNTAX INTEGER { HIGHEST_QOS(1), HIGHEST_PRIORITY(2), Rawlins et al. Expires May 2001 [Page 17] Internet Draft RSVP-PCC-PIB November 2000 ERROR_ON_MERGE(3) } STATUS current DESCRIPTION " Defines the merging strategy for the flow. The Enum values are: (1) take priority of highest QoS (2) take highest priority (3) force an error on heterogeneous merge" ::= { priorityPreemptionPolicyElementEntry 2 } priorityPreemptionPolicyElementPreemptionPriority OBJECT-TYPE SYNTAX INTEGER STATUS current DESCRIPTION " Defines the value of the new reservation that is compared against the defending priorities of existing flows. A higher value represents a higher priority." ::= { priorityPreemptionPolicyElementEntry 3 } priorityPreemptionPolicyElementDefendingPriority OBJECT-TYPE SYNTAX INTEGER STATUS current DESCRIPTION " The value defined for an existing flow to defend its priority against a new reservation seeking admission. The higher value represents higher priority." ::= { priorityPreemptionPolicyElementEntry 4 } END 5 Security Considerations "..The use of IPSEC between the PDP and the PEP, as described in [2748], provides the necessary protection against security threats. However, even if the network itself is secure, there is no control as to who on the secure network is allowed to "Install/Notify" (read/change/create/delete) the PRIs in this PIB. It is then a customer/user responsibility to ensure that the PEP/PDP giving access to an instance of this PIB, is properly configured to give access to the PRIs only to those principals (users) that have legitimate rights to indeed "Install" or "Notify" (change/create/ delete) themà" [POLFRWK] 6 Acknowledgements Rawlins et al. Expires May 2001 [Page 18] Internet Draft RSVP-PCC-PIB November 2000 The authors would like to thank Russell Fenger of Intel for his contribution to this document. 7 Authors Addresses Diana Rawlins 901 International Parkway Richardson, TX 75081 Diana.Rawlins@wcom.com Lei Yao 22001 Loudoun County Parkway Ashburn, VA 20147 Lei.yao@wcom.com Richard McClain 901 International Parkway Richardson, TX 75081 Richard.McClain@wcom.com Amol Kulkarni JF3-206 2111 NE 25th Ave Hillsboro, Oregon 97124 amol.kulkarni@intel.com 8 References [2748] 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-05.txt, October 2000. [SPPI] K. McCloghrie, et.al., "Structure of Policy Provisioning Information," draft-ietf-rap-sppi-02.txt, October 2000. [POLFRWK] M. Fine, K. McCloghrie, J. Seligson, K. Chan, S. Hahn, A. Smith, F. Reichmeyer "Framework Policy Information Base", Internet Draft , November 2000 [2749] Herzog, S., Boyle J., Cohen, R., Durham, D., Rajan, R., Sastry, A., "COPS usage for RSVP" RFC 2749, January 2000 [2750] Herzog, S., "COPS Extensions for Policy Control" RFC 2750, January 2000. [2751] Herzog, S., "Signal Priority Preemption Policy Element" RFC 2751, January 2000. Rawlins et al. Expires May 2001 [Page 19] Internet Draft RSVP-PCC-PIB November 2000 [2752] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T. Herzog, S. "Identity Representation for RSVP" RFC 2752, January 2000. [2753] Yavatkar, R., Pendarakis, D., Guerin, R., "A Framework for Policy-based Admission Control" RFC 2753, January 2000. [2872] Bernet, Y., Pabbati, R., "Application and Sub Application Identity Policy Element for Use with RSVP" RFC 2872, June 2000. [2205] Braden, R., Zhang, L., Berson, S., Herzog, S., Jamin, S., "Resource ReSerVation Protocol (RSVP)" RFC2205, September 1997. [2210] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC2210, September 1997. [2211] Wroclawski, J., "Specification of the Controlled-Load Network Element Service", RFC2211, September 1997. [2212] Shenker, S., Partridge, C., Guerin, R., "Specification of Guaranteed Quality of Service", RFC2212, September 1997. [2215] Shenker, S., Wroclawski, J.," General Characterization Parameters for Integrated Service Network Elements", RFC2215, September 1997. Rawlins et al. Expires May 2001 [Page 20]