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]