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 then {actions} where ôconditionö is a logical expression and "actions" is a set of COPS-PR objects that encode a PDP decision: ::= <1*( )> 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: 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: R. Boutaba, A. Polyrakis Internet-Draft, exp. October 2001 [Page 8] COPS-PR with Meta-Policy Support May 2001 1 6 2 8 (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 (), defined for this purpose. The Object encapsulates a series of COPS-PR install/remove decision objects: ::= <1*( )> 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 Objects (encapsulated within 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 ). 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: ::= *() | [] R. Boutaba, A. Polyrakis Internet-Draft, exp. October 2001 [Page 10] COPS-PR with Meta-Policy Support May 2001 ::= [] The Named Decision Data Object in each DEC message may encapsulate either standard COPS-PR objects, or Meta-Policy information (within an 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 () that encapsulates all meta-policy information. Note that all direct communication, (i.e., when an 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 objects, as well as standard COPS-PR ClientSI objects. The 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 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 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 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*( ) 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: ::= < | | | > The Direct Install/Remove decisions are defined as the Install/Remove decisions in COPS-PR: ::= *( ) ::= *(|) 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: ::= < | | R. Boutaba, A. Polyrakis Internet-Draft, exp. October 2001 [Page 18] COPS-PR with Meta-Policy Support May 2001 > ::= ::= ::= ( | ) The Actions encapsulate COPS-PR decisions (without the context object): ::= <1*> ::= [] (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: ::= < | > 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. ::= | R. Boutaba, A. Polyrakis Internet-Draft, exp. October 2001 [Page 19] COPS-PR with Meta-Policy Support May 2001 ::= <*( )> ::= < | *( )> 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. ::= < []> ::= [] *() ::= *() ::= <[] *()> ::= *()) 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 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]