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