One document matched: draft-ietf-rap-cops-frwk-01.txt
Differences from draft-ietf-rap-cops-frwk-00.txt
Internet Engineering Task Force Kwok Ho Chan
RAP Working Group Louis-Nicolas Hamer
Internet-Draft Nortel Networks
draft-ietf-rap-cops-frwk-01.txt
Expires December 2002 June 2002
An Architecture for COPS Based Policy Control
Management Framework
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.
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 an architecture for a COPS based Policy
Control Management System Framework. The architecture is designed
to be modular, allowing future modification and addition to existing
framework. The major units of the architecture are the Policy
Decision Points (PDP), the Access Edge Policy Enforcement Points
(AE_PEP), the Core Policy Enforcement Points (C_PEP). With Message
Processing Subsystem, Security Subsystem, Framework Data Model
Subsystem, and Application Specific Data Model Subsystem in each PDP
and PEP.
This document further provides a high level description of each unit
and describes the relationship among each unit. This document also
describes how the subsystems within each unit interact with each
other to provide the functionality of a Policy Control Management
System.
Internet Draft COPS Framework June 2002
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
Internet Draft COPS Framework June 2002
1. Introduction
A COPS based Policy Control Management System provides a modular and
scalable way to manage resources. Current resource management
includes resource allocation and access by means of provisioning.
The document will initially start with network QoS resources but
this is only an example application of COPS based Policy Control.
Other applications includes, but are not limited to:
1. Network Information Path Resources
2. Content Resources
This document provides examples of how Policy Controlled resource
allocation and access using provisioning can be done for each of the
above resources. It also provides some solutions for Policy
Controlled End-To-End Services.
2. Architecture Overview
The COPS based Policy Control Management System Architecture
contains two kinds of modular decompositions:
1. Functional Units
2. Data Models
These are described in more details in the following diagram and sub
sections.
Internet Draft COPS Framework June 2002
+-------------------------+
| |
| 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
Internet Draft COPS Framework June 2002
2.1 Policy Controlled Management System Units
In this architecture, we have broken up the Policy Controlled
Management System into two functionalities, each handled by the
functional units:
1. Policy Decision Point (PDP)
PDPs are the gateways to the centralized policy repository,
allowing administrative domain wide policy implementation.
2. Policy Enforcement Point (PEP)
PEPs are the gateways to the resource being managed and have
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
In this architecture, the Data Models are tied to the kinds of
resources being managed, for example:
1. For Network QoS Resources, the DiffServ PIB [DSPIB] Data Model is
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
provided as this document is being developed.
3. Policy Decision Point
3.1 Message Processing
3.2 Framework Data Model
3.3 Application Specific Data Model
4. Access Edge Policy Enforcement Point
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.
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
Internet Draft COPS Framework June 2002
integration and coordinated policy control of these functional
responsibilities.
4.1 Outsourcing by means of COPS-PR and PIBs
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.
Internet Draft COPS Framework June 2002
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
Internet Draft COPS Framework June 2002
The framework data model is as specified in [FRWKPIB].
5. Core Policy Enforcement Point
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.
6. Policy Usage Feedback
[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.
7. Security Considerations
[COPS] defines multiple mechanisms to protect a PEP-PDP connection
against security threats.
For authentication, message integrity, and replay prevention, the
COPS protocol provides an Integrity object. The Integrity object
MUST be supported by all COPS implementations. Furthermore, the PEP-
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,
Internet Draft COPS Framework June 2002
June 2002.
[DSPIB] M. Fine, K. McCloghrie, J. Seligson, K. Chan, S. Hahn, C.
Bell, A. Smith, F. Reichmeyer, "Differentiated
Services Quality of Service Policy Information Base",
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
Kwok Ho Chan
Nortel Networks
600 Technology Park Drive
Billerica, MA 01821
Phone: 978-288-8175
E-mail: khchan@nortelnetworks.com
Louis-Nicolas Hamer
Nortel Networks
PO Box 3511 Station C
Ottawa, Ontario
CANADA K1Y 4H7
Email: nhamer@nortelnetworks.com
| PAFTECH AB 2003-2026 | 2026-04-22 21:28:40 |