INTERNET-DRAFT Andreas Polyrakis Resource Allocation Working Group (RAP) University of Toronto Intended Category: Standards Track Raouf Boutaba Expires: October, 2001 University of Waterloo The Meta-Policy Information Base (M-PIB) draft-polyrakis-mpib-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". 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. R.Boutaba, A.Polyrakis Internet-Draft, expires Oct.2001 [page 1] The Meta-Policy Information Base April 2001 Abstract This document introduces the concept of COPS-PR meta-policies and defines the Meta-Policy Information Base. The meta-policy PIB does not introduce a new policing area. On the contrary, it defines some provisioning classes that can be used by all other PIBs, in order to add meta-policing functionality into them. The meta-policy PIB, like every PIB, stores policing information that controls some policing mechanisms of the device. However, unlike other PIBs, the policing mechanism controlled by the meta-policy PRCs is the PIB itself. The data maintained by these PRCs implement policies that control other policies, this is why they are called meta-policies. Meta-policies is an attempt to push intelligence towards the COPS-PR PEPs and overcome the rigidity of their PIBs. Through meta-policies, more policing information and functionality can be pushed towards the PEP, less interaction with the PDP is necessary and less network and PDP resources are consumed. The PEP is more independent and it can bear longer PDP absences. 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]. Glossary - Terminology This document follows the terminology of [P-TERM]. However, the most commonly used terms are cited again here: PDP Policy Decision Point. PEP Policy Enforcement Point. PRC Provisioning Class. See [COPS-PR]. PRI Provisioning Instance. See [COPS-PR]. PIB Policy Information Base. See [COPS-PR]. PRID Provisioning Instance Identifier. Uniquely identifies an instance of a PRC. See [COPS-PR]. R.Boutaba, A.Polyrakis Internet-Draft, expires Oct.2001 [page 2] The Meta-Policy Information Base April 2001 Table of Contents Status of this Memo...............................................1 Abstract..........................................................2 Conventions used in this document.................................2 Glossary - Terminology............................................2 Table of Contents.................................................3 1.Introduction....................................................4 1.1.PIB Limitations...............................................4 1.2.The concept of Meta-Policies..................................4 1.3.Why Meta-Policies?............................................5 2.Formal Definition...............................................6 2.1.Meta-Policies.................................................6 2.2.Parameters....................................................7 3.Representation of Meta-Policies in the PIB......................7 3.1.Meta-policies.................................................7 3.2.Conditions....................................................7 3.3.Actions.......................................................9 3.4.Parameters....................................................9 4.Structure of the M-PIB..........................................9 4.1.The Capabilities Group........................................9 4.2.The Meta-Policy Group.........................................9 4.3.The Condition Group..........................................10 4.4.The Actions Group............................................11 4.5.The Parameter Group..........................................11 5.Definition of the Meta-Policy PIB..............................11 AuthorsÆ Information.............................................28 References.......................................................28 Appendix A û Sample XML DTD for encoding conditions..............30 Full Copyright Statement.........................................31 R.Boutaba, A.Polyrakis Internet-Draft, expires Oct.2001 [page 3] The Meta-Policy Information Base April 2001 1. Introduction 1.1. PIB Limitations PIBs are rigid structures. The PIB of a device follows specific standards and can only store specific types of policies. Several policies that could be processed entirely at the PEP level may need to be partially processed by the PDP. For example, a PEP that implements a small PIB that performs filtering according to the IP/Mask/Port of the source/destination of the packets cannot implement the policy ôbetween 5pm and 8pm do not allow traffic from IP Xö, even if a clock exists on the device. In this case, the PDP partially evaluates the conditions of the policy and installs, according to the time, the appropriate filter in the PIB of the PEP. Obviously, it would be more efficient if the involvement of the PDP had been avoided and the entire policy had been processed entirely at the PEP level. A second observation is that the PDP may need to send the same or similar commands to the PDP when the same network events occur. For example, suppose that there is a policy: ôgive high priority to administratorsö. If an administrator logs on to a workstation and after a while to another one, the PDP will need to send similar commands to the PEP. Or, each time congestion is detected in the network, the PDP may need to modify the contents of the PIB to reflect similar policies. The latter limitation has been identified and has been partially tackled in the framework PIB [FR-PIB]: The section ôMultiple PIB instancesö describes how the PDP can activate, with a simple command, different instances of the same PIB that relate to different network states. 1.2. The concept of Meta-Policies Inspired by the previous, this document describes how the same can be done in smaller portions of the PIB, i.e., how the PDP can send in advance sets of commands that modify the PIB, which will be activated with simple PDP commands. Moreover, this document describes how the PDP can also download directions to the PEP on how to perform the activation of these sets by itself, independently of the PDP, if this is considered efficient or desirable. This additional functionality is implemented through some extra PRCs that supplement and control the PIB of the device. Data on these PRCs control the data (policies) of the entire PIB; this is why the policies implemented in these classes are called ômeta-policiesö. Meta-policies are simple rules that monitor some events, and according to their values install or remove PRIs from the PIB. Notice that, according to the previous, meta-policies have in principle the same functionality with the PDP that controls the R.Boutaba, A.Polyrakis Internet-Draft, expires Oct.2001 [page 4] The Meta-Policy Information Base April 2001 device. Indeed, meta-policies attempt to push intelligence and PDP functionality towards the PEP. However, this does not oppose to the requirement that the PEP must always obey to the PDP, because meta- policies are rules produced by the PDP, hence the PDP ultimately controls the exact behavior of the PEP. As mentioned before, meta-policies monitor some events and perform some actions. However, this does not imply that all monitoring has to be performed by the PEP. The PDP still maintains the overall picture of the network and informs the PEP of global events. However, several events can be monitored by the PEP itself. Such events may be local events that derive from the MIB (or even the PIB) of the device. Alternatively, the PEP may get such information from a third network service or server, e.g., time service, authentication service, etc. (notice that this does not reduce the scalability of the model: again, N PEPs connect to 1 server). Depending on the values of the network events, meta-policies modify the PIB of the device. Each meta-policy is associated with a combination of events; when these events occur, the meta-policy is activated and some PRIs are installed into the PIB. These PRIs are uninstalled when these events no longer apply. The actions that a meta-policy takes are predetermined by the PDP. In order to do so, the PDP must associate with these actions the events that reflect such network state that will ensure that these actions will not be conflicting with any other installed actions, or that the policies formed in the PIB are invalid or incorrect. Also, since two valid meta-policies may be conflicting under certain circumstances, the PDP must provide some relative priority order between such meta- policies, which will allow the PEP to take the correct decision. Notice that meta-policies do not prohibit the PDP from controlling the entire PIB of the device. On the contrary, the PDP has two ways to modify the PIB: Either directly, by installing or removing PRIs, or indirectly, by installing meta-policies that install or remove these PRIs, when appropriate. Of course, meta-policies introduce extra complexity at the PDP, since it also has to ensure that PRIs installed directly cannot conflict with decisions taken by any installed meta-policy. 1.3. Why Meta-Policies? Meta-policies push some of the PDP functionality towards the PEP. This approach has several advantages: 1. The PDP is relieved from some of the policy processing. Since the global network policies seldom change, meta-policies are usually generated once and sent to the PEP. The PDP does not have to re- generate similar COPS-PR commands each time that the network conditions change. 2. Less network resources are consumed. Instead of sending whole policies, the PDP can activate the pre-installed meta-policies by R.Boutaba, A.Polyrakis Internet-Draft, expires Oct.2001 [page 5] The Meta-Policy Information Base April 2001 communicating network events. Also, the PEPs can be programmed to monitor local events, which means that these events do not need to be communicated to the PDP, and then back to the PEP. 3. The PEPs become more independent, since they are able to take more decisions, according to various network events. Thus, they can operate correctly during larger PDP absences, and they are less affected by situations such as congestion, high network delays, packet loss and PDP overload. 4. The fact that the behavior of the PEPs can be controlled with smaller messages (network events instead of whole policies) makes the model more robust in erroneous network situations, such as congestion and high packet loss. In general, meta-policies contribute towards the scalability, distribution, robustness and fault-tolerance of the COPS-PR model. Note that meta-policies allow the PDP to push towards the PEP as little intelligence as a few simple meta-policies or as much as integrating almost the entire PDP functionality into it. 2. Formal Definition 2.1. Meta-Policies We define a meta-policy as a rule of the form: if (condition) then {actions} where ôconditionö is a logical expression, e.g., ô(C>80%) and (D=true)ö, and "actions" is a set of commands that install PRIs into the PIB. Since the actions encode a specific policy, this rule is a rule on how policies are enforced; this is why it is called ômeta-policyö. Each meta-policy is generated for a specific PEP, according to its capabilities, limitations and the device on which it resides. The PEP evaluates the condition of each meta-policy, and when it evaluates true, it enforces the actions. When it becomes false, the PRIs are uninstalled. The key idea in meta-policies is that the PEP can store and process these meta-policies without knowing their exact semantics: The condition is treated as a logical expression; the actions, pre-generated by the PDP, just denote PRIs that must be installed, and this can be done by the PEP without knowing the high- level policy that these PRIs actually implement. In this way, the PEP can process any meta-policy, independently of its complexity and its meaning. R.Boutaba, A.Polyrakis Internet-Draft, expires Oct.2001 [page 6] The Meta-Policy Information Base April 2001 Both the condition and the actions may contain parameters (such as ôCongestionö or ôTimeö); the values for these parameters are either sent by the PDP or evaluated by the PEP, according to directions provided by the former. 2.2. Parameters The parameters are used in meta-policy conditions in order to determine when a meta-policy must be activated. Moreover, they are used by meta-policy actions in order to dynamically bind the network state within policies. For example, the meta-policy ôif (AdminLogged) then {give high priority to AdminIP}ö, contains the parameters AdminLogged and AdminIP. When installing a parameter, the PDP must specify an evaluation method for this parameter. For instance, the PEP can be directed to get a value for a parameter from the MIB or the PIB of the device. Alternatively, the PDP could provide the value for this parameter. However, other methods are also possible, depending on the capabilities of the device, such as to download and execute a script, use mobile agents, or get the desired information from some server or service. 3. Representation of Meta-Policies in the PIB 3.1. Meta-policies Each meta-policy is comprised of two parts: The ôconditionö and the ôactionsö. The ôconditionö is a logical expression that may be divided into simpler conditions. The ôactionsö is a group of PIB commands that install or remove PRIs. A meta-policy MUST always be associated with a condition, and it is expected to be associated with one or more actions (meta-policies without actions should normally occur only as the result of temporal deactivation of its actions). Since meta-policies may be conflicting, the relative priority between potentially conflicting meta-policies MUST be declared in the PIB. 3.2. Conditions The ôconditionö of a meta-policy is a logical expression that determines when the meta-policy must be activated. Each meta-policy must contain exactly one condition. The condition may consist other simpler conditions; and these conditions may similarly be comprised of even simpler conditions, etc. In this way, the condition is eventually decomposed in primitives that are logical expressions R.Boutaba, A.Polyrakis Internet-Draft, expires Oct.2001 [page 7] The Meta-Policy Information Base April 2001 (i.e., they evaluate true or false), but cannot be further decomposed (i.e., the expression X>Y). This document distinguishes two types of such primitives: Booleans and generic logical expressions. Booleans are a subset of the generic expressions, but due to their simplicity and commonality, they are treated separately. Such primitives are evaluated according to the value of a Boolean parameter. For instance, the condition (X>Y) && (!Congestion) && (WorkTime) is decomposed into three primitives: ôX>Yö, ôCongestionö and ôWorkTimeö. From these three primitives, only the last two are Booleans. Booleans MUST be supported by all meta-policy PIBs. Generic expressions contain all the other logical expressions that cannot be decomposed into simpler primitives. Examples of such primitives are ôX>Yö, ôIP matches X.Y.Z.Wö or ô8:00am < time < 5:00pm). Each PEP can only support specific types of such expressions (e.g., arithmetic), which are reported along with the other PEP capabilities to the PDP. The PDP can only sent to the PEP expressions that are supported by the latter. In order to encode and communicate such generic conditions, XML is used. The PEP supports some XML Document Type Definitions (DTDs), which describe the semantics of XML tags that can be used to described such an expression. For instance, a simple DTD that defines XML tags for encoding arithmetic expressions is presented in Appendix A. The PDP encodes the condition (if this is feasible) according to one of these DTDs, and sends it to the PEP, notifying it which DTD it chose. The PEP MUST be able to interpret any kind of expressions encoded according to the DTDs that it supports (with the exception of some limitations like the size of the XML document, etc, that it reports to the PDP in the REQ message). In this way, complex expressions can be communicated from the PDP to the PEP and be evaluated by the latter. Notice that each atom conditions should be parametric (it does not make sense to use constant conditions), the DTDs MUST provide a way to reference to the parameters that are installed in the PEP, through their identifiers. For example, suppose that the PDP needs to send to the PEP the expression A ôA+B>7ö. The PEP has reported that it supports the DTD of Appendix A. In this case, the expression will be sent as: 1 2 7 (Parameters ôAö and ôBö are mapped to the Parameter IDs 1 and 2, respectively) R.Boutaba, A.Polyrakis Internet-Draft, expires Oct.2001 [page 8] The Meta-Policy Information Base April 2001 Note that the XML-encoded expression does not describe how the parameters are evaluated. It only references the parameters that are used in order to evaluate this expression. 3.3. Actions The Actions of a meta-policy is a group of commands that install PRIs into the PIB. Each action MUST specify a target PRID that specifies a single PRI, and the value that will be installed into it. This value may be either a BER-encoded value, sent by the PDP, or the value of a parameter. 3.4. Parameters Two standard types of parameters are defined in this document. The first type is parameters the values of which are sent by the PDP. The second one is parameters that are evaluated by the MIB or the PIB of the PEP. However, the evaluation methods of the parameters can be extended (this is described later in this document). For instance, the vendors of a device with open node architecture (programmable/active device) may define a way through which scripts or code can be downloaded and executed in order to evaluate a parameter. 4. Structure of the M-PIB The Meta-Policy PIB consists of five groups. 4.1. The Capabilities Group This group contains a single table, the xmlDTDTable. This contains the XML DTDs that the PEP supports, for encoding expressions. Each row consists of an identifier and the DTD URL. The rows of this table are reported to the PDP in the REQ message. 4.2. The Meta-Policy Group This group contains three tables: the metaPolicyTable, the metaPolicyStatusTable and the metaPolicyPriorityTable. The metaPolicyTable is the table where meta-policies are constructed. Each row represents exactly one meta-policy. The meta- policy comprises an identifier, a name, a condition and an action tag. The condition is a reference to the conditionTable that we will describe later in this document, which encodes conditions. The action tag identifies a group of actions from the actionTable that must be executed when the meta-policy is activated. R.Boutaba, A.Polyrakis Internet-Draft, expires Oct.2001 [page 9] The Meta-Policy Information Base April 2001 The metaPolicyStatusTable is a table that AUGMENTS the previous table (this means that there is a 1-1 correspondence between the rows of these tables). Each row of this table reports whether the corresponding meta-policy is active, and whether it suppresses or it is suppressed by anoter meta-policy with higher priority. This table is used to report to the PDP the meta-policy status. This class, unlike the metaPolicy class, is only used to report the status of the meta-policies to the PDP and it cannot be modified by it. Finally, the metaPolicyPriorityTable is used by the PDP in order to report to the PEP conflicting meta-policies, and direct it how to resolve the conflict. Each row identifies two meta-policies, and defines which one has the higher priority. Rows with two active meta-policies MUST NOT exist in this table. 4.3. The Condition Group This group contains four tables: the conditionTable, the complexConditionTable, the booleanConditionTable and the generalConditionTable. The conditionTable is the base table of this group. Each row represents a logical expression. It consists of an identifier and an attribute that defines whether the condition should be logically reversed (i.e., whether its negation must be computed, instead). Rows of this table MUST always be associated with rows of an other table that extends the base one. Some (but not all) of the rows of this table are used in order to represent conditions of meta-policy. Other rows, though, can be used to break down a complex condition to simpler ones. In order to achieve that, the complexConditionTable is used. This table EXTENDS the base conditionTable. Each row consists of two references to the conditionTable, and an operator. The references reference two other logical conditions, and the operator defines a logical operation between these two conditions. In this way, the row in this table forms a more complex condition. Obviously, the PDP must not install rows that reference themselves, either explicitly or implicitly. The booleanConditionTable is a table that also extends the base table. Each row contains a reference to a parameter, which must be of type ôTrueValueö. The value of the condition is evaluated according to the value of this parameter. Finally, the generalConditionTable is used to allow conditions to be evaluated through more complex expressions. Each row consists of a reference to the xmlDTDtable and a string, which encodes in XML an expression. The reference to the xmlDTDtable defines the XML DTD that must be used in order to interpret this expression. The R.Boutaba, A.Polyrakis Internet-Draft, expires Oct.2001 [page 10] The Meta-Policy Information Base April 2001 expression encoded MUST be a logical expression, i.e., it MUST evaluate either true or false. 4.4. The Actions Group This group consists of three tables: the actionTable, the actionValueTable and the actionParametricValueTable. The actionTable is the base table for storing meta-policy actions. Each row contains a tag-reference attribute that groups the actions of a single meta-policy. Each row specifies the PRID of the PRI to be installed. The value of the PRI is determined either in the actionValueTable or the actionParametricValueTable. Both tables EXTEND the base one and provide the value that must be installed for the specific target PRID. The former provides a BER-encoded value, while the latter specifies a parameter, from where the value is evaluated. 4.5. The Parameter Group This group contains three tables: the parameterTable, the mibPibParameterTable and the PDPParameterTable. The parameterTable is the base table for representing conditions. Each row constist of an identifier, a name and an attribute that denotes the type of the parameter. Each row in this table must be associated with a row of a table that EXTENDS this one. The mibPibParameterTable is such a table. It defines a MIB or PIB identifier from where the parameter gets its value. Of course, this identifier must point to an existing variable. Each row also defines the frequency that this value will be updated. The pdpParameterTable also extends the base parameterTable. Each row of this table contains a single attribute that encodes, in BER, a single value. The PDP sends the values for this row. 5. Definition of the Meta-Policy PIB META-POLICY-PIB PIB-DEFINITIONS ::= BEGIN IMPORTS Unsigned32, timeticks, MODULE-IDENTITY, OBJECT-TYPE, InstanceId, ReferenceId FROM COPS-PR-SPPI TEXTUAL-CONVENTION R.Boutaba, A.Polyrakis Internet-Draft, expires Oct.2001 [page 11] The Meta-Policy Information Base April 2001 FROM SNMPv2-TC; metaPolicyPib MODULE-IDENTITY SUBJECT-CATEGORY { all } LAST-UPDATED "200104010000" ORGANIZATION "IETF" CONTACT-INFO " Andreas Polyrakis Dept. of Computer Science, University of Toronto, 10 King's College Road, Toronto, Ontario,M5S 3G4, Canada. e-mail: apolyr@cs.toronto.edu Phone: ++1 (416) 978-4837 Fax: ++1 (416) 978 1931 Raouf Boutaba Dept. of Computer Science, University of Waterloo, 200 University Avenue West, Waterloo, Ontario N2L 3G1, Canada e-mail: rboutaba@bbcr.uwaterloo.ca Phone: ++1 (519) 888 4567 ext.4820 Fax: ++1 (519) 885 1208" DESCRIPTION "The meta-policy PIB module. It contains the classes that are necessary for the provisioning of meta-policy related information. This module is applicable, but not mandatory, to all subject-categories" ::= { tbd } -- The root OID for PRCs in the Meta-Policy PIB --- --- Textual Conventions --- BERValue ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "A sequence of octets that encodes a value using BER. The suppoted BER types are (borrowed by SNMPv2): Type | BER identifier --------------------|---------------- INTEGER | 02 BIT STRING | 03 OCTET STRING | 04 NULL | 05 OBJECT IDENTIFIER | 06 IP ADDRESS | 40 COUNTER32 | 41 GAUGE32 | 42 TIMETICKS | 43 OPAQUE | 44 R.Boutaba, A.Polyrakis Internet-Draft, expires Oct.2001 [page 12] The Meta-Policy Information Base April 2001 By using this type, the PEP can store values for different types of parameters in the same class (PRC)." " SYNTAX OCTET STRING (SIZE (0..16)) XMLString ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "A string that contains a logical expression encoded using XML. The semantics of the XML tags are defined in special DTDs, which the PEP declares that supports." SYNTAX OCTET STRING (SIZE (0..1024)) --- --- End of Textual Conventions --- ----------------------------------------------- ----------------------------------------------- -- Meta-Policy Capabilities Group metaPolicyCapabilitiesClasses OBJECT IDENTIFIER ::= { metaPolicyPib 1 } --- --- Meta-Policy Capabilities Table --- xmlDTDTable OBJECT-TYPE SYNTAX SEQUENCE OF xmlDTDEntry PIB-ACCESS notify STATUS current DESCRIPTION "Each instance of this class specifies a PRC that identifies an XML DTD supported by the PEP for encoding logical expressions. If this class has no instances, then the PEP supports only expressions that are formed with boolean predicates and operators, and in this case the PDP MUST not attempt to install any XML-encoded expressions in the generalConditionTable." ::= { metaPolicyCapabilitiesClasses 1 } xmlDTDEntry OBJECT-TYPE SYNTAX MetaPolicyCapabilitiesEntry STATUS current DESCRIPTION "An instance of the xmlDTDTable class that determines an XML DTD that can be used to encode a logical expression" INDEX { metaPolicyPrid } ::= { metaPolicyTable 1 } XmlDTDEntry ::= SEQUENCE { R.Boutaba, A.Polyrakis Internet-Draft, expires Oct.2001 [page 13] The Meta-Policy Information Base April 2001 xmlDTDPrid InstanceId, xmlDTDURL SnmpAdminString } xmlDTDPrid OBJECT-TYPE SYNTAX InstanceId STATUS current DESCRIPTION "An arbitrary integer that uniquely identifies an instance of the xmlDTD class." ::= { xmlDTDEntry 1 } xmlDTDURL OBJECT-TYPE SYNTAX SnmpAdminString STATUS current DESCRIPTION "The XML DTD URL. A string that indicates the URL of an XML DTD that can be used for encoding expressions. These DTDs can be defined either by standardization organizations, such as IETF, or be vendor specific. When the PDP receives a URL that uniquely identifies such a DTD, it knows that it may encode expressions according to this DTD that the PEP will be able to evaluate." ::= { xmlDTDEntry 2 } --End of xmlDTDTable ----------------------------------------------- ----------------------------------------------- -- Base Meta-Policy Group metaPolicyClasses OBJECT IDENTIFIER ::= { metaPolicyPib 2 } --- --- Meta-Policy Table --- metaPolicyTable OBJECT-TYPE SYNTAX SEQUENCE OF metaPolicyEntry PIB-ACCESS INSTALL STATUS current DESCRIPTION "Each instance of this class specifies a PRC that represents a meta-policy. Each meta-policy, apart from a unique identifier and an optional name, it constists of a condition and a group of actions." ::= { metaPolicyClasses 1 } metaPolicyEntry OBJECT-TYPE SYNTAX MetaPolicyEntry STATUS current R.Boutaba, A.Polyrakis Internet-Draft, expires Oct.2001 [page 14] The Meta-Policy Information Base April 2001 DESCRIPTION "An instance of the metaPolicy Class that represents a meta-policy." INDEX { metaPolicyPrid } ::= { metaPolicyTable 1 } MetaPolicyEntry ::= SEQUENCE { metaPolicyPrid InstanceId, metaPolicyName SnmpAdminString, metaPolicyCondition ReferenceId, metaPolicyActions TagId } metaPolicyPrid OBJECT-TYPE SYNTAX InstanceId STATUS current DESCRIPTION "An arbitrary integer that uniquely identifies an instance of the metaPolicy class." ::= { metaPolicyEntry 1 } metaPolicyName OBJECT-TYPE SYNTAX SnmpAdminString STATUS current DESCRIPTION "A display string that represents the name of the meta-policy. It is reccomented that different meta-policies have different names. However, similar meta-policies may have the same name. Also, an empty string can be used as a name." ::= { metaPolicyEntry 2 } metaPolicyCondition OBJECT-TYPE SYNTAX ReferenceId PIB-REFERENCES contitionTable STATUS current DESCRIPTION "This attribute associates the specific meta-policy with a condition in the condition Class. The condition MUST exist when the meta-policy is installed. The meta-policy MUST always be assosiated with one condition (which means that the attribute can never be null/invalid." ::= { metaPolicyEntry 3 } metaPolicyActions OBJECT-TYPE SYNTAX TagId PIB-REFERENCES actionsTable STATUS current DESCRIPTION "A tag that maps this instance (meta-policy) to a group of actions in the actions Class. Although the tag should map to at least one action, there might be cases where a R.Boutaba, A.Polyrakis Internet-Draft, expires Oct.2001 [page 15] The Meta-Policy Information Base April 2001 meta-policy is associated to no actions. However such cases should be avoided and only be temporal." ::= { metaPolicyEntry 4 } --End of metaPolicyTable -- -- Meta-Policy Status Table -- metaPolicyStatusTable OBJECT-TYPE SYNTAX SEQUENCE OF metaPolicyStatusEntry PIB-ACCESS REPORT-ONLY STATUS current DESCRIPTION "This class augments the metaPolicy class. Each instance of this class defines a PRC that is used in order to report to the PDP the status of the meta-policies. Also, information form this table can be used as a parameter to another meta-policy, as an alternative way to ensure that two priorities cannot be activated at the same time." ::= { metaPolicyClasses 2 } metaPolicyStatusEntry OBJECT-TYPE SYNTAX MetaPolicyStatusEntry STATUS current DESCRIPTION "An instance of the metaPolicyStatus class that reports the status of the corresponding meta-policy in the metaPolicy class." AUGMENTS { metaPolicyEntry } ::= { metaPolicyStatusTable 1 } metaPolicyStatusEntry ::= SEQUENCE { metaPolicyActive TruthValue, metaPolicySuppressed TruthValue } metaPolicyActive OBJECT-TYPE SYNTAX TruthValue STATUS current DESCRIPTION "True while the meta-policy is active" ::= { metaPolicyStatusEntry 1 } metaPolicySuppress OBJECT-TYPE SYNTAX TruthValue STATUS current DESCRIPTION "If this meta-policy is prevented from being active by an other meta-policy (but its conditions are met), this attribute is set to true. R.Boutaba, A.Polyrakis Internet-Draft, expires Oct.2001 [page 16] The Meta-Policy Information Base April 2001 If this meta-policy prevents another meta-policy from being active, then this attribute is true. In other words: Active | Suppr.| -------------------------------- true | true | meta-policy active, | it suppresses another one true | false | meta-policy active, | does not suppress another one false | true | meta-policy inactive | because it is suppressed by another one false | false | meta-policy inactive because | the conditions are not met " ::= { metaPolicyStatusEntry 2 } --End of metaPolicyStatusTable --- --- Meta-Policy Priority Table --- metaPolicyPriorityTable OBJECT-TYPE SYNTAX SEQUENCE OF metaPolicyPriorityEntry PIB-ACCESS INSTALL STATUS current DESCRIPTION "This table reports conflicting meta-policies. When a meta-policy needs to be activated, the PEP MUST check if it is conflicting with another meta-policy, which is already active or needs to be activated at the same time. If so, the one that is referenced in the higherPriority attribute is activated and the other one is deactivated or remains deactivated. Similarly, when a meta-policy is deactivated, the PEP must check if a lower-priority meta-policy must now be activated." ::= { metaPolicyClasses 3 } metaPolicyPriorityEntry OBJECT-TYPE SYNTAX MetaPolicyPriorityEntry STATUS current DESCRIPTION "An instance of the metaPolicyPriority Class that identifies the relative priority between two meta-policies." INDEX { metaPolicyPrid } ::= { metaPolicyPriorityTable 1 } MetaPolicyPriorityEntry ::= SEQUENCE { metaPolicyPriorityPrid InstanceId, higherPriority ReferenceId, lowerPriority ReferenceId, R.Boutaba, A.Polyrakis Internet-Draft, expires Oct.2001 [page 17] The Meta-Policy Information Base April 2001 } metaPolicyPriorityPrid OBJECT-TYPE SYNTAX InstanceId STATUS current DESCRIPTION "An arbitrary integer that uniquely identifies an instance of the metaPolicyPriority class." ::= { metaPolicyPriorityEntry 1 } higherPriority OBJECT-TYPE SYNTAX ReferenceId PIB-REFERENCES metaPolicyTable STATUS current DESCRIPTION "This attribute references to the meta-policy that has higher priority than the one referenced by the lowerPriority attribute" ::= { metaPolicyPriorityEntry 2 } lowerPriority OBJECT-TYPE SYNTAX ReferenceId PIB-REFERENCES metaPolicyTable STATUS current DESCRIPTION "This attribute references to the meta-policy that has lower priority than the one referenced by the higherPriority attribute" ::= { metaPolicyPriorityEntry 3 } --End of metaPolicyPriorityTable ----------------------------------------------- ---------------------------------------------- -- Condition Group conditionClasses OBJECT IDENTIFIER ::= { metaPolicyPib 3 } -- -- Condition Table -- conditionTable OBJECT-TYPE SYNTAX SEQUENCE OF conditionEntry PIB-ACCESS INSTALL STATUS current DESCRIPTION "Each instance of this PRC represents a boolean expression. The conditionss of the meta-policies are instances of this class. However, if the condition of a meta-policy contains more than one predicate, the predicates are also instances of this PRC. R.Boutaba, A.Polyrakis Internet-Draft, expires Oct.2001 [page 18] The Meta-Policy Information Base April 2001 For instance, Suppose that we want to encode a condition A, which is evaluated as ( B OR C ), where B and C some other boolean expressions. In this case, A, B and C are instances of this PRC. All instances of this PRC MUST be extended by an instance of one of the rest PRCs of this group, in order to denote if this condition should be evaluated based on simpler conditions, if it is a boolean operand or an other logical expression." ::= { conditionClasses 1 } conditionEntry OBJECT-TYPE SYNTAX ConditionEntry STATUS current DESCRIPTION "An instance of the condition Class that defines a boolean condition" INDEX { conditionIndex } ::= { conditionTable 1 } ConditionEntry ::= SEQUENCE { conditionPrid InstanceId, conditionReverse Truevalue } conditionPrid OBJECT-TYPE SYNTAX InstanceId STATUS current DESCRIPTION "An arbitrary integer that uniquely identifies an instance of the condition class." ::= { conditionEntry 1 } conditionReverse OBJECT-TYPE SYNTAX Truevalue STATUS current DESCRIPTION "if true, the negation of the logical expression is evaluated, instead." ::= { conditionEntry 2 } -- END OF conditionTable -- -- Complex Condition Table -- complexConditionTable OBJECT-TYPE SYNTAX SEQUENCE OF complexConditionEntry PIB-ACCESS INSTALL STATUS current DESCRIPTION "Each instance of this PRC represents a complex R.Boutaba, A.Polyrakis Internet-Draft, expires Oct.2001 [page 19] The Meta-Policy Information Base April 2001 condition. It consists of two simplier conditions, and a logical operator that determines how the two terms are assosiated to compose the more complicated condition" ::= { conditionClasses 2 } complexConditionEntry OBJECT-TYPE SYNTAX ComplexConditionEntry STATUS current DESCRIPTION "An instance of the complexCondition class that breaks a complex condition into two simpler ones." EXTENDS { conditionTable } ::= { complexConditionTable } ComplexConditionEntry ::= SEQUENCE { operator Unsigned32, leftTerm ReferenceId, rightTerm ReferenceId } operator OBJECT-TYPE SYNTAX Unsigned32 { AND (0), OR (1) } STATUS current DESCRIPTION "The logical operator in the complex condition" ::= { complexConditionEntry 1 } leftTerm OBJECT-TYPE SYNTAX ReferenceId PIB-REFERENCES conditionTable STATUS current DESCRIPTION "A reference to the first simpler condition." ::= { complexConditionEntry 2 } rightTerm OBJECT-TYPE SYNTAX ReferenceId PIB-REFERENCES conditionTable STATUS current DESCRIPTION "A reference to the second simpler condition." ::= { complexConditionEntry 3 } -- END OF complexConditionTable -- -- Boolean Condition Expression Table -- R.Boutaba, A.Polyrakis Internet-Draft, expires Oct.2001 [page 20] The Meta-Policy Information Base April 2001 booleanConditionTable OBJECT-TYPE SYNTAX SEQUENCE OF booleanConditionEntry PIB-ACCESS INSTALL STATUS mandatory DESCRIPTION "Each instance of this class extends the condition class and represents a boolean parameter from which the condition is evaluated." ::= { metaPolicyPibClasses 2 } booleanConditionEntry OBJECT-TYPE SYNTAX BooleanConditionEntry STATUS mandatory DESCRIPTION "An instance of the booleanCondition class that defines the boolean parameter that gives values to the corresponding condition." EXTENDS { conditionTable } ::= { booleanConditionTable 1 } BooleanConditionEntry ::= SEQUENCE { parameterReference ReferenceId } parameterReference OBJECT-TYPE SYNTAX ReferenceId PIB-REFERENCES parameterTable STATUS current DESCRIPTION "A reference to a parameter from where the condition is evaluated. This condition MUST be of type boolean (Truthvalue)." ::= { booleanConditionEntry 1 } -- End of booleanConditionTable -- -- Generic Condition Table -- genericConditionTable OBJECT-TYPE SYNTAX SEQUENCE OF genericConditionEntry PIB-ACCESS INSTALL STATUS current DESCRIPTION "Each instance of this class extends the condition class and assosiates the corresponding condition with a complex logical expression, from where the condition is evaluated." ::= { conditionClasses 2 } genericConditionEntry OBJECT-TYPE SYNTAX GenericConditionEntry STATUS current DESCRIPTION R.Boutaba, A.Polyrakis Internet-Draft, expires Oct.2001 [page 21] The Meta-Policy Information Base April 2001 "An instance of the generalCondition class that defines the logical expression for the corresponding condition of the condition class." EXTENDS { generalConditionTable } ::= { conditionNumericalExpressionTable } GenericConditionEntry ::= SEQUENCE { xmlDTDRef ReferenceId, xmlCondition XMLString } xmlDTDRef OBJECT-TYPE SYNTAX ReferenceId PIB-REFERENCES xmlDTDTable STATUS current DESCRIPTION "A reference to the xmlDTD class that deternies which of the XML DTDs that this PEP supports is used in order to encode the expression." ::= { genericConditionEntry 1 } xmlCondition OBJECT-TYPE SYNTAX XMLString STATUS mandatory DESCRIPTION "The XML-encoded expression." ::={ genericConditionEntry 2 } -- End of genericConditionTable ----------------------------------------------- ----------------------------------------------- -- Actions Group actionClasses OBJECT IDENTIFIER ::= { metaPolicyPib 4 } -- -- Actions Table -- actionTable OBJECT-TYPE SYNTAX SEQUENCE of actionEntry PIB-ACCESS INSTALL STATUS current DESCRIPTION "Each instance of this class stores an action of a meta-policy." ::= { actionClasses 1 } actionEntry OBJECT-TYPE SYNTAX ActionEntry STATUS current R.Boutaba, A.Polyrakis Internet-Draft, expires Oct.2001 [page 22] The Meta-Policy Information Base April 2001 DESCRIPTION "An instance of the action class that stores an action of a meta-policy." INDEX { actionPrid } ::= { actionTable 1 } ActionEntry ::= SEQUENCE { actionPrid InstanceId, actionRefTag TagReferenceId, actionTargetPrid Prid } actionPrid OBJECT-TYPE SYNTAX InstanceId STATUS current DESCRIPTION "An arbitrary integer that uniquely identifies an instance of the action class." ::= { actionEntry 1 } actionRefTag OBJECT-TYPE SYNTAX TagReferenceId PIB-TAG metaPolicyActions STATUS current DESCRIPTION "An attribute that defines a Tag Group of actions. All actions with the same tag are grouped as the actions of a single meta-policy." ::={ actionEntry 2 } actionTargetPrid OBJECT-TYPE SYNTAX Prid STATUS current DESCRIPTION "The PRID of the PRI to be installed/updated. The PRID must point to a single PRI." ::={ actionEntry 3 } -- END OF actionsTable -- -- Action Value table -- actionValueTable OBJECT-TYPE SYNTAX SEQUENCE OF actionValueEntry PIB-ACCESS INSTALL STATUS current DESCRIPTION "Each instance of this class extends the corresponding instance of the action class. It provides the BER-encoded value that will be installed at the corresponding PRI." ::= { actionClasses 2 } R.Boutaba, A.Polyrakis Internet-Draft, expires Oct.2001 [page 23] The Meta-Policy Information Base April 2001 actionValueEntry OBJECT-TYPE SYNTAX ActionsValueEntry STATUS current DESCRIPTION "An insance of the actionValue class. It provides the value (encoded with BER) that will be installed at the PRI denoted by the corresponding instance of the action class." EXTENDS { actionEntry } ::= { actionValueTable 1 } ActionValueEntry ::= SEQUENCE { ActionValueEpd BERValue } actionValueEpd OBJECT-TYPE SYNTAX BERValue STATUS current DESCRIPTION "This attribute contains the BER-encoded value of the PRI to be installed/updated." ::={ actionValueEntry 1 } -- END OF actionValueTable -- -- Action Parametric Value Table -- actionParametricValueTable OBJECT-TYPE SYNTAX SEQUENCE OF actionParametricValueEntry PIB-ACCESS INSTALL STATUS current DESCRIPTION "Each instance of this class that extends the corresponding instance of the action class. It provides with the parametric value that will be installed at the corresponding PRI." ::= { actionClasses 3 } actionParametricValueEntry OBJECT-TYPE SYNTAX ActionParametricValueEntry STATUS current DESCRIPTION "An insance of the actionValue class. It provides with the parametric value that will be installed at the PRI denoted by the corresponding instance of the action class." EXTENDS { actionEntry } ::= { actionParametricValueTable 1 } R.Boutaba, A.Polyrakis Internet-Draft, expires Oct.2001 [page 24] The Meta-Policy Information Base April 2001 ActionParametricValueEntry ::= SEQUENCE { ParameterRef ReferenceId } ParameterRef OBJECT-TYPE SYNTAX ReferenceId PIB-REFERENCES parameterTable STATUS current DESCRIPTION "A reference to a the parameter, from where the value of the installed PRI should be obtained. Whenever the value of the parameter changes, the installed PRI MUST be updated." ::={ actionParametricValueEntry 1 } -- END OF actionParametricValueTable ----------------------------------------------- ----------------------------------------------- -- Parameter Group parameterClasses OBJECT IDENTIFIER ::= { metaPolicyPib 5 } - - Parameter Table - parameterTable OBJECT-TYPE SYNTAX SEQUENCE OF parameterEntry PIB-ACCESS INSTALL STATUS current DESCRIPTION "Each instance of this class defines a parameter that has been installed on the PEP. This class MUST be extended by a class that defines how the value of the parameter will be evaluated." ::= { parameterClasses 1} parameterEntry OBJECT-TYPE SYNTAX ParameterEntry STATUS current DESCRIPTION "An instance of the parameter class that installs a parameter into the PEP." INDEX { parameterPrid } ::= { parameterTable 1 } ParameterEntry ::= SEQUENCE { parameterPrid InstanceId, parameterName SNMPAdminString, parameterType Unsigned32 R.Boutaba, A.Polyrakis Internet-Draft, expires Oct.2001 [page 25] The Meta-Policy Information Base April 2001 } parameterPrid OBJECT-TYPE SYNTAX InstanceId STATUS current DESCRIPTION "An arbitrary integer that uniquely identifies an instance of the parameter class." ::= { parameterEntry 1 } parameterNameOBJECT-TYPE SYNTAX SNMPAdminString STATUS current DESCRIPTION "A string that represents the name of the parameter. It is reccomented that different parameter have different names. However, similar parameter may have the same name. Also, an empty string can be used as a name." ::= { parameterEntry 2 } parameterType SYNTAX Unsigned32 { INTEGER (02) BIT STRING (03) OCTET STRING (04) NULL (05) OBJECT IDENTIFIER (06) IP ADDRESS (40) } STATUS current DESCRIPTION "The BER type of the parameter. The suppoted BER types are: Type | BER identifier --------------------|---------------- INTEGER | 02 BIT STRING | 03 OCTET STRING | 04 NULL | 05 OBJECT IDENTIFIER | 06 IP ADDRESS | 40" ::= { parameterEntry 3 } -- END OF parameterTable -- -- MIBPIB Parameter Table -- mibPibParameterTable OBJECT-TYPE SYNTAX SEQUENCE OF mibPibParameterEntry PIB-ACCESS INSTALL STATUS current DESCRIPTION "This class extends the parameter class. Each instance of this class assosiates to the R.Boutaba, A.Polyrakis Internet-Draft, expires Oct.2001 [page 26] The Meta-Policy Information Base April 2001 corresponding parameter a MIB or PIB variable, from where the parameter is evaluated" ::= { parameterClasses 2 } mibPibParameterEntry OBJECT-TYPE SYNTAX MibPibParameterEntry STATUS current DESCRIPTION "An instance of the mibPibParameter class that provides the identifier of the MIB/PIB variable from where the corresponding parameter is evaluated." EXTENDS { parameterEntry } ::= { mibPibParameterTable 1 } MibPibParameterEntry ::= SEQUENCE { targetOID OBJECT-IDENTIFIER, EvaluationFrequency timeticks } targetOID OBJECT-TYPE SYNTAX OBJECT-IDENTIFIER PIB-ACCESS INSTALL STATUS current DESCRIPTION "The object identifier of the MIB/PIB variable. The MIB/PIB variable MUST exist in the MIB/PIB of the device. Also, the type of the target variable MUST be compatible with the type of the corresponding PRI of the parameter Class." ::={ mibPibParameterEntry 1 } EvaluationFrequency OBJECT-TYPE SYNTAX timeticks STATUS current DESCRIPTION "The frequency of updating the parameter in milliseconds" ::={ mibPibParameterEntry 2 } -- END of mibPibParameterTable -- -- PDP Parameter Table -- pdpParameterTable OBJECT-TYPE SYNTAX SEQUENCE OF pdpParameterEntry PIB-ACCESS INSTALL STATUS current DESCRIPTION "This class extends the parameter class. Each instance of this class contains the value of the corresponding paramter. This value is send by the PDP and updated whenever necessary." ::= { parameterClasses 3 } R.Boutaba, A.Polyrakis Internet-Draft, expires Oct.2001 [page 27] The Meta-Policy Information Base April 2001 pdpParameterEntry OBJECT-TYPE SYNTAX PdpParameterEntry STATUS current DESCRIPTION "An instance of the pdpParameter class that stores the value, sent by the PDP, for the corresponding parameter." INDEX { parameterIndex } ::= { pdpParametersTable 1 } PdpParameterEntry ::= SEQUENCE { lastValue BERValue } lastValue OBJECT-TYPE SYNTAX BERValue STATUS current DESCRIPTION "The latest value of the parameter, encoded with BER. The BER-encoded value must be of the same type as the corresponding PRI of the parameter class." ::={ pdpParameterEntry 1 } -- END OF pdpParameterTable END AuthorsÆ Information Andreas Polyrakis Dept. of Computer Science, University of Toronto, 10 King's College Road, Toronto, Ontario, M5S 3G4, Canada. e-mail: apolyr@cs.toronto.edu Phone: ++1 (416) 978-4837 Fax: ++1 (416) 978 1931 Raouf Boutaba Dept. of Computer Science, University of Waterloo, 200 University Avenue West, Waterloo, Ontario N2L 3G1, Canada e-mail: rboutaba@bbcr.uwaterloo.ca Phone: ++1 (519) 888 4567 ext.4820 Fax: ++1 (519) 885 1208 References [P-TERM] A. Westerinen, J. Schnizlein, J. Strassner, Mark Scherling, Bob Quinn, Shai Herzog, An-Ni Huynh, Mark Carlson, Jay Perry, ôTerminology for Policy-Based R.Boutaba, A.Polyrakis Internet-Draft, expires Oct.2001 [page 28] The Meta-Policy Information Base April 2001 Managementö, IETF RFC 3198, Proposed Standard, November 2000. [RAP-FRM] R. Yavatkar, D. Pendarakis, R. Guerin, "A Framework for Policy-based Admission Control", IETF RFC 2753, January 2000. [COPS] Boyle, J., Cohen, R., Durham, D., Herzog, S., Raja, R., Sastry, A., "The COPS (Common Open Policy Service) Protocol", IETF RFC 2748, Proposed Standard, January 2000. [COPS-PR] K. Chan, J. Seligson, D. Durham, S. Gai, K. McCloghrie, S. Herzog, F. Reichmeyer, R. Yavatkar, A. Smith, "COPS Usage for Policy Provisioning", IETF RFC 3084, Proposed Standard, March 2001. [FR-PIB] M. Fine, K. McCloghrie, J. Seligson, K. Chan; S. Hahn, R. Sahita, A. Smith, F. Reichmeyer, "Framework Policy Information Base", IETF, Internet-Draft, draft-ietf-rap- frameworkpib-07.txt, January 2002 [SPPI] K. McCloghrie, M. Fine, J. Seligson, K. Chan, S. Hahn, R. Sahita, A. Smith, F. Reichmeyer, "Structure of Policy Provisioning Information (SPPI)", IETF RFC 3159, Proposed Standard, Augoust 2001. R.Boutaba, A.Polyrakis Internet-Draft, expires Oct.2001 [page 29] The Meta-Policy Information Base April 2001 Appendix A û Sample XML DTD for encoding conditions R.Boutaba, A.Polyrakis Internet-Draft, expires Oct.2001 [page 30] The Meta-Policy Information Base April 2001 Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. R.Boutaba, A.Polyrakis Internet-Draft, expires Oct.2001 [page 31]