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