rfc3084.txt
来自「RFC 的详细文档！」· 文本 代码 · 共 1,476 行 · 第 1/5 页
TXT
1,476 行
Network Working Group K. Chan
Request for Comments: 3084 J. Seligson
Category: Standards Track Nortel Networks
D. Durham
Intel
S. Gai
K. McCloghrie
Cisco
S. Herzog
IPHighway
F. Reichmeyer
PFN
R. Yavatkar
Intel
A. Smith
Allegro Networks
March 2001
COPS Usage for Policy Provisioning (COPS-PR)
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 (2001). All Rights Reserved.
Abstract
This document describes the use of the Common Open Policy Service
(COPS) protocol for support of policy provisioning (COPS-PR). This
specification is independent of the type of policy being provisioned
(QoS, Security, etc.) but focuses on the mechanisms and conventions
used to communicate provisioned information between PDPs and PEPs.
The protocol extensions described in this document do not make any
assumptions about the policy data model being communicated, but
describe the message formats and objects that carry the modeled
policy data.
Chan, et al. Standards Track [Page 1]
RFC 3084 COPS-PR March 2001
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].
Table of Contents
Glossary........................................................... 3
1. Introduction.................................................... 3
1.1. Why COPS for Provisioning?.................................... 5
1.2. Interaction between the PEP and PDP........................... 5
2. Policy Information Base (PIB)................................... 6
2.1. Rules for Modifying and Extending PIBs........................ 7
2.2. Adding PRCs to, or deprecating from, a PIB.................... 7
2.2.1. Adding or Deprecating Attributes of a BER Encoded PRC....... 8
2.3. COPS Operations Supported for a Provisioning Instance......... 8
3. Message Content................................................. 9
3.1. Request (REQ) PEP -> PDP..................................... 9
3.2. Decision (DEC) PDP -> PEP....................................10
3.3. Report State (RPT) PEP -> PDP................................12
4. COPS-PR Protocol Objects........................................13
4.1. Complete Provisioning Instance Identifier (PRID)..............14
4.2. Prefix PRID (PPRID)...........................................15
4.3. Encoded Provisioning Instance Data (EPD)......................16
4.4. Global Provisioning Error Object (GPERR)......................21
4.5. PRC Class Provisioning Error Object (CPERR)...................22
4.6. Error PRID Object (ErrorPRID).................................23
5. COPS-PR Client-Specific Data Formats............................23
5.1. Named Decision Data...........................................23
5.2. ClientSI Request Data.........................................24
5.3. Policy Provisioning Report Data...............................24
5.3.1. Success and Failure Report-Type Data Format.................24
5.3.2. Accounting Report-Type Data Format..........................25
6. Common Operation................................................26
7. Fault Tolerance.................................................28
8. Security Considerations.........................................29
9. IANA Considerations.............................................29
10. Acknowledgements...............................................30
11. References.....................................................30
12. Authors' Addresses.............................................32
13. Full Copyright Statement.......................................34
Chan, et al. Standards Track [Page 2]
RFC 3084 COPS-PR March 2001
Glossary
PRC Provisioning Class. A type of policy data.
PRI Provisioning Instance. An instance of a PRC.
PIB Policy Information Base. The database of policy
information.
PDP Policy Decision Point. See [RAP].
PEP Policy Enforcement Point. See [RAP].
PRID Provisioning Instance Identifier. Uniquely identifies an
instance of a PRC.
1. Introduction
The IETF Resource Allocation Protocol (RAP) WG has defined the COPS
(Common Open Policy Service) protocol [COPS] as a scalable protocol
that allows policy servers (PDPs) to communicate policy decisions to
network devices (PEPs). COPS was designed to support multiple types
of policy clients.
COPS is a query/response protocol that supports two common models for
policy control: Outsourcing and Configuration.
The Outsourcing model addresses the kind of events at the PEP that
require an instantaneous policy decision (authorization). In the
outsourcing scenario, the PEP delegates responsibility to an external
policy server (PDP) to make decisions on its behalf. For example, in
COPS Usage for RSVP [COPRSVP] when a RSVP reservation message
arrives, the PEP must decide whether to admit or reject the request.
It can outsource this decision by sending a specific query to its
PDP, waiting for its decision before admitting the outstanding
reservation.
The COPS Configuration model (herein described as the Provisioning
model), on the other hand, makes no assumptions of such direct 1:1
correlation between PEP events and PDP decisions. The PDP may
proactively provision the PEP reacting to external events (such as
user input), PEP events, and any combination thereof (N:M
correlation). Provisioning may be performed in bulk (e.g., entire
router QoS configuration) or in portions (e.g., updating a DiffServ
marking filter).
Network resources are often provisioned based on relatively static
SLAs (Service Level Agreements) at network boundaries. While the
Outsourcing model is dynamically paced by the PEP in real-time, the
Provisioning model is paced by the PDP in somewhat flexible timing
over a wide range of configurable aspects of the PEP.
Chan, et al. Standards Track [Page 3]
RFC 3084 COPS-PR March 2001
Edge Device Policy Server
+--------------+ +-----------+ +-----------+
| | | | | External |
| | COPS | | | Events |
| +-----+ | REQ() | +-----+ | +---+-------+
| | |----|----------|->| | | |
| | PEP | | | | PDP |<-|---------+
| | |<---|----------|--| | |
| +-----+ | COPS | +-----+ |
| | DEC() | |
+--------------+ +-----------+
Figure 1: COPS Provisioning Model
In COPS-PR, policy requests describe the PEP and its configurable
parameters (rather than an operational event). If a change occurs
in these basic parameters, an updated request is sent. Hence,
requests are issued quite infrequently. Decisions are not
necessarily mapped directly to requests, and are issued mostly
when the PDP responds to external events or PDP events (policy/SLA
updates).
This document describes the use of the COPS protocol [COPS] for
support of policy provisioning. This specification is independent
of the type of policy being provisioned (QoS, Security, etc.).
Rather, it focuses on the mechanisms and conventions used to
communicate provisioned information between PDPs and PEPs. The
data model assumed in this document is based on the concept of
Policy Information Bases (PIBs) that define the policy data. There
may be one or more PIBs for given area of policy and different
areas of policy may have different sets of PIBs.
In order to support a model that includes multiple PDPs
controlling non-overlapping areas of policy on a single PEP, the
client-type specified by the PEP to the PDP is unique for the area
of policy being managed. A single client-type for a given area of
policy (e.g., QoS) will be used for all PIBs that exist in that
area. The client should treat all the COPS-PR client-types it
supports as non-overlapping and independent namespaces where
instances MUST NOT be shared.
The examples used in this document are biased toward QoS Policy
Provisioning in a Differentiated Services (DiffServ) environment.
However, COPS-PR can be used for other types of provisioning
policies under the same framework.
Chan, et al. Standards Track [Page 4]
RFC 3084 COPS-PR March 2001
1.1. Why COPS for Provisioning?
COPS-PR has been designed within a framework that is optimized for
efficiently provisioning policies across devices, based on the
requirements defined in [RAP]. First, COPS-PR allows for efficient
transport of attributes, large atomic transactions of data, and
efficient and flexible error reporting. Second, as it has a single
connection between the policy client and server per area of policy
control identified by a COPS Client-Type, it guarantees only one
server updates a particular policy configuration at any given
time. Such a policy configuration is effectively locked, even from
local console configuration, while the PEP is connected to a PDP
via COPS. COPS uses reliable TCP transport and, thus, uses a state
sharing/synchronization mechanism and exchanges differential
updates only. If either the server or client are rebooted (or
restarted) the other would know about it quickly. Last, it is
defined as a real-time event-driven communications mechanism,
never requiring polling between the PEP and PDP.
1.2. Interaction between the PEP and PDP
When a device boots, it opens a COPS connection to its Primary
PDP. When the connection is established, the PEP sends information
about itself to the PDP in the form of a configuration request.
This information includes client specific information (e.g.,
hardware type, software release, configuration information).
During this phase the client may also specify the maximum COPS-PR
message size supported.
In response, the PDP downloads all provisioned policies that are
currently relevant to that device. On receiving the provisioned
policies, the device maps them into its local QoS mechanisms, and
installs them. If conditions change at the PDP such that the PDP
detects that changes are required in the provisioned policies
currently in effect, then the PDP sends the changes (installs,
updates, and/or deletes) in policy to the PEP, and the PEP updates
its local configuration appropriately.
If, subsequently, the configuration of the device changes (board
removed, board added, new software installed, etc.) in ways not
covered by policies already known to the PEP, then the PEP
asynchronously sends this unsolicited new information to the PDP
in an updated configuration request. On receiving this new
information, the PDP sends to the PEP any additional provisioned
policies now needed by the PEP, or removes those policies that are
no longer required.
Chan, et al. Standards Track [Page 5]
RFC 3084 COPS-PR March 2001
2. Policy Information Base (PIB)
The data carried by COPS-PR is a set of policy data. The protocol
assumes a named data structure, known as a Policy Information Base
(PIB), to identify the type and purpose of unsolicited policy
information that is "pushed" from the PDP to the PEP for
provisioning policy or sent to the PDP from the PEP as a
notification. The PIB name space is common to both the PEP and the
PDP and data instances within this space are unique within the
scope of a given Client-Type and Request-State per TCP connection
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?