idnits 2.17.1 draft-ietf-rap-cops-frwk-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 9 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 2002) is 7986 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC-2119' is mentioned on line 36, but not defined == Missing Reference: 'COPS-RSVP' is mentioned on line 250, but not defined == Missing Reference: 'TLS' is mentioned on line 306, but not defined == Unused Reference: 'FRWRK' is defined on line 310, but no explicit reference was found in the text == Unused Reference: 'COPSRSVP' is defined on line 331, but no explicit reference was found in the text == Unused Reference: 'SPPI' is defined on line 335, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2753 (ref. 'FRWRK') ** Downref: Normative reference to an Historic RFC: RFC 3084 (ref. 'COPS-PR') ** Downref: Normative reference to an Historic draft: draft-ietf-rap-frameworkpib (ref. 'FRWKPIB') ** Downref: Normative reference to an Historic draft: draft-ietf-diffserv-pib (ref. 'DSPIB') ** Downref: Normative reference to an Historic RFC: RFC 3159 (ref. 'SPPI') == Outdated reference: A later version (-04) exists of draft-ietf-rap-feedback-frwk-02 ** Downref: Normative reference to an Informational draft: draft-ietf-rap-feedback-frwk (ref. 'FEEDBACKFRWK') -- No information found for draft-ietf - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'FEEDBACKPIB' -- Possible downref: Normative reference to a draft: ref. 'TEPIB' Summary: 11 errors (**), 0 flaws (~~), 8 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Kwok Ho Chan 2 RAP Working Group Louis-Nicolas Hamer 3 Internet-Draft Nortel Networks 4 draft-ietf-rap-cops-frwk-01.txt 5 Expires December 2002 June 2002 7 An Architecture for COPS Based Policy Control 8 Management Framework 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other documents 22 at any time. It is inappropriate to use Internet-Drafts as 23 reference material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Conventions used in this document 33 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 34 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 35 this document are to be interpreted as described in [RFC-2119]. 37 Abstract 39 This document describes an architecture for a COPS based Policy 40 Control Management System Framework. The architecture is designed 41 to be modular, allowing future modification and addition to existing 42 framework. The major units of the architecture are the Policy 43 Decision Points (PDP), the Access Edge Policy Enforcement Points 44 (AE_PEP), the Core Policy Enforcement Points (C_PEP). With Message 45 Processing Subsystem, Security Subsystem, Framework Data Model 46 Subsystem, and Application Specific Data Model Subsystem in each PDP 47 and PEP. 49 This document further provides a high level description of each unit 50 and describes the relationship among each unit. This document also 51 describes how the subsystems within each unit interact with each 52 other to provide the functionality of a Policy Control Management 53 System. 55 Status of this Memo................................................1 56 Conventions used in this document..................................1 57 Abstract...........................................................1 58 1. Introduction....................................................3 59 2. Architecture Overview...........................................3 60 Figure 2.1 Policy Control Management System Architecture...........4 61 2.1 Policy Controlled Management System Units......................5 62 2.2 Policy Controlled Management System Data Models................5 63 3. Policy Decision Point...........................................5 64 3.1 Message Processing.............................................5 65 3.2 Framework Data Model...........................................5 66 3.3 Application Specific Data Model................................5 67 4. Access Edge Policy Enforcement Point............................5 68 4.1 Outsourcing by means of COPS-PR and PIBs.......................6 69 4.1.1 Outsourcing using COPS-PR....................................6 70 4.1.2 Outsourcing using PIB........................................7 71 4.2 Integration of Outsourcing and Provisioning Model ............7 72 4.3 Message Processing ...........................................7 73 4.4 Framework Data Model .........................................7 74 5. Core Policy Enforcement Point...................................8 75 6. Policy Usage Feedback...........................................8 76 7. Security Considerations.........................................8 77 8. References......................................................8 78 1. Introduction 80 A COPS based Policy Control Management System provides a modular and 81 scalable way to manage resources. Current resource management 82 includes resource allocation and access by means of provisioning. 83 The document will initially start with network QoS resources but 84 this is only an example application of COPS based Policy Control. 85 Other applications includes, but are not limited to: 86 1. Network Information Path Resources 87 2. Content Resources 89 This document provides examples of how Policy Controlled resource 90 allocation and access using provisioning can be done for each of the 91 above resources. It also provides some solutions for Policy 92 Controlled End-To-End Services. 94 2. Architecture Overview 96 The COPS based Policy Control Management System Architecture 97 contains two kinds of modular decompositions: 98 1. Functional Units 99 2. Data Models 101 These are described in more details in the following diagram and sub 102 sections. 104 +-------------------------+ 105 | | 106 | PDP |<------------------+ 107 | | | 108 +-------------------------+ | 109 ^ | 110 | | 111 | | 112 | | 113 | | 114 | | 115 | | 116 | | 117 v v 118 +-------------------------+ +-------------------+ 119 |Access Edge PEP | |Core PEP | 120 |-------------------------| |-------------------| 121 |Outsource |Provision | |Provision | 122 |Data Model |Data Model | |Data Model | 123 | AccessEvent| QoS | | QoS | 124 | QoS AdmCtrl| TE | | TE | 125 | TE AdmCtrl | | | | 126 | | | | | 127 |-------------------------| |-------------------| 128 |Resources | |Resources | 129 +-------------------------+ +-------------------+ 131 Figure 2.1 Policy Control Management System Architecture 132 2.1 Policy Controlled Management System Units 134 In this architecture, we have broken up the Policy Controlled 135 Management System into two functionalities, each handled by the 136 functional units: 137 1. Policy Decision Point (PDP) 138 PDPs are the gateways to the centralized policy repository, 139 allowing administrative domain wide policy implementation. 140 2. Policy Enforcement Point (PEP) 141 PEPs are the gateways to the resource being managed and have 142 interfaces to the resource's control planes, notice this does not 143 limit the PEP to be co-located in the same machine as the 144 resources. 146 2.2 Policy Controlled Management System Data Models 148 In this architecture, the Data Models are tied to the kinds of 149 resources being managed, for example: 150 1. For Network QoS Resources, the DiffServ PIB [DSPIB] Data Model is 151 used. 152 2. For Network Information Path Resource, the TE PIB [TEPIB] Data 153 Model is used. 155 Other Data Models are being defined and more examples will be 156 provided as this document is being developed. 158 3. Policy Decision Point 160 3.1 Message Processing 162 3.2 Framework Data Model 164 3.3 Application Specific Data Model 166 4. Access Edge Policy Enforcement Point 168 The Access Edge Policy Enforcement Point's functional responsibility 169 is dictated by its relative position within the network 170 administrative domain. These includes: 171 1. Access Event Identification. 172 2. Access Event Handling. 173 3. Access Flow Identification and Aggregation. 174 4. Allocation of Resource for the individual or/and aggregated 175 flows. 177 These functional responsibilities require the usage of both the 178 Outsourcing Model and the Provisioning Model of COPS. The 179 effectiveness and efficiency of resource usage lies with the 180 integration and coordinated policy control of these functional 181 responsibilities. 183 4.1 Outsourcing by means of COPS-PR and PIBs 185 COPS-PR and PIBs were originally designed for use with the 186 Provisioning Model. But there should not be any restriction on its 187 usage, especially when it can be very beneficial to integrate both 188 the Outsourcing and Provisioning functionalities using the same 189 architecture and method. 191 4.1.1 Outsourcing using COPS-PR 193 The Outsourcing Model basically describes the usage of policy 194 control for handling of dynamic events using the COPS protocol. 195 [COPS-PR] describes its applicability to the Outsourcing Model when 196 it indicates its: 197 1. Flexibility on interaction time range. 198 2. Flexibility on the information the protocol carries, using the 199 protocol for both event notification and decision notification. 201 Using COPS-PR to support the Outsourcing Model is natural, without 202 any modification to the existing protocol [COPS-PR]. 204 For the outsourcing model purpose, COPS-PR is used: 205 1. To indicate the Event Handling capabilities of the PEP by issuing 206 Request messages. In the same way COPS-PR is normally used for 207 provisioning, using Policy Classes defined in the Framework PIB 208 [FRWKPIB]. 209 2. To provision the PEP on how to handle the events based on the 210 PEP's capabilities by issuing Decision messages. In the same way 211 COPS-PR is normally used for provisioning. Policy Classes will 212 need to be defined depending on the type of event being handled. 213 3. To indicate the correct installation of Event Handling Policies 214 by issuing Report messages. Policy Classes may be defined for 215 specific reported information. 216 4. To indicate the occurrence of the event by issuing Request 217 messages. This is using COPS-PR for outsourcing. Classes will 218 need to be defined depending on the type of event being handled. 219 5. To indicate the result of the outsourced decision by issuing 220 Decision messages. This is using COPS-PR for outsourcing. 221 Policy Classes will need to be defined depending on the type of 222 event being handled. 223 6. To indicate the correct installation of outsourced results by 224 issuing Report messages. Policy Classes may be defined for 225 specific reported information. 227 Defining new Policy Classes when necessary. 229 4.1.2 Outsourcing using PIB 231 COPS-PR adds flexibility by allowing the information exchanged to be 232 defined separately from the protocol. This flexibility plays a 233 major role when using COPS-PR for outsourcing and when coordinating 234 the policy control for both outsourcing and provisioning. 236 The differentiation between outsourcing and provisioning is in the 237 information contained in the PIB classes: 238 1. Event notification PIB classes carried by COPS Request messages. 239 2. Configuration notification for Event Handling PIB classes carried 240 by COPS Decision messages. 241 3. PEP Capabilities PIB classes carried by COPS Request messages. 242 4. Configuration notification for provisioning PIB classes carried 243 by COPS Decision messages. 244 5. Configuration status and usage feedback PIB classes carried by 245 COPS Report messages. 247 The use of PIBs for outsourcing allows the information to be 248 outsourced to be independent from the protocol. For example, the 249 handling of signaling protocols does not require changes to the 250 protocol itself contrary to the approach taken by [COPS-RSVP] . 252 This helps to achieve the goal of keeping the protocol simple and 253 stable, allowing easy interoperability. Allowing adaptation to 254 technology changes without changing the foundation of policy 255 control. 257 Depending on what is being outsourced, corresponding PIB definitions 258 needs to be created. 260 4.2 Integration of Outsourcing and Provisioning Model 262 Using COPS-PR and PIB for Outsourcing does not change how COPS-PR 263 and PIBs are used for Provisioning. It just adds to the 264 applicability of the policy control technology to solve real world 265 problems. For example, the event handling decision may include QoS 266 treatment PIB class instances to indicate the way to handle the 267 event is to mark a specific traffic flow using some kinds of QoS 268 marking. Other QoS treatments whose decisions are not outsourced 269 can still be provided using provisioning use of COPS-PR. 271 4.3 Message Processing 273 Message processing is as specified in [COPS-PR]. 275 4.4 Framework Data Model 276 The framework data model is as specified in [FRWKPIB]. 278 5. Core Policy Enforcement Point 280 Typically, core Policy Enforcement Points are configured following the 281 COPS-PR provisioning model. C PEPs are configured with general policies 282 and do not require support of the outsourcing model. 284 6. Policy Usage Feedback 286 [FEEDBACKFRWK] describes the COPS Report Type of Accounting and the 287 necessary framework for the monitoring and reporting of usage 288 feedback for an installed state. [FEEDBACKPIB] defines the policy 289 usage feedback framework PIB that specifies the policy classes 290 common for COPS feedback reports. 292 7. Security Considerations 294 [COPS] defines multiple mechanisms to protect a PEP-PDP connection 295 against security threats. 297 For authentication, message integrity, and replay prevention, the 298 COPS protocol provides an Integrity object. The Integrity object 299 MUST be supported by all COPS implementations. Furthermore, the PEP- 300 PDP connection MAY be provided by IP Security. In this case, the 301 IPSEC Authentication Header(AH) SHOULD be used for the validation of 302 the connection. 304 Additionally, IPSEC Encapsulation Security Payload (ESP) MAY be used 305 to provide both validation and secrecy. Transport Layer Security 306 [TLS] MAY be used for both connection-level validation and privacy. 308 8. References 310 [FRWRK] R. Yavatkar, D. Pendarakis, R. Guerin, "A Framework for 311 Policy-Based Admission Control", RFC 2753, January 200. 313 [COPS] D. Durhan, J. Boyle, R. Cohen, S. Herzog, R. Rajan, 314 A. Sastry, "The COPS (Common Open Policy Service) Protocol", 315 RFC 2748, January 2000. 317 [COPS-PR] K. Chan, D. Durham, S. Gai, S. Herzog, K. McCloghrie, 318 F. Reichmeyer, J. Seligson, A. Smith, R. Yavatkar, "COPS 319 Usage for Policy Provisioning," RFC 3084, March 2001. 321 [FRWKPIB] M. Fine, K. McCloghrie, J. Seligson, K. Chan, S. Hahn, R. 322 Sahita, A. Smith, F. Reichmeyer, "Framework Policy 323 Information Base", draft-ietf-rap-frameworkpib-09.txt, 324 June 2002. 326 [DSPIB] M. Fine, K. McCloghrie, J. Seligson, K. Chan, S. Hahn, C. 327 Bell, A. Smith, F. Reichmeyer, "Differentiated 328 Services Quality of Service Policy Information Base", 329 draft-ietf-diffserv-pib-09.txt, June 2002. 331 [COPSRSVP] Boyle, J., Cohen, R., Durham, D., Herzog, S., Raja, R. 332 and A. Sastry, "COPS usage for RSVP", RFC 2749, January 333 2000. 335 [SPPI] K. McCloghrie, M. Fine, J. Seligson, K. Chan, S. Hahn, 336 R. Sahita, A. Smith, F. Reichmeyer, "Structure of Policy 337 Provisioning Information," RFC 3159, August 2001. 339 [FEEDBACKFRWK] Rawlins, D., Kulkarni, A., "Framework of COPS-PR 340 Policy Usage Feedback", draft-ietf-rap-feedback-frwk-02.txt, 341 February 2002, Work in progress. 343 [FEEDBACKPIB] Rawlins, et al, "Framework of COPS-PR Policy 344 Information Base for Policy Usage Feedback", 345 draft-ietf rap - -feedback-fr-pib-03, June 2002, 346 Work in progress. 348 [TEPIB] B. Boucadair, C. Jacquenet, "An IP Traffic Engineering 349 Policy Information Base", draft-jacquenet-ip-te-pib-02.txt, 350 June 2002, Work in progress. 352 9. Author Information and Acknowledgments 354 Kwok Ho Chan 355 Nortel Networks 356 600 Technology Park Drive 357 Billerica, MA 01821 358 Phone: 978-288-8175 359 E-mail: khchan@nortelnetworks.com 361 Louis-Nicolas Hamer 362 Nortel Networks 363 PO Box 3511 Station C 364 Ottawa, Ontario 365 CANADA K1Y 4H7 366 Email: nhamer@nortelnetworks.com