8/1/23, 1:07 PM
`
`RFC 2748: The COPS (Common Open Policy Service) Protocol
`
`Network Working Group
`Request for Comments: 2748
`Category: Standards Track
`
`D. Durham, Ed.
`Intel
`J. Boyle
`Level 3
`R. Cohen
`Cisco
`S. Herzog
`IPHighway
`R. Rajan
`AT&T
`A. Sastry
`Cisco
`January 2000
`
`The COPS (Common Open Policy Service) Protocol
`
`Status of this Memo
`
` This document specifies an Internet standards track protocol for the
` Internet community, and requests discussion and suggestions for
` improvements. Please refer to the current edition of the "Internet
` Official Protocol Standards" (STD 1) for the standardization state
` and status of this protocol. Distribution of this memo is unlimited.
`
`Copyright Notice
`
` Copyright (C) The Internet Society (2000). All Rights Reserved.
`
`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].
`
`Abstract
`
` This document describes a simple client/server model for supporting
` policy control over QoS signaling protocols. The model does not make
` any assumptions about the methods of the policy server, but is based
` on the server returning decisions to policy requests. The model is
` designed to be extensible so that other kinds of policy clients may
` be supported in the future. However, this document makes no claims
` that it is the only or the preferred approach for enforcing future
` types of policies.
`
`Durham, et al.
`
`Standards Track
`
`[Page 1]
`
`https://www.rfc-editor.org/rfc/rfc2748.html
`
`1/38
`
`1
`
`SAMSUNG 1036
`
`

`

`8/1/23, 1:07 PM
`
`RFC 2748: The COPS (Common Open Policy Service) Protocol
`
`RFC 2748 COPS January 2000
`
`Table Of Contents
`
` 1. Introduction....................................................3
` 1.1 Basic Model....................................................4
` 2. The Protocol....................................................6
` 2.1 Common Header..................................................6
` 2.2 COPS Specific Object Formats...................................8
` 2.2.1 Handle Object (Handle).......................................9
` 2.2.2 Context Object (Context).....................................9
` 2.2.3 In-Interface Object (IN-Int)................................10
` 2.2.4 Out-Interface Object (OUT-Int)..............................11
` 2.2.5 Reason Object (Reason)......................................12
` 2.2.6 Decision Object (Decision)..................................12
` 2.2.7 LPDP Decision Object (LPDPDecision).........................14
` 2.2.8 Error Object (Error)........................................14
` 2.2.9 Client Specific Information Object (ClientSI)...............15
` 2.2.10 Keep-Alive Timer Object (KATimer)..........................15
` 2.2.11 PEP Identification Object (PEPID)..........................16
` 2.2.12 Report-Type Object (Report-Type)...........................16
` 2.2.13 PDP Redirect Address (PDPRedirAddr)........................16
` 2.2.14 Last PDP Address (LastPDPAddr).............................17
` 2.2.15 Accounting Timer Object (AcctTimer)........................17
` 2.2.16 Message Integrity Object (Integrity).......................18
` 2.3 Communication.................................................19
` 2.4 Client Handle Usage...........................................21
` 2.5 Synchronization Behavior......................................21
` 3. Message Content................................................22
` 3.1 Request (REQ) PEP -> PDP.....................................22
` 3.2 Decision (DEC) PDP -> PEP....................................24
` 3.3 Report State (RPT) PEP -> PDP................................25
` 3.4 Delete Request State (DRQ) PEP -> PDP........................25
` 3.5 Synchronize State Request (SSQ) PDP -> PEP...................26
` 3.6 Client-Open (OPN) PEP -> PDP.................................26
` 3.7 Client-Accept (CAT) PDP -> PEP...............................27
` 3.8 Client-Close (CC) PEP -> PDP, PDP -> PEP.....................28
` 3.9 Keep-Alive (KA) PEP -> PDP, PDP -> PEP.......................28
` 3.10 Synchronize State Complete (SSC) PEP -> PDP..................29
` 4. Common Operation...............................................29
` 4.1 Security and Sequence Number Negotiation......................29
` 4.2 Key Maintenance...............................................31
` 4.3 PEP Initialization............................................31
` 4.4 Outsourcing Operations........................................32
` 4.5 Configuration Operations......................................32
` 4.6 Keep-Alive Operations.........................................33
` 4.7 PEP/PDP Close.................................................33
` 5. Security Considerations........................................33
` 6. IANA Considerations............................................34
`
`Durham, et al. Standards Track [Page 2]
`
`https://www.rfc-editor.org/rfc/rfc2748.html
`
`2/38
`
`2
`
`

`

