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:
<ar_cond comp=ÆGTÆ>
<expr>
<expr><par>1</par></expr>
<arop op=Æ+Æ></arop>
<expr><par>2</par></expr>
</expr>
<expr><num>7</num></expr>
</ar_cond>
(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
<!ųSimple DTD for arithmetic expression representation -->
<!ų------------------------------------------>
<!ųSince these XML documents will be both -->
<!ųgenerated and consumed by machines, the -->
<!ųreadability of the tags is not very -->
<!ųimportant. However, since there might be-->
<!ųconcerns about the XML document size, -->
<!ųthe tag names were kept as small as -->
<!ųpossible. -->
<!ų------------------------------------------>
<!ų Only arithmetic expressions are supported. -->
<!ų The attribute defines the comparison type -->
<!ų GT = Greater than, LT = Less than -->
<!ų EQ = Equal, NE = Not equal -->
<!ų GE = Greater or equal, LE = Less or equal -->
<!ELEMENT ar_cond (expr, expr)>
<!ATTLIST ar_cond
comp (GT | LT | EQ | NE | GE | LE ) #REQUIRED
>
<!ELEMENT expr ((expr, arop, expr) | par | num)>
<!ELEMENT par #PCDATA>
<!ELEMENT num #PCDATA>
<!ELEMENT arop EMPTY>
<!ATTLIST arop
op ( + | - | * | / ) #REQUIRED
>
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]