INTERNET-DRAFT Raouf Boutaba
Resource Allocation Working Group (RAP) University of Waterloo
Intended Category: Standards Track Andreas Polyrakis
Expires: October, 2001 University of Toronto
COPS-PR with Meta-Policy Support
draft-boutaba-copsprmp-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 and A. Polyrakis [Page 1]
COPS-PR with Meta-Policy Support May 2001
Abstract
In COPS-PR, the (clients of the) PEPs use special structures, called
Policy Information Bases (PIBs) that store the policies that are
sent by the PDPs. PIBs are well-defined structures that are not
meant to be modified to adapt to the needs of each network. This
makes COPS-PR PEPs rigid and inflexible. This document describes an
extension of the COPS-PR protocol that allows the PEPs to store
meta-policies that control the content of their PIBs. The set of
meta-policies that the PEPs can store is not predefined and
customized policies can be supported. The use of meta-policies
pushes intelligence towards the PEPs and makes them more self-
dependent. In this way, the model becomes more distributed, scalable
and fault-tolerant, while the bandwidth consumption and the (real-
time) processing load of the PDP are reduced.
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
The terms used in this document are in full conformance with the
terminology defined in [P-TERM] and in the base COPS [COPS] and
COPS-PR [COPS-PR] protocols.
Note: The use of the '*' character represented throughout this
document is consistent with the ABNF [RFC2234]. A plain æ*Æ means 0
or more of the following entities. A æ1*Æ means one or more of the
following entities.
R. Boutaba, A. Polyrakis Internet-Draft, exp. October 2001 [Page 2]
COPS-PR with Meta-Policy Support May 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.COPS and COPS-PR..............................................4
1.2.Why Meta-Policies?............................................6
2.Meta-Policies in COPS-PR-MP.....................................7
2.1.Definition....................................................7
2.2.Meta-policy Representation....................................7
2.2.1.Priorities..................................................7
2.2.2.Conditions..................................................8
2.2.3.Actions.....................................................9
2.2.4.Parameters..................................................9
3.Protocol and architecture modifications........................10
3.1.Exchanged messages...........................................10
3.2.Operation Modes..............................................10
3.3.PIB augmentations............................................11
3.4.The Meta-Policy DataBase (MPB)...............................11
4.Message Content................................................12
4.1.Request (REQ): PEP -> PDP....................................12
4.2.Decision (DEC): PDP -> PEP...................................12
4.3.Report State (RPT): PEP -> PDP...............................13
5.COPS-PR-MP Specific Object Formats.............................14
5.1.Meta-Policy Object (MPO).....................................14
5.2.Parameter Object (Par).......................................14
5.3.Condition Object (Cond)......................................16
5.4.Action Object (Act)..........................................16
5.5.Policy Object (Pol)..........................................16
5.6.Global Meta-Policy Error (GMPER).............................17
5.7.Specific Meta-Policy Error (SMPER)...........................17
6.COPS-PR-MP Meta-Policy Information Specific Data Formats.......18
6.1.Named Decision Data..........................................18
6.2.Named ClientSI: Request......................................19
6.3.Named ClientSI: Report.......................................20
7.Common Operation...............................................20
8.Interoperability with COPS-PR..................................21
9.Security Considerations........................................21
10.IANA Considerations...........................................21
Acknowledgements.................................................22
AuthorsÆ Information.............................................22
References.......................................................22
Appendix A û Sample XML DTD for encoding conditions..............22
Full Copyright Statement.........................................23
R. Boutaba, A. Polyrakis Internet-Draft, exp. October 2001 [Page 3]
COPS-PR with Meta-Policy Support May 2001
1. Introduction
1.1. COPS and COPS-PR
Recently, Policy-Based Networking has received significant
attention, as a promising alternative to the existing network
management techniques. IETF is currently developing the Common Open
Policy Service (COPS) [COPS] as the protocol that communicates
policy decisions from the Policy Decision Points to the Policy
Enforcement Points. COPS supports two common models for policy
control: the outsourcing and the provisioning.
COPS for Policy Provisioning (COPS-PR) [COPS-PR] is an extension of
COPS, where the PDP controls the PEPs in a provisioning style. COPS-
PR is based on the existence of a Policy Information Base (PIB). The
PIB is a structure similar to a MIB. It can be described as a
conceptual tree namespace, where the branches represent structures
of data or Provisioning Classes (PRCs) and the leaves, which are
called Provisioning Instances (PRIs), represent instantiations of
these classes. The policies are formed as a set of PRIs, stored
inside the PIB. By installing the appropriate PRIs into the PIB of a
PEP, the PDP controls the behaviour of the device.
-------+-------+----------+---PRC--+--PRI
| | | +--PRI
| | |
| | +---PRC-----PRI
| |
| +---PRC--+--PRI
| +--PRI
| +--PRI
| +--PRI
| +--PRI
|
+---PRC---PRI
Figure 1
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
could be avoided and the entire policy could be processed entirely
at the PEP level.
R. Boutaba, A. Polyrakis Internet-Draft, exp. October 2001 [Page 4]
COPS-PR with Meta-Policy Support May 2001
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 to administrators
high priorityö. If an administrator logs on at 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. COPS-PR-MP and 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 direct the PEP 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 rules,
generated by the PDP and processed by the PEP, that control the PIB
of the device. These rules control the data (policies) of the PIB;
this is why they 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
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., clock 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
R. Boutaba, A. Polyrakis Internet-Draft, exp. October 2001 [Page 5]
COPS-PR with Meta-Policy Support May 2001
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 do 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 a priority for each meta-policy, 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
of modifying 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.
This document describes COPS-PR with Meta-Policy support (COPS-PR-
MP), which is an extension of COPS-PR that implements the described
functionality.
1.2. 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
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.
R. Boutaba, A. Polyrakis Internet-Draft, exp. October 2001 [Page 6]
COPS-PR with Meta-Policy Support May 2001
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. Meta-Policies in COPS-PR-MP
2.1. Definition
A meta-policy is a rule of the form:
p: if <condition> then {actions}
where ôconditionö is a logical expression
and "actions" is a set of COPS-PR objects that encode a PDP
decision:
<Actions> ::= <1*(<Decision: Flags>
<Named Decision Data: Provisioning >
)>
Each meta-policy refers to a specific client of a specific PEP. It
is generated by the PDP that controls this client and it is consumed
by that client. Since the actions encode a specific policy, the rule
can be considered as a ôpolicy about policiesö; therefore the term
ômeta-policyö.
Note: Hereinafter, we shall call ôevaluationö of a policy the
process of evaluating the value of its conditions, and ôenforcementö
or ôactivationö of a policy the process of enforcing the described
actions. Also, we shall call ôprocessingö of a policy the process of
evaluating and activating (or deactivating) it.
2.2. Meta-policy Representation
A meta-policy in COPS-PR-MP consists of two parts: the condition and
the actions. Since both the conditions and the actions may be
parametric, information on meta-policy parameters is also necessary.
This section describes the way that meta-policy related information
is encoded and represented.
A new ClientSI object (S-Num=7) is defined to extend the existing
COPS-PR ClientSI objects, in order to communicate meta-policy
information between the PDP and the PEP. All meta-policy information
is encapsulated within this object. This object and the objects that
it encapsulates are described in detail in section 5.
2.2.1. Priorities
R. Boutaba, A. Polyrakis Internet-Draft, exp. October 2001 [Page 7]
COPS-PR with Meta-Policy Support May 2001
Each meta-policy is assigned with a non-negative integer that
denotes the priority of the meta-policy. Priorities are supplied by
the PDP and they are used when two conflicting meta-policies need to
be activated at the same time. In this case, the conflict is
resolved by activating the meta-policy with the highest priority.
2.2.2. Conditions
The ôconditionö of a meta-policy represents a logical expression
that determines when the meta-policy must be activated. The protocol
itself puts no limitations to the complexity of the expression
(size, dept of nested conditions, operators, compared types, etc.).
However, such limitations are reported from each PEP to the
controlling PDP.
Conditions, in most cases, contain parameters. Parameters are the
non-constant terms of a condition, the values of which are
dynamically generated, usually according to the state of the
network. Without parameters, the conditions would always evaluate
either true or false. Parameters are further discussed in paragraph
2.2.4.
In order to encode conditions, several encoding techniques can be
used. This document proposes and uses XML. The conditions of each
meta-policy are encoded and sent by the PDP as XML documents. The
semantics of the XML tags are described in special Data Type
Definition (DTD) documents that supplement this document. DTDs are
expected to emerge as standard documents (public or vendor-specific)
that will cover the needs of different PEPs. Each PEP should support
at least one of these well-defined DTDs. At least one supported DTD
MUST be reported to the PDP; the PDP MUST use one of them to encode
conditions for the specific PEP (if this is not possible, the PDP
should either transform the condition to a form compatible with one
supported DTD, or not send the meta-policy at all). The PEP MUST be
able to understand and process any condition which is encoded
according to any of the DTDs that it supports. In this way, PEPs
with different capabilities or requirements may support as simple or
as complex conditions as necessary. Note that all PEPs should
support at least a default, simple DTD that allows the encoding of
simple Boolean expressions.
A sample DTD is presented in Appendix A. Supposing that this DTD is
published at the URL http://foo.bar/SampleDTD.dtd, then a PEP that
wishes to indicate that it supports that DTD MUST sent to the PDP
the following empty XML document in a REQ message:
<!DOCTYPE cond SYSTEM ôhttp://foo.bar/SampleDTD.dtdö>
If the PDP wishes to send a condition, it must encode it and sent it
in a XML document, according to the specified DTD. For example, the
condition (!(C>6)&&(B==8)) would be represented as:
<!DOCTYPE cond SYSTEM ôhttp://foo.bar/SampleDTD.dtdö>
R. Boutaba, A. Polyrakis Internet-Draft, exp. October 2001 [Page 8]
COPS-PR with Meta-Policy Support May 2001
<cond not='true'>
<cond>
<simple_cond>
<par>1</par>
<arop op='gr'></arop>
<num>6</num>
</simple_cond>
</cond>
<logop op='+'></logop>
<cond>
<simple_cond>
<par>2</par>
<arop op='eq'></arop>
<num>8</num>
</simple_cond>
</cond>
</cond>
(Parameters ôCö and ôBö are mapped to the Parameter IDs 1 and 2,
respectively)
This document defines a special object (Cond) that carries
conditions. This object is encapsulated within a Meta-Policy Object
(MPO) (which is encapsulated either inside a Named Decision Data
Object in DEC messages or inside a Named ClientSI Object in REQ and
RPT messages).
Note that the XML-encoded condition does not describe how the
parameters are evaluated. This information is conveyed on a special
object (Parameter Object) that binds a parameter with an evaluation
method. This is discussed in more details in paragraph 2.2.4.
2.2.3. Actions
The Actions of a meta-policy are encapsulated within a special
object (<Act>), defined for this purpose. The <Act> Object
encapsulates a series of COPS-PR install/remove decision objects:
<Actions> ::= <1*(<Decision: Flags>
<Named Decision Data: Provisioning>
)>
The Actions of a single meta-policy may contain both install and
remove decisions. In this case, the install decisions MUST be
preceded by the remove decisions (as in COPS-PR).
2.2.4. Parameters
Parameters can be used both in Actions and in Conditions. This
version of this document does not support parameters in the actions,
though.
R. Boutaba, A. Polyrakis Internet-Draft, exp. October 2001 [Page 9]
COPS-PR with Meta-Policy Support May 2001
A parameter is a non-constant term in a meta-policy. An example of a
condition with parameters is the following:
(8:00<time<17:00) and (UsageAB<80%)
In this example, the parameter ôtimeö gets the value of the current
time and the parameter ôUsageABö gets the value of the usage
percentage of the line between routers A and B.
Parameters in COPS-PR-MP are associated with a Parameter Identifier
(ParID). Each ParID is associated with an evaluation method, through
which the parameter gets values. A possible evaluation method is
from the MIB of the device. Another method is to let the PDP send
values for this parameter, whenever its value changes. However,
other methods can exist (such as download and execute scripts,
contact another entity, etc.)
Parameters are encoded within <Par> Objects (encapsulated within
<MPO> objects).
Prior to installing (or updating) a meta-policy, the PDP MUST ensure
that it has installed all the parameters that this meta-policy uses,
and has defined an evaluation method for each of those parameters.
3. Protocol and architecture modifications
This section briefly describes how the COPS-PR protocol and the two
interacting entities (PDP-PEP) are affected.
3.1. Exchanged messages
COPS-PR-MP extends the COPS-PR ClientSI objects with a new one (MPO:
S-Num=7), which encapsulates all meta-policy related information. As
all ClientSI objects, it is encapsulated within Named ClientSI
objects (in REQ and RPT messages), or within Named Decision Data
Objects (in DEC messages). Consequently, the only messages that are
affected are these three types of messages. However, even these
messages keep exactly the same format as in COPS-PR (although a new
type of object can be encapsulated into them, the <MPO>).
3.2. Operation Modes
A COPS-PR-MP DEC message has the same format as in COPS-PR; hence it
may contain one or more decisions:
<Decision Message> ::= <Common Header>
<Client Handle>
*(<Decision>) | <Error>
[<Integrity>]
R. Boutaba, A. Polyrakis Internet-Draft, exp. October 2001 [Page 10]
COPS-PR with Meta-Policy Support May 2001
<Decision> ::= <Context>
<Decision: Flags>
[<Named Decision Data: Provisioning >]
The Named Decision Data Object in each DEC message may encapsulate
either standard COPS-PR objects, or Meta-Policy information (within
an <MPO> object). Hence, the PDP has two ways to control the PEP:
The direct (or standard COPS-PR) mode, and the indirect (or Meta-
Policy) mode, respectively. The two modes of operation can be mixed
and used concurrently.
Similarly, information conveyed within REQ and RPT messages can be
categorized as direct or indirect.
3.3. PIB augmentations
Since the capabilities of the PEP are augmented with meta-policies,
some additional PRCs have to be added to its PIB. These PRCs are
read-only and they are used in order to communicate the meta-policy
related capabilities and limitations of the PEP to the PDP. Typical
PRIs in these PRCs should report memory capabilities, maximum number
of policies and parameters, supported evaluation methods, etc. Note
that the added PRCs are independent of the client(s) of the PEP. The
additional PRCs will be defined in next versions of this document.
The additional PRCs are used only in order to communicate the
capabilities of the PEP to the PDP. The PRIDs of PRIs for these
PRCs, and their values, are encapsulated within Meta-Policy Objects
and sent to the PDP within REQ messages.
3.4. The Meta-Policy DataBase (MPB)
The PEP needs to maintain another DataBase, the Meta-Policy DataBase
(MPB), in order to hold meta-policy related information. This
database stores all such information (meta-policy identifiers,
conditions, actions, priorities, parameter identifiers, parameter
evaluation methods and values, and the way all these are
associated). The meta-policy information that is stored in the MPB
is associated with the client handle that it refers to (different
clients are controlled by different meta-policies).
The existence of this database implies the existence of a mechanism
that updates this database according to the PDP decisions, and a
mechanism that monitors the parameters, evaluates the conditions and
activates/deactivates meta-policies.
Note that this database is independent of the client(s) of the PEP.
However, the mechanisms that process the meta-policies may need to
be aware of the semantics of the PRCs and the PIBs that are
installed in the PIB at any time.
R. Boutaba, A. Polyrakis Internet-Draft, exp. October 2001 [Page 11]
COPS-PR with Meta-Policy Support May 2001
4. Message Content
This section describes the basic messages exchanged between the PDP
and the PEP, in COPS-PR-MP.
All messages used by COPS-PR-MP conform to the message
specifications defined in the COPS [COPS] and COPS-PR [COPS-PR] base
protocols. However, the COPS-PR ClientSI objects are augmented with
a new object, the Meta-Policy Object (<MPO>) that encapsulates all
meta-policy information.
Note that all direct communication, (i.e., when an <MPO> object is
not present), fully conform to COPS-PR. COPS-PR-MP is a superset of
COPS-PR, hence, any COPS-PR-MP PDP or PEP can easily revert to
standard COPS-PR, if it is required to do so.
4.1. Request (REQ): PEP -> PDP
The REQ message is sent in order to issue a ôconfiguration requestö
to the PDP. It has exactly the same format with COPS-PR; however,
the Named ClientSI object can now encapsulate <MPO> objects, as well
as standard COPS-PR ClientSI objects.
The <MPO> object encapsulates information about the capabilities and
limitations of the PEP, related to meta-policies. Hence, it may
contain (i) objects that convey information about the supported XML
DTDs (for condition representation) and (ii) bindings of PRIs and
their values, for these PRCs that are relevant to meta-policies (see
PIB augmentations, par. 3.3). Each <MPO> object may contain one PRI-
value binding, or one supported XML DTD. However, several MPOs may
exist in a single REQ message.
The reason that the meta-policy related PRIs are sent within MPOs
objects is to emphasize that this information is related to meta-
policies, and to follow the convention that all meta-policy related
information is encapsulated within MPOs objects.
A PDP that receives a REQ message with at least an <MPO> object
SHOULD assume that the client supports COPS-PR-MP.
4.2. Decision (DEC): PDP -> PEP
DEC messages can be send as solicited replies to REQ messages, or
unsolicited whenever the PDP desires to update the behaviour of the
PEP. Each DEC message may contain multiple decisions, and both
direct and indirect decisions may co-exist in the same message.
The remove decisions MUST precede the install decisions, both for
direct and indirect commands. All the decisions (direct and
indirect) within a DEC message are associated with the Client Handle
of the message.
R. Boutaba, A. Polyrakis Internet-Draft, exp. October 2001 [Page 12]
COPS-PR with Meta-Policy Support May 2001
The format of the Decision Messages is the same with COPS-PR. Yet,
MPO objects can now be encapsulated into the Named Decision Data
Objects.
As in COPS-PR, the Named Decision Data object MUST NOT be included
in the decision if the Decision Flags object Command-Code is NULL or
if the Request-State flag is set in the Decision Flags object (thus,
these messages cannot carry meta-policy related decisions).
The PEP MUST enforce all decisions, by updating the PIB according to
the Direct Decisions and the MPB according to the indirect
decisions. When a meta-policy is added to the MPB, the PEP MUST
evaluate it immediately, and if necessary, enforce it. Also, prior
to removing or updating a meta-policy, the meta-policy MUST be de-
activated (i.e., uninstalled from the PIB, if it is active).
In response to a DEC message, the policy provisioning client sends a
RPT message with the solicited message flag set back to the PDP to
inform the PDP of the result (success/failure) of the DEC message.
4.3. Report State (RPT): PEP -> PDP
The RPT message has similar usage with COPS-PR. It is used in order
to inform the PDP of the success or failure in carrying out its
decision(s), or to report an accounting related change in state. The
RPT message has exactly the same format with COPS-PR RPT messages.
Failures related to meta-policies are reported through MPO objects
that are encapsulated within Named ClientSI objects. Accounting-
related RPT messages are not applicable to meta-policies, hence they
never carry <MPO> objects.
The success and failure messages refer to the installation of the
DEC message. If one decision (either direct or indirect) in the DEC
message fails, the PEP should send a failure RPT message reporting
the error and rollback to the state before receiving the DEC
message.
When a failure is related to a direct decision, an RPT message MUST
be sent, as defined in COPS-PR. When a meta-policy related error
occurs, the RPT must specify the Policy or Parameter identifier that
is related to the error. Note that meta-policy errors are related to
adding, removing or updating policies in the MPB, or parameter-
related errors; not errors in the process of actually enforcing an
active meta-policy into the PIB. The latter type of errors SHOULD be
handled by the PEP (which should either fix them or send an
unsolicited failure RPT to the PDP). However, when a policy is added
to the MPB, the conditions and the actions SHOULD be checked for
integrity, and if a problem is detected, the meta-policy MUST NOT be
installed and an appropriate solicited failure RPT message MUST be
sent to the PDP, reporting the cause of the error.
R. Boutaba, A. Polyrakis Internet-Draft, exp. October 2001 [Page 13]
COPS-PR with Meta-Policy Support May 2001
Unsolicited failure reports may exist on both direct and indirect
decisions. As in COPS-PR, the PEP cannot rollback to a previous
"good" state; hence the PDP must take the appropriate actions on
receiving such a message in order to bring the PEP in a consistent
condition again. If such a failure is related to the MPB or with
activating a meta-policy, the MPB MUST be reset, and the PDP MUST
download again all the relevant meta-policies.
5. COPS-PR-MP Specific Object Formats
This section describes the new objects of the COPS-PR-MP protocol.
The rest of the COPS-PR objects are used by COPS-PR-MP without any
modifications.
5.1. Meta-Policy Object (MPO)
This objects extends the ClientSI objects defined in COPS-PR. This
object encapsulates any meta-policy related information, exchanged
between the PDPs and the PEPs.
S-Num=7, S-Type=1, Meta-Policy data
0 1 2 3
+---------------+---------------+---------------+---------------+
| Length | S-Num=MPO (7) | S-Type=1 |
+---------------+---------------+---------------+---------------+
This object encapsulates other objects, called Client Meta-Policy
Information (ClientMI) objects, which maintain the format:
0 1 2 3
+---------------+---------------+---------------+---------------+
| Length | M-Num | M-Type |
+---------------+---------------+---------------+---------------+
// ... //
+---------------+---------------+---------------+---------------+
M-NumÆs 1-6 are defined exactly as the corresponding S-NumÆs in
COPS-PR. These objects are re-used, in order to describe the actions
of a meta-policy, and to allow the errors in these actions to be
reported to the PDP.
M-Num 7 is not used.
5.2. Parameter Object (Par)
M-Num=8, M-Type, ParID, Evaluation Type, Value
R. Boutaba, A. Polyrakis Internet-Draft, exp. October 2001 [Page 14]
COPS-PR with Meta-Policy Support May 2001
0 1 2 3
+---------------+---------------+---------------+---------------+
| Length | M-Num=Par (8) | M-Type |
+---------------+---------------+---------------+---------------+
| ParID | Evaluation Type |
+---------------+---------------+---------------+---------------+
// ... //
+---------------+---------------+---------------+---------------+
The ParID field identifies the parameter.
Three ways of evaluating a parameter exist:
Evaluation Type = MIB (1):
+---------------+---------------+---------------+---------------+
| Length | M-Num=Par (8) | M-Type = 1 |
+---------------+---------------+---------------+---------------+
| ParID | Evaluation Type = MIB (1) |
+---------------+---------------+---------------+---------------+
| Frequency |
+---------------+---------------+---------------+---------------+
// MIB OID //
+---------------+---------------+---------------+---------------+
In this case, the parameter is evaluated according to a value
fetched from the MIB of the device. The MIB OID field encodes the
MIB object identifier, from where the value will be fetched. The
Frequency field determines, in timeticks, the frequency of re-
evaluating this value. M-Type MUST be set to 1.
The MIB OID is a variable-length field.
Evaluation Type = PDP (2):
+---------------+---------------+---------------+---------------+
| Length | M-Num=Par (8) | M-Type = 1 |
+---------------+---------------+---------------+---------------+
| ParID | Evaluation Type = PDP (2) |
+---------------+---------------+---------------+---------------+
// Value //
+---------------+---------------+---------------+---------------+
In this case, the PDP updates the parameter with identifier ParID,
with a new value. The Value field encodes the new value of the
parameter in BER format, hence the M-Type must be set to 1 (BER).
The Value is a variable-length field.
More Evaluation types will be defined in next versions of this
document.
R. Boutaba, A. Polyrakis Internet-Draft, exp. October 2001 [Page 15]
COPS-PR with Meta-Policy Support May 2001
5.3. Condition Object (Cond)
M-Num=9, M-Type=2 (XML), Condition
0 1 2 3
+---------------+---------------+---------------+---------------+
| Length | M-Num=Cond (9)| M-Type=2 |
+---------------+---------------+---------------+---------------+
// Condition //
+---------------+---------------+---------------+---------------+
The Condition Field contains the whole condition expression (XML
document) that describes the condition.
5.4. Action Object (Act)
M-Num=10, M-Type=1, Decisions
0 1 2 3
+---------------+---------------+---------------+---------------+
| Length | M-Num=Act (10)| M-Type=1 |
+---------------+---------------+---------------+---------------+
The Action object encapsulates the series of standard COPS-PR
objects that implement the desired behaviour:
Decisions ::= 1*(
<Decision: Flags>
<Named Decision Data: Provisioning>
)
5.5. Policy Object (Pol)
M-Num=11, M-Type=1, PolID, Priority
0 1 2 3
+---------------+---------------+---------------+---------------+
| Length | M-Num=Pol (11)| M-Type=1 |
+---------------+---------------+---------------+---------------+
| PolID | Priority |
+-------------------------------+-------------------------------+
The Policy object is used to determine the Policy ID (PolID) of a
meta-policy that will be installed or removed (according to the
decision command type). The Priority field denotes the priority of
the meta-policy, in case there are conflicts with other meta-
policies. The Priority and PolID fields have the same size; hence
each meta-policy can have a different priority. Although it is not
necessary, the PDPs SHOULD give different priorities to different
R. Boutaba, A. Polyrakis Internet-Draft, exp. October 2001 [Page 16]
COPS-PR with Meta-Policy Support May 2001
policies in order to ensure that conflicts that cannot be resolved
are impossible to arise.
A Policy object may be used in order to add, remove or update a
meta-policy. To install a new policy, the meta-policy object is
followed by exactly one condition object and one action object. To
remove an existing policy, a decision message is sent with a remove
command followed by a meta-policy object with a Pol object with the
appropriate PolID.
The PolID is a unique integer (in the scope of the client-handle).
5.6. Global Meta-Policy Error (GMPER)
The Global Meta-Policy Error is used to communicate meta-policy
errors that are not related to a specific meta-policy.
M-Num=12, M-Type=1, Error-Code, Error Sub-Code
This object is used to inform the PDP of meta-policy errors.
0 1 2 3
+---------------+---------------+---------------+---------------+
| Length |M-Num=GMPER(12)| M-Type=1 |
+---------------+---------------+---------------+---------------+
| Error-Code | Error Sub-code |
+---------------+---------------+---------------+---------------+
The error codes are to be defined.
5.7. Specific Meta-Policy Error (SMPER)
The Specific Meta-Policy Error is used to communicate meta-policy
errors that are related to a specific meta-policy.
S-Num=13, Error-Code, Error Sub-Code
This object is used to inform the PDP of meta-policy errors.
0 1 2 3
+---------------+---------------+---------------+---------------+
| Length |M-Num=SMPER(12)| M-Type=1 |
+---------------+---------------+---------------+---------------+
| Error-Code | Error Sub-code |
+---------------+---------------+---------------+---------------+
The error codes are defined:
R. Boutaba, A. Polyrakis Internet-Draft, exp. October 2001 [Page 17]
COPS-PR with Meta-Policy Support May 2001
Missing Condition Object (1) -The relevant PolID MUST be
specified in the Sub-Code.
Missing Actions Object (2) -The relevant PolID MUST be
specified in the Sub-Code.
Non-existing Parameter (3) -The relevant ParID must be
specified in the Sub-Code.
Unsupported Condition Encoding (4) -The relevant PolID MUST be
specified in the Sub-Code.
Badly formed Condition (5) -The relevant PolID MUST be
specified in the Sub-Code.
Non-resolvable Conflict (6) -The relevant PolID MUST be
specified in the Sub-Code.
Error in actions (8) -The relevant PolID MUST be
specified in the Sub-Code.
6. COPS-PR-MP Meta-Policy Information Specific Data Formats
This section describes the way that the previously defined objects
are used.
6.1. Named Decision Data
In COPS-PR, a Named Decision Data Object encapsulates an Install or
a Remove decision. In COPS-PR-MP, this object may also encapsulate
meta-policy decisions:
<Named Decision Data> ::= <<Direct Install Decision> |
<Direct Remove Decision> |
<Meta-Policy Install Decision> |
<Meta-Policy Remove Decision>>
The Direct Install/Remove decisions are defined as the
Install/Remove decisions in COPS-PR:
<Install Decision> ::= *(<PRID> <EPD>)
<Remove Decision> ::= *(<PRID>|<PPRID>)
A Meta-Policy Install Decision can either install a parameter or a
meta-policy. In the first case, it encapsulates a PAR object that
directs the PEP how to evaluate the parameters, (or carries the
newest value for this parameter). In the second case, a meta-policy
MUST contain at least a Pol object that identifies the policy to be
installed. If this is a new policy, exactly one condition and one
action must follow. If this policy already exists (in this case the
message updates the policy) the Pol object MUST be followed by
either a single Cond Object or a single Act object, that update the
conditions or the actions of the meta-policy, respectively:
<Meta-Policy Install Decision> ::=
<<Parameter install> |
<meta-policy install> |
R. Boutaba, A. Polyrakis Internet-Draft, exp. October 2001 [Page 18]
COPS-PR with Meta-Policy Support May 2001
<meta-policy update>>
<Parameter install > ::= <Parameter>
<meta-policy install> ::= <Policy>
<Conditions>
<Actions>
<meta-policy update> ::= <Policy>
(<Conditions> | <Actions>)
The Actions encapsulate COPS-PR decisions (without the context
object):
<Actions> ::= <1*<Action>>
<Action> ::= <Decision: Flags>
[<Named Decision Data: Provisioning >]
(Note that in this version of the document, nested meta-policies,
i.e., meta-policies that install other meta-policies, are not
allowed. This means that the Actions cannot carry Named Decision
Data Objects that encapsulate meta-policy Objects. In future
versions of this document, however, this constrain may be removed)
If the PEP receives an install decisions that refers to parameters
that do not exist, an appropriate error must be issued in a failure
RPT message. The same holds for the case where a decisions attempts
to install a policy with a PolID that already exists, or update an
non-existing policy.
A Meta-Policy Remove Decision may either remove a parameter or a
meta-policy. In the first case, a Par object with the relevant ParID
is sent. In the second case, a Pol object with the relevant PolID is
sent:
<Meta-Policy remove Decision> ::=
<<Parameter> | <Policy>>
Failure RPTs should be sent to the PDP if a non-existing parameter
or meta-policy is attempted to be removed.
6.2. Named ClientSI: Request
The Named ClientSI object within a REQ is used to report the
capabilities of the PEP/client. An MPO object within a Named
ClientSI object can be used in order to convey information about the
meta-policy capabilities of the PEP/Client. The MPO object contains
either condition object that reports a supported XML DTD or PRI-EPD
pairs that report meta-policy capabilities of the PEP. More than one
MPO can exist in a REQ message.
<Named ClientSI: Request> ::= <Direct Request> |
R. Boutaba, A. Polyrakis Internet-Draft, exp. October 2001 [Page 19]
COPS-PR with Meta-Policy Support May 2001
<Inderect Request>
<Direct Request> ::= <*(<PRID> <EPD>)>
<Indirect Request> ::= < <MPO> | *(<PRID> <EPD>)>
6.3. Named ClientSI: Report
Accounting RPT messages are not applicable to meta-policies, hence
only direct RPT accounting messages exist, which are as described in
COPS-PR. RPT that report the success or failure of installing a
decision have two parts: the direct one that reports the success or
failure of installing direct decisions, and the indirect one that
reports the success or failure of installing meta-policies. The
former has the same format as in COPS-PR. The second is encapsulated
within an MPO object. This object contains any General Meta-Policy
errors, followed by one or more Specific Meta-Policy Errors. This
object reports the Parameter or Meta-Policy, which caused the error.
If the error is detected within the actions of the meta-policy, the
(PRID,EPD) pair that caused the error can be reported.
<Named ClientSI: Report> ::= <<Direct Decision Report>
[<Indirect Decision Report>]>
<Direct Decision Report> ::= [<GPERR>] *(<Dreport>)
<Dreport> ::= <ErrorPRID> <CPERR> *(<PRID><EPD>)
<Indirect Decision Report> ::= <[<GMPER>] *(<MPreport>)>
<MPreport> ::= <SMPE> *(<PRID><EPD>))
7. Common Operation
In general, the interaction between a COPS-PR-MP PDP and PEP is
similar to COPS-PR. The differences are summed up in the following:
In the REQ messages, the PEP must inform the PDP of the meta-policy
capabilities and the supported XML DTDs. This is achieved by
encoding this information within MPO objects, each encapsulated
within a Named ClientSI object.
When a PDP receives from a client a REQ message that contains at
least one MPO object, it SHOULD assume that this client supports
meta-policies. The PDP downloads the initial policies and meta-
policies that determine the behaviour of the client. The PDP must
ensure that meta-policies that may conflict with each other are
associated with different priorities, so that the PEP will be able
to resolve the conflict, if both need to be activated at the same
time. The PDP needs to inform the PEP of the evaluation method for
R. Boutaba, A. Polyrakis Internet-Draft, exp. October 2001 [Page 20]
COPS-PR with Meta-Policy Support May 2001
each of the parameters that the PEP uses in the meta-policies. Also,
the PDP has to send initial values for those parameters which will
be evaluated by the PDP instead of the PEP.
The PDP may send unsolicited DEC messages with direct commands that
update the PIB, or indirect commands that update the meta-policies
or the values of the parameters.
On receiving a DEC message, the client installs both the direct and
indirect commands, and reports the success or the failure of this
procedure to the PDP with a solicited RPT message.
The PEP monitors the values of the parameters. When a value changes,
the related conditions are recalculated, and, depending on the
result, meta-policies are activated or deactivated. If two meta-
policies are activated simultaneously, the conflict MUST be resolved
according to the priority (higher priority wins). Direct commands
always have higher priority than meta-policies.
8. Interoperability with COPS-PR
A PDP that receives a REQ message with at least an MPO object SHOULD
assume that the PEP supports COPS-PR-MP. On the other hand, if a PEP
sends a REQ message without any MPO objects, the PDP MUST assume
that this is a COPS-PR PEP and MUST control it exclusively according
to the COPS-PR protocol (unless the PEP sends a new REQ message that
contains MPOs).
A COPS-PR-MP that sends a REQ message with MPO objects to a COPS-PR
PDP SHOULD receive an error message, indicating that the PDP does
not recognise the MPO object. In this case, the PEP MUST revert to
standard COPS-PR and issue a new REQ message without MPO objects.
In both cases, the PDP can fully control the PEP through standard
COPS-PR commands. Hence, COPS-PR-MP PDPs and PEPs can interoperate
without problems.
9. Security Considerations
No new security issues are introduced by COPS-PR-MP. The discussion
conducted in the relevant section of [COPS] and [COPS-PR] apply
here, as well.
10. IANA Considerations
COPS-PR-MP follows the same IANA considerations for COPS objects as
the base COPS protocol [COPS]. COPS-PR introduces a new extends the
S-Num name space, defined in [COPS-PR] with a new object (S-Num=7).
R. Boutaba, A. Polyrakis Internet-Draft, exp. October 2001 [Page 21]
COPS-PR with Meta-Policy Support May 2001
Acknowledgements
This research work was supported by research grants from Nortel
Networks and the Natural Sciences and Engineering Research Council
of Canada.
AuthorsÆ Information
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
Andreas Polyrakis
Dept. of Computer Science,
University of Toronto,
10 King's College Road,
Toronto, Ontario,M5S 3G4, Canada.
Phone: ++1 (416) 978-4837
Fax: ++1 (416) 978 1931
References
[P-TERM] A. Westerinen, J. Schnizlein, J. Strassner, Mark
Scherling, Bob Quinn, Jay Perry, Shai Herzog, An-Ni Huynh,
Mark Carlson, ôPolicy Terminologyö, Internet draft, draft-
ietf-policy-terminology-00.txt, July 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, D. Durham, S. Gai, S. Herzog, K. McCloghrie, F.
Reichmeyer, J. Seligson, A. Smith, R. Yavatkar, "COPS
Usage for Policy Provisioning," draft-ietf-rap-pr-05.txt,
October 30, 2000.
[RFC2234] D. Crocker, P. Overell, " Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
Appendix A û Sample XML DTD for encoding conditions
R. Boutaba, A. Polyrakis Internet-Draft, exp. October 2001 [Page 22]
COPS-PR with Meta-Policy Support May 2001
<!ùSimple DTD for condition 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. -->
<!ù------------------------------------------>
<!ù A general, complex condition -->
<!ù The attribute ônotö is used for negation -->
<!ELEMENT cond ((cond, logop, cond) | simple_cond)>
<!ATTLIST cond
not (true | false) "false"
>
<!ù Logical operator. Its attribute ôopö defines the operator -->
<!ELEMENT logop EMPTY>
<!ATTLIST logop
op (or | and) #REQUIRED
>
<!ù Simple Boolean condition. -->
<!ù 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 simple_cond (expr, expr)>
<!ATTLIST simple_cond
comp (GT | LT | EQ | NE | GE | LE ) #REQUIRED
>
<!ELEMENT expr ((expr, arop, expr) | var | num)>
<!ELEMENT var #PCDATA>
<!ELEMENT num #PCDATA>
<!ELEMENT arop EMPTY>
<!ATTLIST arop
op ( + | - | * | / ) #REQUIRED
>
Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
R. Boutaba, A. Polyrakis Internet-Draft, exp. October 2001 [Page 23]
COPS-PR with Meta-Policy Support May 2001
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, exp. October 2001 [Page 24]