`8/1/23, 1:07 PM
`
`RFC 2748: The COPS (Common Open Policy Service) Protocol
`
`RFC 2748 COPS January 2000
`
` 7. References.....................................................35
` 8. Author Information and Acknowledgments.........................36
` 9. Full Copyright Statement.......................................38
`
`1. Introduction
`
` This document describes a simple query and response protocol that can
` be used to exchange policy information between a policy server
` (Policy Decision Point or PDP) and its clients (Policy Enforcement
` Points or PEPs). One example of a policy client is an RSVP router
` that must exercise policy-based admission control over RSVP usage
` [RSVP]. We assume that at least one policy server exists in each
` controlled administrative domain. The basic model of interaction
` between a policy server and its clients is compatible with the
` framework document for policy based admission control [WRK].
`
` A chief objective of this policy control protocol is to begin with a
` simple but extensible design. The main characteristics of the COPS
` protocol include:
`
` 1. The protocol employs a client/server model where the PEP sends
` requests, updates, and deletes to the remote PDP and the PDP
` returns decisions back to the PEP.
`
` 2. The protocol uses TCP as its transport protocol for reliable
` exchange of messages between policy clients and a server.
` Therefore, no additional mechanisms are necessary for reliable
` communication between a server and its clients.
`
` 3. The protocol is extensible in that it is designed to leverage
` off self-identifying objects and can support diverse client
` specific information without requiring modifications to the
` COPS protocol itself. The protocol was created for the general
` administration, configuration, and enforcement of policies.
`
` 4. COPS provides message level security for authentication, replay
` protection, and message integrity. COPS can also reuse existing
` protocols for security such as IPSEC [IPSEC] or TLS to
` authenticate and secure the channel between the PEP and the
` PDP.
`
` 5. The protocol is stateful in two main aspects: (1)
` Request/Decision state is shared between client and server and
` (2) State from various events (Request/Decision pairs) may be
` inter-associated. By (1) we mean that requests from the client
` PEP are installed or remembered by the remote PDP until they
` are explicitly deleted by the PEP. At the same time, Decisions
` from the remote PDP can be generated asynchronously at any time
`
`Durham, et al. Standards Track [Page 3]
`
`https://www.rfc-editor.org/rfc/rfc2748.html
`
`3/38
`
`3
`
`

`

`8/1/23, 1:07 PM
`
`RFC 2748: The COPS (Common Open Policy Service) Protocol
`
`RFC 2748 COPS January 2000
`
` for a currently installed request state. By (2) we mean that
` the server may respond to new queries differently because of
` previously installed Request/Decision state(s) that are
` related.
`
` 6. Additionally, the protocol is stateful in that it allows the
` server to push configuration information to the client, and
` then allows the server to remove such state from the client
` when it is no longer applicable.
`
`1.1 Basic Model
`
` +----------------+
` | |
` | Network Node | Policy Server
` | |
` | +-----+ | COPS +-----+
` | | PEP |<-----|-------------->| PDP |
` | +-----+ | +-----+
` | ^ |
` | | |
` | \-->+-----+ |
` | | LPDP| |
` | +-----+ |
` | |
` +----------------+
`
` Figure 1: A COPS illustration.
`
` Figure 1 Illustrates the layout of various policy components in a
` typical COPS example (taken from [WRK]). Here, COPS is used to
` communicate policy information between a Policy Enforcement Point
` (PEP) and a remote Policy Decision Point (PDP) within the context of
` a particular type of client. The optional Local Policy Decision Point
` (LPDP) can be used by the device to make local policy decisions in
` the absence of a PDP.
`
` It is assumed that each participating policy client is functionally
` consistent with a PEP [WRK]. The PEP may communicate with a policy
` server (herein referred to as a remote PDP [WRK]) to obtain policy
` decisions or directives.
`
` The PEP is responsible for initiating a persistent TCP connection to
` a PDP. The PEP uses this TCP connection to send requests to and
` receive decisions from the remote PDP. Communication between the PEP
` and remote PDP is mainly in the form of a stateful request/decision
` exchange, though the remote PDP may occasionally send unsolicited
`
`Durham, et al. Standards Track [Page 4]
`
`https://www.rfc-editor.org/rfc/rfc2748.html
`
`4/38
`
`4
`
`

