draft-ietf-rap-cops-frwk-00.txt   draft-ietf-rap-cops-frwk-01.txt 
Internet Engineering Task Force Kwok Ho Chan Internet Engineering Task Force Kwok Ho Chan
RAP Working Group Nortel Networks RAP Working Group Louis-Nicolas Hamer
Internet-Draft Internet-Draft Nortel Networks
Expiration: February 2002 draft-ietf-rap-cops-frwk-01.txt
draft-ietf-rap-cops-frwk-00.txt Expires December 2002 June 2002
An Architecture for COPS Based Policy Control An Architecture for COPS Based Policy Control
Management Framework Management Framework
Last Updated: 7/13/01
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 40 skipping to change at line 38
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Conventions used in this document Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in [RFC-2119]. this document are to be interpreted as described in [RFC-2119].
Status of this Memo 1
Conventions used in this document 1
Abstract 3
1. Introduction 3
2. Architecture Overview 3
2.1 Policy Controlled Management System Units 3
2.2 Policy Controlled Management System Data Models 4
3. Policy Decision Point 4
3.1 Message Processing 4
3.2 Security 4
3.3 Framework Data Model 4
3.4 Application Specific Data Model 4
4. Access Edge Policy Enforcement Point 4
4.1 Message Processing 4
4.2 Security 4
4.3 Framework Data Model 4
4.4 Application Specific Data Model 4
5. Core Policy Enforcement Point 4
5.1 Message Processing 4
5.2 Security 4
5.3 Framework Data Model 4
5.4 Application Specific Data Model 4
6. References 4
Abstract Abstract
This document describes an architecture for a COPS based Policy This document describes an architecture for a COPS based Policy
Control Management System Framework. The architecture is designed Control Management System Framework. The architecture is designed
to be modular, allowing future modification and addition to existing to be modular, allowing future modification and addition to existing
framework. The major units of the architecture are the Policy framework. The major units of the architecture are the Policy
Decision Points (PDP), the Access Edge Policy Enforcement Points Decision Points (PDP), the Access Edge Policy Enforcement Points
(PEP), the Core Policy Enforcement Points. With Message Processing (AE_PEP), the Core Policy Enforcement Points (C_PEP). With Message
Subsystem, Security Subsystem, Framework Data Model Subsystem, and Processing Subsystem, Security Subsystem, Framework Data Model
Application Specific Data Model Subsystem in each PDP and PEP. Subsystem, and Application Specific Data Model Subsystem in each PDP
and PEP.
This document further provides a high level description of each unit This document further provides a high level description of each unit
and describes the relationship among each unit. This document also and describes the relationship among each unit. This document also
describes how the subsystems within each unit interact with each describes how the subsystems within each unit interact with each
other to provide the functionality of a Policy Control Management other to provide the functionality of a Policy Control Management
System. System.
Status of this Memo................................................1
Conventions used in this document..................................1
Abstract...........................................................1
1. Introduction....................................................3
2. Architecture Overview...........................................3
Figure 2.1 Policy Control Management System Architecture...........4
2.1 Policy Controlled Management System Units......................5
2.2 Policy Controlled Management System Data Models................5
3. Policy Decision Point...........................................5
3.1 Message Processing.............................................5
3.2 Framework Data Model...........................................5
3.3 Application Specific Data Model................................5
4. Access Edge Policy Enforcement Point............................5
4.1 Outsourcing by means of COPS-PR and PIBs.......................6
4.1.1 Outsourcing using COPS-PR....................................6
4.1.2 Outsourcing using PIB........................................7
4.2 Integration of Outsourcing and Provisioning Model ............7
4.3 Message Processing ...........................................7
4.4 Framework Data Model .........................................7
5. Core Policy Enforcement Point...................................8
6. Policy Usage Feedback...........................................8
7. Security Considerations.........................................8
8. References......................................................8
1. Introduction 1. Introduction
COPS based Policy Control Management System provides a modular and A COPS based Policy Control Management System provides a modular and
scalable way to management resource access and provisioning. We scalable way to manage resources. Current resource management
started with network QoS resources but this is only the initial includes resource allocation and access by means of provisioning.
application of COPS based Policy Control. Other applications The document will initially start with network QoS resources but
includes but not limited to: this is only an example application of COPS based Policy Control.
1. Network Plumbing Resource Other applications includes, but are not limited to:
2. Content Resource 1. Network Information Path Resources
2. Content Resources
This document provides examples on how Policy Controlled access and This document provides examples of how Policy Controlled resource
provisioning can be done for each of the above resources. Providing allocation and access using provisioning can be done for each of the
some solutions for Policy Controlled End-To-End Services. above resources. It also provides some solutions for Policy
Controlled End-To-End Services.
2. Architecture Overview 2. Architecture Overview
The COPS based Policy Control Management System Architecture The COPS based Policy Control Management System Architecture
contains two kinds of modular decompositions: contains two kinds of modular decompositions:
1. Functional Units 1. Functional Units
2. Data Models 2. Data Models
As described in more details in the following sub sections. These are described in more details in the following diagram and sub
sections.
+-------------------------+
| |
| PDP |<------------------+
| | |
+-------------------------+ |
^ |
| |
| |
| |
| |
| |
| |
| |
v v
+-------------------------+ +-------------------+
|Access Edge PEP | |Core PEP |
|-------------------------| |-------------------|
|Outsource |Provision | |Provision |
|Data Model |Data Model | |Data Model |
| AccessEvent| QoS | | QoS |
| QoS AdmCtrl| TE | | TE |
| TE AdmCtrl | | | |
| | | | |
|-------------------------| |-------------------|
|Resources | |Resources |
+-------------------------+ +-------------------+
Figure 2.1 Policy Control Management System Architecture
2.1 Policy Controlled Management System Units 2.1 Policy Controlled Management System Units
In this architecture, we have broken up the Policy Controlled In this architecture, we have broken up the Policy Controlled
Management System into two functionalities, each handled by the Management System into two functionalities, each handled by the
functional units: functional units:
1. Policy Decision Point (PDP) 1. Policy Decision Point (PDP)
PDPs are the gateways to the centralized policy repository, PDPs are the gateways to the centralized policy repository,
allowing administrative domain wide policy implementation. allowing administrative domain wide policy implementation.
2. Policy Enforcement Point (PEP) 2. Policy Enforcement Point (PEP)
PEPs are the gateways to the resource being managed and have PEPs are the gateways to the resource being managed and have
direct interfaces to the resource's control planes. interfaces to the resource's control planes, notice this does not
limit the PEP to be co-located in the same machine as the
resources.
2.2 Policy Controlled Management System Data Models 2.2 Policy Controlled Management System Data Models
In this architecture, the Data Models are tied to the kinds of In this architecture, the Data Models are tied to the kinds of
resource being managed, for example: resources being managed, for example:
1. For Network QoS Resource, the DiffServ PIB Data Model is used. 1. For Network QoS Resources, the DiffServ PIB [DSPIB] Data Model is
2. For Network Plumbing Resource, the TE PIB Data Model is used. used.
2. For Network Information Path Resource, the TE PIB [TEPIB] Data
Model is used.
Other Data Models are being defined and more examples will be Other Data Models are being defined and more examples will be
provided as this document is being developed. provided as this document is being developed.
3. Policy Decision Point 3. Policy Decision Point
3.1 Message Processing 3.1 Message Processing
3.2 Security 3.2 Framework Data Model
3.3 Framework Data Model
3.4 Application Specific Data Model 3.3 Application Specific Data Model
4. Access Edge Policy Enforcement Point 4. Access Edge Policy Enforcement Point
4.1 Message Processing The Access Edge Policy Enforcement Point's functional responsibility
is dictated by its relative position within the network
administrative domain. These includes:
1. Access Event Identification.
2. Access Event Handling.
3. Access Flow Identification and Aggregation.
4. Allocation of Resource for the individual or/and aggregated
flows.
4.2 Security These functional responsibilities require the usage of both the
Outsourcing Model and the Provisioning Model of COPS. The
effectiveness and efficiency of resource usage lies with the
integration and coordinated policy control of these functional
responsibilities.
4.3 Framework Data Model 4.1 Outsourcing by means of COPS-PR and PIBs
4.4 Application Specific Data Model COPS-PR and PIBs were originally designed for use with the
Provisioning Model. But there should not be any restriction on its
usage, especially when it can be very beneficial to integrate both
the Outsourcing and Provisioning functionalities using the same
architecture and method.
4.1.1 Outsourcing using COPS-PR
The Outsourcing Model basically describes the usage of policy
control for handling of dynamic events using the COPS protocol.
[COPS-PR] describes its applicability to the Outsourcing Model when
it indicates its:
1. Flexibility on interaction time range.
2. Flexibility on the information the protocol carries, using the
protocol for both event notification and decision notification.
Using COPS-PR to support the Outsourcing Model is natural, without
any modification to the existing protocol [COPS-PR].
For the outsourcing model purpose, COPS-PR is used:
1. To indicate the Event Handling capabilities of the PEP by issuing
Request messages. In the same way COPS-PR is normally used for
provisioning, using Policy Classes defined in the Framework PIB
[FRWKPIB].
2. To provision the PEP on how to handle the events based on the
PEP's capabilities by issuing Decision messages. In the same way
COPS-PR is normally used for provisioning. Policy Classes will
need to be defined depending on the type of event being handled.
3. To indicate the correct installation of Event Handling Policies
by issuing Report messages. Policy Classes may be defined for
specific reported information.
4. To indicate the occurrence of the event by issuing Request
messages. This is using COPS-PR for outsourcing. Classes will
need to be defined depending on the type of event being handled.
5. To indicate the result of the outsourced decision by issuing
Decision messages. This is using COPS-PR for outsourcing.
Policy Classes will need to be defined depending on the type of
event being handled.
6. To indicate the correct installation of outsourced results by
issuing Report messages. Policy Classes may be defined for
specific reported information.
Defining new Policy Classes when necessary.
4.1.2 Outsourcing using PIB
COPS-PR adds flexibility by allowing the information exchanged to be
defined separately from the protocol. This flexibility plays a
major role when using COPS-PR for outsourcing and when coordinating
the policy control for both outsourcing and provisioning.
The differentiation between outsourcing and provisioning is in the
information contained in the PIB classes:
1. Event notification PIB classes carried by COPS Request messages.
2. Configuration notification for Event Handling PIB classes carried
by COPS Decision messages.
3. PEP Capabilities PIB classes carried by COPS Request messages.
4. Configuration notification for provisioning PIB classes carried
by COPS Decision messages.
5. Configuration status and usage feedback PIB classes carried by
COPS Report messages.
The use of PIBs for outsourcing allows the information to be
outsourced to be independent from the protocol. For example, the
handling of signaling protocols does not require changes to the
protocol itself contrary to the approach taken by [COPS-RSVP] .
This helps to achieve the goal of keeping the protocol simple and
stable, allowing easy interoperability. Allowing adaptation to
technology changes without changing the foundation of policy
control.
Depending on what is being outsourced, corresponding PIB definitions
needs to be created.
4.2 Integration of Outsourcing and Provisioning Model
Using COPS-PR and PIB for Outsourcing does not change how COPS-PR
and PIBs are used for Provisioning. It just adds to the
applicability of the policy control technology to solve real world
problems. For example, the event handling decision may include QoS
treatment PIB class instances to indicate the way to handle the
event is to mark a specific traffic flow using some kinds of QoS
marking. Other QoS treatments whose decisions are not outsourced
can still be provided using provisioning use of COPS-PR.
4.3 Message Processing
Message processing is as specified in [COPS-PR].
4.4 Framework Data Model
The framework data model is as specified in [FRWKPIB].
5. Core Policy Enforcement Point 5. Core Policy Enforcement Point
5.1 Message Processing Typically, core Policy Enforcement Points are configured following the
COPS-PR provisioning model. C PEPs are configured with general policies
and do not require support of the outsourcing model.
5.2 Security 6. Policy Usage Feedback
5.3 Framework Data Model [FEEDBACKFRWK] describes the COPS Report Type of Accounting and the
necessary framework for the monitoring and reporting of usage
feedback for an installed state. [FEEDBACKPIB] defines the policy
usage feedback framework PIB that specifies the policy classes
common for COPS feedback reports.
5.4 Application Specific Data Model 7. Security Considerations
6. References [COPS] defines multiple mechanisms to protect a PEP-PDP connection
against security threats.
[FWPIB] M. Fine, K. McCloghrie, J. Seligson, K. Chan, S. Hahn, R. For authentication, message integrity, and replay prevention, the
Sahita, A. Smith, F. Reichmeyer, Framework Policy COPS protocol provides an Integrity object. The Integrity object
Information Base," MUST be supported by all COPS implementations. Furthermore, the PEP-
draft-ietf-rap-frameworkpib-04.txt, March 1, 2001. PDP connection MAY be provided by IP Security. In this case, the
IPSEC Authentication Header(AH) SHOULD be used for the validation of
the connection.
Additionally, IPSEC Encapsulation Security Payload (ESP) MAY be used
to provide both validation and secrecy. Transport Layer Security
[TLS] MAY be used for both connection-level validation and privacy.
8. References
[FRWRK] R. Yavatkar, D. Pendarakis, R. Guerin, "A Framework for
Policy-Based Admission Control", RFC 2753, January 200.
[COPS] D. Durhan, J. Boyle, R. Cohen, S. Herzog, R. Rajan,
A. Sastry, "The COPS (Common Open Policy Service) Protocol",
RFC 2748, 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," RFC 3084, March 2001.
[FRWKPIB] M. Fine, K. McCloghrie, J. Seligson, K. Chan, S. Hahn, R.
Sahita, A. Smith, F. Reichmeyer, "Framework Policy
Information Base", draft-ietf-rap-frameworkpib-09.txt,
June 2002.
[DSPIB] M. Fine, K. McCloghrie, J. Seligson, K. Chan, S. Hahn, C. [DSPIB] M. Fine, K. McCloghrie, J. Seligson, K. Chan, S. Hahn, C.
Bell, A. Smith, F. Reichmeyer, "Differentiated Bell, A. Smith, F. Reichmeyer, "Differentiated
Services Quality of Service Policy Information Base," Services Quality of Service Policy Information Base",
draft-ietf-diffserv-pib-03.txt, March 2, 2001. draft-ietf-diffserv-pib-09.txt, June 2002.
[COPSRSVP] Boyle, J., Cohen, R., Durham, D., Herzog, S., Raja, R.
and A. Sastry, "COPS usage for RSVP", RFC 2749, January
2000.
[SPPI] K. McCloghrie, M. Fine, J. Seligson, K. Chan, S. Hahn,
R. Sahita, A. Smith, F. Reichmeyer, "Structure of Policy
Provisioning Information," RFC 3159, August 2001.
[FEEDBACKFRWK] Rawlins, D., Kulkarni, A., "Framework of COPS-PR
Policy Usage Feedback", draft-ietf-rap-feedback-frwk-02.txt,
February 2002, Work in progress.
[FEEDBACKPIB] Rawlins, et al, "Framework of COPS-PR Policy
Information Base for Policy Usage Feedback",
draft-ietf rap - -feedback-fr-pib-03, June 2002,
Work in progress.
[TEPIB] B. Boucadair, C. Jacquenet, "An IP Traffic Engineering
Policy Information Base", draft-jacquenet-ip-te-pib-02.txt,
June 2002, Work in progress.
9. Author Information and Acknowledgments 9. Author Information and Acknowledgments
Kwok Ho Chan Kwok Ho Chan
Nortel Networks Nortel Networks
600 Technology Park Drive 600 Technology Park Drive
Billerica, MA 01821 Billerica, MA 01821
Phone: 978-288-8175 Phone: 978-288-8175
E-mail: khchan@nortelnetworks.com E-mail: khchan@nortelnetworks.com
Louis-Nicolas Hamer
Nortel Networks
PO Box 3511 Station C
Ottawa, Ontario
CANADA K1Y 4H7
Email: nhamer@nortelnetworks.com
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/