`

`8/1/23, 1:07 PM
`
`RFC 2748: The COPS (Common Open Policy Service) Protocol
`
`RFC 2748 COPS January 2000
`
` decisions to the PEP to force changes in previously approved request
` states. The PEP also has the capacity to report to the remote PDP
` that it has successfully completed performing the PDP's decision
` locally, useful for accounting and monitoring purposes. The PEP is
` responsible for notifying the PDP when a request state has changed on
` the PEP. Finally, the PEP is responsible for the deletion of any
` state that is no longer applicable due to events at the client or
` decisions issued by the server.
`
` When the PEP sends a configuration request, it expects the PDP to
` continuously send named units of configuration data to the PEP via
` decision messages as applicable for the configuration request. When a
` unit of named configuration data is successfully installed on the
` PEP, the PEP should send a report message to the PDP confirming the
` installation. The server may then update or remove the named
` configuration information via a new decision message. When the PDP
` sends a decision to remove named configuration data from the PEP, the
` PEP will delete the specified configuration and send a report message
` to the PDP as confirmation.
`
` The policy protocol is designed to communicate self-identifying
` objects which contain the data necessary for identifying request
` states, establishing the context for a request, identifying the type
` of request, referencing previously installed requests, relaying
` policy decisions, reporting errors, providing message integrity, and
` transferring client specific/namespace information.
`
` To distinguish between different kinds of clients, the type of client
` is identified in each message. Different types of clients may have
` different client specific data and may require different kinds of
` policy decisions. It is expected that each new client-type will have
` a corresponding usage draft specifying the specifics of its
` interaction with this policy protocol.
`
` The context of each request corresponds to the type of event that
` triggered it. The COPS Context object identifies the type of request
` and message (if applicable) that triggered a policy event via its
` message type and request type fields. COPS identifies three types of
` outsourcing events: (1) the arrival of an incoming message (2)
` allocation of local resources, and (3) the forwarding of an outgoing
` message. Each of these events may require different decisions to be
` made. The content of a COPS request/decision message depends on the
` context. A fourth type of request is useful for types of clients that
` wish to receive configuration information from the PDP. This allows a
` PEP to issue a configuration request for a specific named device or
` module that requires configuration information to be installed.
`
`Durham, et al. Standards Track [Page 5]
`
`https://www.rfc-editor.org/rfc/rfc2748.html
`
`5/38
`
`5
`
`

`

`8/1/23, 1:07 PM
`
`RFC 2748: The COPS (Common Open Policy Service) Protocol
`
`RFC 2748 COPS January 2000
`
` The PEP may also have the capability to make a local policy decision
` via its Local Policy Decision Point (LPDP) [WRK], however, the PDP
` remains the authoritative decision point at all times. This means
` that the relevant local decision information must be relayed to the
` PDP. That is, the PDP must be granted access to all relevant
` information to make a final policy decision. To facilitate this
` functionality, the PEP must send its local decision information to
` the remote PDP via an LPDP decision object. The PEP must then abide
` by the PDP's decision as it is absolute.
`
` Finally, fault tolerance is a required capability for this protocol,
` particularly due to the fact it is associated with the security and
` service management of distributed network devices. Fault tolerance
` can be achieved by having both the PEP and remote PDP constantly
` verify their connection to each other via keep-alive messages. When a
` failure is detected, the PEP must try to reconnect to the remote PDP
` or attempt to connect to a backup/alternative PDP. While
` disconnected, the PEP should revert to making local decisions. Once a
` connection is reestablished, the PEP is expected to notify the PDP of
` any deleted state or new events that passed local admission control
` after the connection was lost. Additionally, the remote PDP may
` request that all the PEP's internal state be resynchronized (all
` previously installed requests are to be reissued). After failure and
` before the new connection is fully functional, disruption of service
` can be minimized if the PEP caches previously communicated decisions
` and continues to use them for some limited amount of time. Sections
` 2.3 and 2.5 detail COPS mechanisms for achieving reliability.
`
`2. The Protocol
`
` This section describes the message formats and objects exchanged
` between the PEP and remote PDP.
`
`2.1 Common Header
`
` Each COPS message consists of the COPS header followed by a number of
` typed objects.
`
` 0 1 2 3
` +--------------+--------------+--------------+--------------+
` |Version| Flags| Op Code | Client-type |
` +--------------+--------------+--------------+--------------+
` | Message Length |
` +--------------+--------------+--------------+--------------+
`
` Global note: //// implies field is reserved, set to 0.
`
`Durham, et al. Standards Track [Page 6]
`
`https://www.rfc-editor.org/rfc/rfc2748.html
`
`6/38
`
`6
`
`

`

`8/1/23, 1:07 PM
`
`RFC 2748: The COPS (Common Open Policy Service) Protocol
`
`RFC 2748 COPS January 2000
`
` The fields in the header are:
` Version: 4 bits
` COPS version number. Current version is 1.
`
` Flags: 4 bits
` Defined flag values (all other flags MUST be set to 0):
` 0x1 Solicited Message Flag Bit
` This flag is set when the message is solicited by
` another COPS message. This flag is NOT to be set
` (value=0) unless otherwise specified in section 3.
`
` Op Code: 8 bits
` The COPS operations:
` 1 = Request (REQ)
` 2 = Decision (DEC)
` 3 = Report State (RPT)
` 4 = Delete Request State (DRQ)
` 5 = Synchronize State Req (SSQ)
` 6 = Client-Open (OPN)
` 7 = Client-Accept (CAT)
` 8 = Client-Close (CC)
` 9 = Keep-Alive (KA)
` 10= Synchronize Complete (SSC)
`
` Client-type: 16 bits
`
` The Client-type identifies the policy client. Interpretation of
` all encapsulated objects is relative to the client-type. Client-
` types that set the most significant bit in the client-type field
` are enterprise specific (these are client-types 0x8000 -
` 0xFFFF). (See the specific client usage documents for particular
` client-type IDs). For KA Messages, the client-type in the header
` MUST always be set to 0 as the KA is used for connection
` verification (not per client session verification).
`
` Message Length: 32 bits
` Size of message in octets, which includes the standard COPS
` header and all encapsulated objects. Messages MUST be aligned on
` 4 octet intervals.
`
`Durham, et al. Standards Track [Page 7]
`
`https://www.rfc-editor.org/rfc/rfc2748.html
`
`7/38
`
`7
`
`

`

`8/1/23, 1:07 PM
`
`RFC 2748: The COPS (Common Open Policy Service) Protocol
`
`RFC 2748 COPS January 2000
`
`2.2 COPS Specific Object Formats
`
` All the objects follow the same object format; each object consists
` of one or more 32-bit words with a four-octet header, using the
` following format:
`
` 0 1 2 3
` +-------------+-------------+-------------+-------------+
` | Length (octets) | C-Num | C-Type |
` +-------------+-------------+-------------+-------------+
` | |
` // (Object contents) //
` | |
` +-------------+-------------+-------------+-------------+
`
` The length is a two-octet value that describes the number of octets
` (including the header) that compose the object. If the length in
` octets does not fall on a 32-bit word boundary, padding MUST be added
` to the end of the object so that it is aligned to the next 32-bit
` boundary before the object can be sent on the wire. On the receiving
` side, a subsequent object boundary can be found by simply rounding up
` the previous stated object length to the next 32-bit boundary.
`
` Typically, C-Num identifies the class of information contained in the
` object, and the C-Type identifies the subtype or version of the
` information contained in the object.
`
` C-num: 8 bits
` 1 = Handle
` 2 = Context
` 3 = In Interface
` 4 = Out Interface
` 5 = Reason code
` 6 = Decision
` 7 = LPDP Decision
` 8 = Error
` 9 = Client Specific Info
` 10 = Keep-Alive Timer
` 11 = PEP Identification
` 12 = Report Type
` 13 = PDP Redirect Address
` 14 = Last PDP Address
` 15 = Accounting Timer
` 16 = Message Integrity
`
` C-type: 8 bits
` Values defined per C-num.
`
`Durham, et al. Standards Track [Page 8]
`
`https://www.rfc-editor.org/rfc/rfc2748.html
`
`8/38
`
`8
`
`

`

`8/1/23, 1:07 PM
`
`RFC 2748: The COPS (Common Open Policy Service) Protocol
`
`RFC 2748 COPS January 2000
`
`2.2.1 Handle Object (Handle)
`
` The Handle Object encapsulates a unique value that identifies an
` installed state. This identification is used by most COPS operations.
` A state corresponding to a handle MUST be explicitly deleted when it
` is no longer applicable. See Section 2.4 for details.
`
` C-Num = 1
`
` C-Type = 1, Client Handle.
`
` Variable-length field, no implied format other than it is unique from
` other client handles from the same PEP (a.k.a. COPS TCP connection)
` for a particular client-type. It is always initially chosen by the
` PEP and then deleted by the PEP when no longer applicable. The client
` handle is used to refer to a request state initiated by a particular
` PEP and installed at the PDP for a client-type. A PEP will specify a
` client handle in its Request messages, Report messages and Delete
` messages sent to the PDP. In all cases, the client handle is used to
` uniquely identify a particular PEP's request for a client-type.
`
` The client handle value is set by the PEP and is opaque to the PDP.
` The PDP simply performs a byte-wise comparison on the value in this
` object with respect to the handle object values of other currently
` installed requests.
`
`2.2.2 Context Object (Context)
`
` Specifies the type of event(s) that triggered the query. Required for
` request messages. Admission control, resource allocation, and
` forwarding requests are all amenable to client-types that outsource
` their decision making facility to the PDP. For applicable client-
` types a PEP can also make a request to receive named configuration
` information from the PDP. This named configuration data may be in a
` form useful for setting system attributes on a PEP, or it may be in
` the form of policy rules that are to be directly verified by the PEP.
`
` Multiple flags can be set for the same request. This is only allowed,
` however, if the set of client specific information in the combined
` request is identical to the client specific information that would be
` specified if individual requests were made for each specified flag.
`
` C-num = 2, C-Type = 1
`
`Durham, et al. Standards Track [Page 9]
`
`https://www.rfc-editor.org/rfc/rfc2748.html
`
`9/38
`
`9
`
`

`

`8/1/23, 1:07 PM
`
`RFC 2748: The COPS (Common Open Policy Service) Protocol
`
`RFC 2748 COPS January 2000
`
` 0 1 2 3
` +--------------+--------------+--------------+--------------+
` | R-Type | M-Type |
` +--------------+--------------+--------------+--------------+
`
` R-Type (Request Type Flag)
`
` 0x01 = Incoming-Message/Admission Control request
` 0x02 = Resource-Allocation request
` 0x04 = Outgoing-Message request
` 0x08 = Configuration request
`
` M-Type (Message Type)
`
` Client Specific 16 bit values of protocol message types
`
`2.2.3 In-Interface Object (IN-Int)
`
` The In-Interface Object is used to identify the incoming interface on
` which a particular request applies and the address where the received
` message originated. For flows or messages generated from the PEP's
` local host, the loop back address and ifindex are used.
`
` This Interface object is also used to identify the incoming
` (receiving) interface via its ifindex. The ifindex may be used to
` differentiate between sub-interfaces and unnumbered interfaces (see
` RSVP's LIH for an example). When SNMP is supported by the PEP, this
` ifindex integer MUST correspond to the same integer value for the
` interface in the SNMP MIB-II interface index table.
`
` Note: The ifindex specified in the In-Interface is typically relative
` to the flow of the underlying protocol messages. The ifindex is the
` interface on which the protocol message was received.
`
` C-Num = 3
`
` C-Type = 1, IPv4 Address + Interface
`
` 0 1 2 3
` +--------------+--------------+--------------+--------------+
` | IPv4 Address format |
` +--------------+--------------+--------------+--------------+
` | ifindex |
` +--------------+--------------+--------------+--------------+
`
` For this type of the interface object, the IPv4 address specifies the
` IP address that the incoming message came from.
`
`Durham, et al. Standards Track [Page 10]
`
`https://www.rfc-editor.org/rfc/rfc2748.html
`
`10/38
`
`10
`
`

`

`8/1/23, 1:07 PM
`
`RFC 2748: The COPS (Common Open Policy Service) Protocol
`
`RFC 2748 COPS January 2000
`
` C-Type = 2, IPv6 Address + Interface
`
` 0 1 2 3
` +--------------+--------------+--------------+--------------+
` | |
` + +
` | |
` + IPv6 Address format +
` | |
` + +
` | |
` +--------------+--------------+--------------+--------------+
` | ifindex |
` +--------------+--------------+--------------+--------------+
`
` For this type of the interface object, the IPv6 address specifies the
` IP address that the incoming message came from. The ifindex is used
` to refer to the MIB-II defined local incoming interface on the PEP as
` described above.
`
`2.2.4 Out-Interface Object (OUT-Int)
`
` The Out-Interface is used to identify the outgoing interface to which
` a specific request applies and the address for where the forwarded
` message is to be sent. For flows or messages destined to the PEP's
` local host, the loop back address and ifindex are used. The Out-
` Interface has the same formats as the In-Interface Object.
`
` This Interface object is also used to identify the outgoing
` (forwarding) interface via its ifindex. The ifindex may be used to
` differentiate between sub-interfaces and unnumbered interfaces (see
` RSVP's LIH for an example). When SNMP is supported by the PEP, this
` ifindex integer MUST correspond to the same integer value for the
` interface in the SNMP MIB-II interface index table.
`
` Note: The ifindex specified in the Out-Interface is typically
` relative to the flow of the underlying protocol messages. The ifindex
` is the one on which a protocol message is about to be forwarded.
`
` C-Num = 4
`
` C-Type = 1, IPv4 Address + Interface
`
` Same C-Type format as the In-Interface object. The IPv4 address
` specifies the IP address to which the outgoing message is going. The
` ifindex is used to refer to the MIB-II defined local outgoing
` interface on the PEP.
`
`Durham, et al. Standards Track [Page 11]
`
`https://www.rfc-editor.org/rfc/rfc2748.html
`
`11/38
`
`11
`
`

`

`8/1/23, 1:07 PM
`
`RFC 2748: The COPS (Common Open Policy Service) Protocol
`
`RFC 2748 COPS January 2000
`
` C-Type = 2, IPv6 Address + Interface
`
` Same C-Type format as the In-Interface object. For this type of the
` interface object, the IPv6 address specifies the IP address to which
` the outgoing message is going. The ifindex is used to refer to the
` MIB-II defined local outgoing interface on the PEP.
`
`2.2.5 Reason Object (Reason)
`
` This object specifies the reason why the request state was deleted.
` It appears in the delete request (DRQ) message. The Reason Sub-code
` field is reserved for more detailed client-specific reason codes
` defined in the corresponding documents.
`
` C-Num = 5, C-Type = 1
`
` 0 1 2 3
` +--------------+--------------+--------------+--------------+
` | Reason-Code | Reason Sub-code |
` +--------------+--------------+--------------+--------------+
`
` Reason Code:
` 1 = Unspecified
` 2 = Management
` 3 = Preempted (Another request state takes precedence)
` 4 = Tear (Used to communicate a signaled state removal)
` 5 = Timeout (Local state has timed-out)
` 6 = Route Change (Change invalidates request state)
` 7 = Insufficient Resources (No local resource available)
` 8 = PDP's Directive (PDP decision caused the delete)
` 9 = Unsupported decision (PDP decision not supported)
` 10= Synchronize Handle Unknown
` 11= Transient Handle (stateless event)
` 12= Malformed Decision (could not recover)
` 13= Unknown COPS Object from PDP:
` Sub-code (octet 2) contains unknown object's C-Num
` and (octet 3) contains unknown object's C-Type.
`
`2.2.6 Decision Object (Decision)
`
` Decision made by the PDP. Appears in replies. The specific non-
` mandatory decision objects required in a decision to a particular
` request depend on the type of client.
`
`Durham, et al. Standards Track [Page 12]
`
`https://www.rfc-editor.org/rfc/rfc2748.html
`
`12/38
`
`12
`
`

`

`8/1/23, 1:07 PM
`
`RFC 2748: The COPS (Common Open Policy Service) Protocol
`
`RFC 2748 COPS January 2000
`
` C-Num = 6
` C-Type = 1, Decision Flags (Mandatory)
`
` 0 1 2 3
` +--------------+--------------+--------------+--------------+
` | Command-Code | Flags |
` +--------------+--------------+--------------+--------------+
`
` Commands:
` 0 = NULL Decision (No configuration data available)
` 1 = Install (Admit request/Install configuration)
` 2 = Remove (Remove request/Remove configuration)
`
` Flags:
` 0x01 = Trigger Error (Trigger error message if set)
` Note: Trigger Error is applicable to client-types that
` are capable of sending error notifications for signaled
` messages.
`
` Flag values not applicable to a given context's R-Type or
` client-type MUST be ignored by the PEP.
`
` C-Type = 2, Stateless Data
`
` This type of decision object carries additional stateless
` information that can be applied by the PEP locally. It is a
` variable length object and its internal format SHOULD be
` specified in the relevant COPS extension document for the given
` client-type. This object is optional in Decision messages and is
` interpreted relative to a given context.
`
` It is expected that even outsourcing PEPs will be able to make
` some simple stateless policy decisions locally in their LPDP. As
` this set is well known and implemented ubiquitously, PDPs are
` aware of it as well (either universally, through configuration,
` or using the Client-Open message). The PDP may also include this
` information in its decision, and the PEP MUST apply it to the
` resource allocation event that generated the request.
`
` C-Type = 3, Replacement Data
`
` This type of decision object carries replacement data that is to
` replace existing data in a signaled message. It is a variable
` length object and its internal format SHOULD be specified in the
` relev