idnits 2.17.1 draft-strassner-policy-terms-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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 21) being 59 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 21 pages 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 8 instances of lines with control characters in the document. ** The abstract seems to contain references ([TERMS]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 325 has weird spacing: '...ructure and m...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'DIFFARCH' -- Possible downref: Non-RFC (?) normative reference: ref. 'DIFFSERV' -- Possible downref: Non-RFC (?) normative reference: ref. 'DSFIELD' ** Obsolete normative reference: RFC 2251 (ref. 'LDAP') (Obsoleted by RFC 4510, RFC 4511, RFC 4512, RFC 4513) == Outdated reference: A later version (-03) exists of draft-ietf-rap-framework-01 ** Downref: Normative reference to an Informational draft: draft-ietf-rap-framework (ref. 'RAPFRAME') -- Possible downref: Non-RFC (?) normative reference: ref. 'SLA' Summary: 9 errors (**), 0 flaws (~~), 6 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force John Strassner 2 INTERNET DRAFT Cisco Systems 3 26 February 1999 Ed Ellesson 4 IBM 6 Terminology for describing network policy and services 7 draft-strassner-policy-terms-01.txt 9 Status of Memo 11 This document is an Internet-Draft and is in full conformance with all 12 provisions of Section 10 of RFC2026. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, and 14 its working groups. Note that other groups may also distribute working 15 documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference material 20 or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Abstract 30 Recent work in the IETF has led to multiple protocols which support 31 the classification of packets for the purposes of treating certain 32 classes or flows of packets in a particular way compared to other 33 packets. The successful wide-scale deployment of these protocols 34 depends on the ability to administer and distribute consistent policy 35 information to the multiple devices in the network which perform the 36 classification and packet conditioning or treatment. As a result, 37 there is a clear need to develop a scalable framework for policy 38 administration and distribution that will enable interoperability 39 among multiple devices and device types that must work together to 40 achieve a consistent implementation of policy. 42 Unfortunately, terms like "policy" and "service" are not 43 currently defined in sufficient detail as to enable the definition, 44 specification, and implementation of policy servers and how policy is 45 recognized and enforced at the device level. At present, both "policy" 46 and "service" (as well as other related terms) are overloaded with 47 multiple (often conflicting) meanings. This makes communication about 48 policy in general and specifically policy-based networking cumbersome 49 and difficult. 51 This document defines a set of terms that the Internet community can 52 use to exchange ideas on how policy creation, administration, 53 management, and distribution could work among policy servers and 54 multiple device types. 56 Definition of Key Word Usage 58 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 59 "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document 60 are to be interpreted as described in RFC 2119 [TERMS]. These words 61 will be capitalized to ensure that their intent in this context is 62 easily discernible. 64 Table of Contents 66 Status of this memo 1 67 Abstract 1 68 Definition of Key Word Usage 2 69 Table of Contents 2 70 1. Introduction and Motivation 4 71 2. Previously Defined Terminology 4 72 3. Areas of Terminology Conflict 8 73 4. Policy Mental Model 8 74 4.1 General Policy Architecture 8 75 4.2 How Policy Decisions Are Made 10 76 4.3 What Is A Policy (In General Terms) 10 77 4.4 Real-World Requirements of Policy 11 78 4.5 Policy Components 11 79 4.6 Policy-Based Applications And Network Policy 11 80 4.7 Difference Between Policy And Service 12 81 4.8 Need For Canonical Representation Of Policy 12 82 5. Policy Terminology 13 83 5.1 Policy 13 84 5.2 Policy Rule 13 85 5.3 Policy Condition 13 86 5.4 Policy Action 14 87 5.5 Policy Decision 14 88 5.6 Policy Behavior 14 89 5.7 Policy State 14 90 5.8 Policy Conflict 15 91 5.9 Service Level Agreement 15 92 5.10 Service Level Objective 15 93 5.11 Policy Event 16 94 5.12 Policy Evaluation 16 95 5.13 Policy Enforcement 16 96 5.14 Policy Policing 16 97 5.15 Policy Agent 16 98 5.16 Policy-Driven Service 16 99 5.17 Policy Audit 17 100 5.18 Policy Consistency Checking 17 101 5.19 Policy Discrepancy 17 102 5.20 Policy Mechanism 17 103 5.21 Policy Verification 17 104 5.22 Policy Restoration 17 105 6. Policy Example 17 106 Table of Contents (continued) 108 7. Terminology For Implementing Policy GUIs 19 109 7.1 Types Of Policies 19 110 7.2 How A Policy Is Used - Service And Usage Policies 19 111 7.3 How A Policy Is Triggered - Static vs. Dynamic Policies 19 112 7.3.1 Static Policies 19 113 7.3.2 Dynamic Policies 19 114 7.4 Classifying Policies Based On Attributes 20 115 7.5 Policy Triggers 20 116 8. Security Considerations 20 117 9. Acknowledgements 21 118 10. References 21 119 11. Authors' Addresses 21 120 1. Introduction and Motivation 122 Recent work in the IETF has led to protocols which support the 123 classification of packets for the purposes of treating certain 124 classes or flows of packets in a particular way compared to other 125 packets. The purpose of such classification may include preferential 126 queuing or dropping, admitting or denying access, or encrypting the 127 packet's payload, to cite just a few examples. Protocols that 128 explicitly support some or all of these functions include COPS, 129 RADIUS, RSVP, IntServ, DiffServ, ISSLL, DSSLL, and IPSEC. 131 The successful wide-scale deployment these and other protocols depends 132 on the ability for the administrator of a network domain to administer 133 and distribute consistent policy information to the multiple devices 134 in the network which perform the classification and packet 135 conditioning or treatment. Protocols that could be used for the 136 distribution of the policy include LDAP, COPS, SNMP, and TELNET/CLI. 137 The multiple types of devices that must work in concert across even a 138 single domain to achieve the desired policy can include hosts (clients 139 and servers), routers, switches, firewalls, bandwidth brokers, subnet 140 bandwidth managers, network access servers, and policy servers, to name 141 just a few. 143 As a result, there is a clear need to develop a scalable framework for 144 policy administration and distribution that will allow interoperability 145 among the multiple devices and device types that must work together to 146 achieve a consistent implementation of the network administrator's 147 policy. Unfortunately, terms like "policy" and "service" are not 148 currently defined in sufficient detail as to enable the definition, 149 specification, and implementation of policy servers and how policy is 150 recognized and enforced at the device level. At present, both "policy" 151 and "service" (as well as other related terms) are overloaded with 152 multiple (often conflicting) meanings. This makes communication about 153 policy in general and specifically policy-based networking cumbersome 154 and difficult. 156 This document defines a set of terms that the Internet community can 157 use to exchange ideas on how policy creation, administration, 158 management, and distribution could work among policy servers and 159 multiple device types. 161 2. Previously Defined Terminology 163 The following terms have been previously defined in other Internet 164 Drafts and are used in this draft to better define policy and policy- 165 based networking terms. 167 Definitions taken from RFC2474 (Definition of the DS Field): 169 Classifier: an entity which selects packets based on the content of 170 packet headers according to defined rules. 172 Differentiated Services Boundary: the edge of a DS domain, where 173 classifiers and traffic conditioners are likely to be deployed. A 174 differentiated services boundary can be further sub-divided into 175 ingress and egress nodes, where the ingress/egress nodes are the 176 downstream/upstream nodes of a boundary link in a given traffic 177 direction. A differentiated services boundary may be co-located 178 with a host, subject to local policy. 180 Differentiated Services Domain: a contiguous portion of the Internet 181 over which a consistent set of differentiated services policies are 182 administered in a coordinated fashion. A differentiated services 183 domain can represent different administrative domains or autonomous 184 systems, different trust regions, different network technologies 185 (e.g., cell/frame), hosts and routers, etc. 187 Differentiated Services Field: the IPv4 header TOS octet or the IPv6 188 Traffic Class octet when interpreted in conformance with the 189 definition given in this document (RFC2474). 191 Mechanism: The implementation of one or more per-hop behaviors 192 according to a particular algorithm. 194 Per-hop Behavior (PHB): a description of the externally observable 195 forwarding treatment applied at a differentiated services-compliant 196 node to a behavior aggregate. 198 Traffic Conditioning: control functions that can be applied to a 199 behavior aggregate, application flow, or other operationally useful 200 subset of traffic, e.g., routing updates. These MAY include 201 metering, policing, shaping, and packet marking. Traffic 202 conditioning is used to enforce agreements between domains and to 203 condition traffic to receive a differentiated service within a domain 204 by marking packets with the appropriate codepoint in the DS field and 205 by monitoring and altering the temporal characteristics of the 206 aggregate where necessary. 208 Traffic Conditioner: an entity that performs traffic conditioning 209 functions and which MAY contain meters, policers, shapers, and 210 markers. Traffic conditioners are typically deployed in DS boundary 211 nodes (i.e., not in interior nodes of a DS domain). 213 Service: a description of the overall treatment of (a subset of) a 214 customer's traffic across a particular domain, across a set of 215 interconnected DS domains, or end-to-end. Service descriptions are 216 covered by administrative policy and services are constructed by 217 applying traffic conditioning to create behavior aggregates which 218 experience a known PHB at each node within the DS domain. Multiple 219 services can be supported by a single per-hop behavior used in 220 concert with a range of traffic conditioners. 222 Definitions taken from RFC2475 (Differentiated Services Architecture): 224 - Differentiated Services (DS): a paradigm for providing quality- 225 of-service (QoS) in the Internet by employing a small, 226 well-defined set of building blocks from which a variety of 227 services may be built. 229 - DS-capable: capable of implementing differentiated services 230 as described in this architecture; usually used in reference 231 to a domain consisting of DS-compliant nodes. 233 - DS codepoint: a specific value of the DSCP portion of the 234 DS field, used to select a PHB. 236 - DS-compliant: enabled to support differentiated services 237 functions and behaviors as defined in [DSFIELD], this document 238 (DS Architecture), and other differentiated services documents; 239 usually used in reference to a node or device. 241 - Mechanism: a specific algorithm or operation (e.g., queueing 242 discipline) that is implemented in a node to realize a set of 243 one or more per-hop behaviors. 245 - Service: the overall treatment of a defined subset of a customer's 246 traffic within a DS domain or end-to-end. 248 - Service Level Agreement: a service contract between a customer and 249 a service provider that specifies the forwarding service a customer 250 should receive. A customer may be a user organization (source 251 domain) or another DS domain (upstream domain). A SLA may include 252 traffic conditioning rules which constitute a TCA in whole or 253 in part. 255 - Service Provisioning Policy: a policy which defines how traffic 256 conditioners are configured on DS boundary nodes and how traffic 257 streams are mapped to DS behavior aggregates to achieve a range 258 of services. 260 - Traffic conditioning: control functions performed to enforce rules 261 specified in a TCA, including metering, marking, shaping, and 262 policing. 264 - Traffic Conditioning Agreement (TCA): an agreement specifying 265 classifier rules and any corresponding traffic profiles and 266 metering, marking, discarding and/or shaping rules which are to 267 apply to the traffic streams selected by the classifier. A TCA 268 encompasses all of the traffic conditioning rules explicitly 269 specified within a SLA along with all of the rules implicit from 270 the relevant service requirements and/or from a DS domain's 271 service provisioning policy. 273 - Traffic profile: a description of the temporal properties of a 274 traffic stream such as rate and burst size. 276 - Traffic stream: an administratively significant set of one or 277 more microflows which traverse a path segment. A traffic stream 278 may consist of the set of active microflows which are selected by 279 a particular classifier. 281 Definitions taken from draft-ietf-rap-framework-01.txt: 283 - Administrative Domain: A collection of network elements under the 284 same administrative control and grouped together for administrative 285 purposes. 287 - Network Element (also called a Node): A networking device, such as 288 a router, a switch, or a hub, where resource allocation decisions 289 have to be made and the decisions have to be enforced. 291 - Policy: The combination of rules and services where rules define 292 the criteria for resource access and usage. 294 - Policy control: The application of rules to determine whether or 295 not access to a particular resource should be granted. 297 - Policy Object: Contains policy-related info such as policy 298 elements and is carried in a request or response related to resource 299 allocation decision. 301 - Policy Element: Subdivision of policy objects; contains single units 302 of information necessary for the evaluation of policy rules. A 303 single policy element carries an user or application identification 304 whereas another policy element may carry user credentials or credit 305 card information. Examples of policy elements include identity of 306 the requesting user or application, user/app credentials, etc. The 307 policy elements themselves are expected to be independent of which 308 QoS signaling protocol is used. 310 - Policy Decision Point (PDP): The point where policy decisions are 311 made. 313 - Policy Enforcement Point (PEP): The point where the policy 314 decisions are actually enforced. 316 - Policy Ignorant Node (PIN): A network element that does not 317 explicitly support policy control using the mechanisms defined in 318 this document (RAP Framework). 320 - Resource: Something of value in a network infrastructure to which 321 rules or policy criteria are first applied before access is 322 granted. Examples of resources include the buffers in a router and 323 bandwidth on an interface. 325 - Service Provider: Controls the network infrastructure and may be 326 responsible for the charging and accounting of services. 328 3. Areas of Terminology Conflict 330 Section 2 listed previously-defined terms that are related to the 331 definition of policy and policy-based networking. Of these terms, the 332 following terms that have been previously defined need more definition 333 in order to satisfy the goals of this document, and will be redefined 334 in subsequent sections of this document: 336 NAME OF THE TERM DEFINED IN PROBLEM WITH DEFINITION 337 Service [DIFFSERV], Too simplistic a definition; needs 338 [DIFFARCH] to be a more general concept 340 Policing [DIFFARCH] Too specific to traffic conditioning 342 Service Level [DIFFARCH] Too specific to traffic conditioning 343 Agreement (SLA) 345 Service [DIFFARCH] Too specific to Differentiated 346 Provisioning Services architecture 348 Policy [RAPFRAME] Too simplistic a definition 350 Policy control [RAPFRAME] Too simplistic a definition 352 Policy Object [RAPFRAME] Too specific to using QoS 353 signaling protocol as transport 355 4. Policy Mental Model 357 In the general sense, policies represent business goals and objectives, 358 and describe how resources are allocated to meet these goals and 359 objectives. With respect to networking, policy refers to the ability to 360 administer and manage network elements in order to provide a set of 361 services to clients of the network. "Clients" in this context refer to 362 users as well as applications and services. 364 An underlying assumption of this draft is that policy is stored in a 365 centralized repository. This repository may be, but is not limited to, 366 a directory accessed using the LDAP protocol [LDAP]. The rest of this 367 section defines the underlying mental model to support this definition 368 of policy and policy-based networking. 370 4.1 General Policy Architecture 372 A general architecture is shown in Figure 1 below. This architecture is 373 similar to that proposed in [SLA] with some minor modifications. 375 +-------------------+ 376 | Management Tool | 377 +-------------------+ 378 | Repository Client | 379 +--------+----------+ 380 | <--- Repository Access Protocol 381 | 382 +--------------------+ 383 | Policy Repository | 384 | (Directory Server, | 385 | Database, etc. ) | 386 +--------+-----------+ 387 | <--- Repository Access Protocol 388 | 389 +--------+------------+ 390 | Repository Client | 391 +---------------------+ 392 | Policy Decision | 393 | Point (PDP) | 394 +---------------------+ 395 | <--- Policy Protocol 396 | 397 +--------+------------+ 398 | Policy Enforcement | 399 | Point (PEP) | 400 +---------------------+ 402 Figure 1. Architectural Overview 404 The above diagram illustrates one common implementation that combines 405 the use of a policy repository, a PDP, and a PEP. This diagram is not 406 meant to imply that these entities must be located in physically 407 separate devices, nor is it meant to imply that the only protocols 408 used for communicating policy are those illustrated. Rather, it is 409 simply meant to show one possible implementation for the purpose of 410 defining the three important entities fundamental to policy: a 411 repository, a PDP, and a PEP. Please refer to [SLA] for a description 412 of how these entities are used and interact with each other. 414 It is assumed that policy decisions will always be made in the PDP and 415 implemented in the PEP. Specifically, the PEP is not able to make 416 decisions on its own. This simplifies the definition and modeling of 417 policy while leaving open the possibility for a single device to have 418 both a Local PDP (LPDP) as well as a PEP. 420 The Repository Access Protocol and the Policy Protocol are in general 421 different protocols. If the Policy Repository is a directory, then LDAP 422 is one example of a Repository Access Protocol. However, the Policy 423 Protocol could be any combination of COPS, SNMP, and Telnet/CLI. Given 424 this rich diversity, a common language is needed to represent policy 425 rules. The rest of this document defines the necessary terminology to 426 enable the definition of such a language as well as the definition of 427 how policy is defined, manipulated, and used in the PDP and the PEP. 429 4.2 How Policy Decisions Are Made 431 Any PEP that encounters an event requiring a policy-based decision 432 first asks a PDP how to handle this request. This results in one or 433 more policy decisions made by the PDP that are in turn communicated to 434 the PEP. A policy decision results in a specific set of operations that 435 either provide a service that was contracted for, or implement a change 436 in state (e.g., in the network) to provide a service. For example, if 437 the network is designed to support differentiated classes of service 438 for handling different types of traffic, network elements could send 439 requests to a policy server asking how to map a given type of traffic. 440 Policy decisions would then be made instructing what type of queueing 441 mechanisms to use to handle that traffic (as an example). 443 4.3 What Is A Policy (In General Terms) 445 A policy is formally defined as an aggregation of policy rules. Each 446 policy rule is comprised of a set of conditions and a corresponding set 447 of actions. The conditions define when the policy rule is applicable. 448 Once a policy rule is so activated, one or more actions contained by 449 that policy rule may then be executed. These actions are associated 450 with either meeting or not meeting the set of conditions specified in 451 the policy rule. 453 Policies can contain policies. This notion of hierarchy is crucial, as 454 it enables complex policies to be built from a set of simpler policies, 455 and simplifies their management. It also enables reuse of policy 456 building blocks (policy rules, conditions and actions). 458 This definition of policy can be enhanced in several different ways. 459 However, it is the feelings of the authors that as simple as possible 460 (but no simpler) a definition must first be used and put into practice 461 before more complicated definitions of policy are deployed. Otherwise, 462 it will be much harder to achieve interoperability of policy servers. 464 Policy is a relationship among the attributes of the objects maintained 465 by a policy application that control and manages one or more aspects of 466 a set of PEPs. These PEPs are used to provide a set of services that 467 are regulated by one or more policies. Key to this definition is the 468 ability to separate the specification of the set of services to be 469 provided in a vendor-independent manner from the implementation of 470 vendor-specific mechanisms that are applied to vendor-specific network 471 elements to supply those services. 473 4.4 Real-World Requirements of Policy 475 A critical part of the underlying mental model is that it must be easy 476 to detect conflicts between different policies and resolve them. The 477 simplest view of a policy is that it specifies a set of actions 478 that MUST be performed if a set of associated conditions is met. 479 Therefore, the ability to detect and resolve conflicts between policy 480 definitions (conditions as well as actions that are taken when a 481 set of conditions are met) is crucial. One way of doing this is by 482 imposing a priority and/or order on both the satisfaction of policy 483 conditions as well as the execution of policy actions. However, it 484 should be noted that priority and order are fundamental concepts of 485 distributed systems and MUST be supported irrespective of being used 486 to supply a means for policy conflict resolution. 488 4.5 Policy Components 490 Policy is comprised of the following three functions: 492 1. Decision-making. This compares the current state of the network to 493 a desired state described by an application-specific policy and 494 decides how to achieve the desired state. 495 2. Enforcement. This implements a desired policy state through a set 496 of management commands; when applied to network elements, these 497 management commands change the configuration of the device using 498 one or more mechanisms. These mechanisms MAY be vendor-specific. 499 3. Policing. This is an on-going active or passive examination of the 500 network and its constituent devices for checking network health, 501 whether policies are being satisfied, and whether clients are 502 taking unfair advantage of network services. 504 Decision-making uses static and/or dynamic data to determine if a type 505 of policy is being satisfied and, if not, what steps are needed to 506 satisfy that policy. Enforcement refers to the interpretation and 507 execution of policies by consumers who are assumed to be trustworthy. 508 Policing is the auditing of policy compliance to verify that the policy 509 consumers properly implement policies. 511 4.6 Policy-Based Applications and Network Policy 513 Policy is defined in terms of applications or processes that monitor 514 and manipulate one or more entities in order to achieve a desired goal. 515 To make the following discussion simpler to understand, this paper 516 focuses on network policies. 518 A network policy defines the relationships between clients that desire 519 services of the network and the network elements that provide those 520 services. Network Policy applications model two important things: 521 1) the state of the SLAs that they are enforcing, and/or 522 2) some part of the state of the (overall) network in order to 523 ensure that their clients will obtain the services they require 524 of (that portion of) the network. 526 Such applications will maintain a number of objects of various types, 527 each with one or more attributes. Each of these objects either models 528 the state of one or more network elements or maintains some part of the 529 internal state of the policy application. 531 Each of these state machines contains the mapping of services desired 532 by users to the network elements that provide those services. A network 533 policy, then, is a relationship among attributes of the objects 534 maintained by the policy application that controls and manages some 535 aspect of the network in terms of one or more services that the network 536 provides. Since the application models some part of the state of the 537 entity, it is also accurate to say that a policy is a statement about 538 the desired state of the entity (e.g., the requirements to maintain its 539 current state or the need to transition to a different state). 541 4.7 Difference Between Policy And Service 543 A service is the expression of a relationship between a set of objects. 544 A policy is a statement about a set of relationships between objects 545 that provide a particular service. 547 4.8 Need For Canonical Representation Of Policy 549 Policies represent business functions and goals. These correspond to 550 network services, which are provided by vendor-specific network 551 elements. The problem is that vendors will describe the same business 552 function in different ways. This is because business functions are 553 described at a necessarily high level, and are therefore subject to 554 different interpretation. Since the network will implement the services 555 that correspond to these business functions, differences in network 556 elements will exacerbate this mapping. 558 The solution is to use a canonical representation of policy. All 559 policies MUST consist of a set of policy rules, and all policy rules 560 MUST consist of a set of policy conditions and policy actions. This 561 provides a consistent meta-structure for describing policy, enabling 562 a vendor-independent exchange of policy information. However, this 563 is not enough, because the definitions of policy conditions and 564 actions could still be different, and if they were, interoperability 565 of policy servers will not be achievable. Therefore, a canonical 566 representation of policy conditions and policy actions MUST also 567 be enforced. This in turn requires a categorization of policy rule, 568 policy condition, and policy action into a set of application-specific 569 domains (e.g., RSVP and Differentiated Services would have separate 570 policy conditions and actions that identify their applicability). 571 Given a class-based implementation of policy, the above could be 572 implemented easily through defining subclasses that corresponded to 573 the different policies, policy rules, policy conditions, and policy 574 actions that were under control of the PDP. 576 5. Policy Terminology 578 The following is a set of policy terminology definitions. 580 5.1 Policy 582 A policy is a named object that represents an aggregation of Policy 583 Rules. The policy describes the overall business function(s) to be 584 accomplished, while the set of policy rules define how those business 585 functions will be met. The business function(s) correspond to one or 586 more SLOs of an SLA. 588 5.2 Policy Rule 590 A policy rule is comprised of a set of conditions and a corresponding 591 set of actions. This combination in effect defines a sequence of 592 actions to be initiated when the corresponding set of conditions is 593 either satisfied or not satisfied. For simplicity, it is recommended 594 that positive (satisfaction) and negative (unable to meet) conditions 595 be realized as separate rules that are folded into a single policy. 596 Each policy rule is a declarative statement consisting of a Boolean 597 expression that describes a situation to which the policy applies. 598 When the expression is true, one set of actions is initiated, and 599 when false, a different set of actions is initiated. This version of 600 the document will only consider the expression of a rule as a condition 601 statement (e.g., IF some set of conditions are met, THEN take this set 602 of actions, ELSE take this other set of actions). 604 5.3 Policy Condition 606 Policy Conditions consist of two parts, a policy condition type and a 607 policy condition element. This structure is aimed at satisfying the 608 need for a canonical representation of a policy condition. 610 A policy condition type is a set of predefined conditions that can be 611 attached to a policy rule for evaluation. This canonical set of 612 conditions represent common conditions that all network vendors can 613 implement. By including this canonical representation of policy 614 conditions, the resulting set of policy conditions can be exchanged 615 between multiple vendors' policy servers. This is necessary for 616 interoperability as well as for a policy server to be able to parse 617 rules to determine if any rules conflict may potentially conflict 618 with each other. A policy condition element is a policy condition type 619 instance that is being tested. Policy condition elements are related 620 together to form a Boolean expression. The relations can be one of the 621 following operators: in, not in, equal, not equal, less than, less 622 than or equal, greater than, and greater than or equal. 624 5.4 Policy Action 626 A policy action is the changing of the configuration of one or more 627 network elements in order to achieve a desired policy state. This (new) 628 policy state provides one or more (new) behaviors. As with policy 629 conditions, a policy action is comprised of two parts, a policy action 630 type and a policy action element. The policy action type defines a 631 canonical set of operations or treatments that can be given to traffic 632 flowing into the network element (e.g., deny, change code point, etc.) 633 that is vendor-independent. Similarly, the policy action element 634 specifies the type of mechanism to be used to provide the specified 635 operation or treatment. 637 5.5 Policy Decision 639 A policy decision is the abstraction of activating and evaluating one 640 or more policy rules. Each policy rule is interpreted in the context 641 of a specific request (implied or explicit) for accessing and/or using 642 one or more resources. It connotes taking one or more pre-determined 643 actions based on whether or not a given set of policy conditions were 644 satisfied. Note that the action of a policy decision MAY be to simply 645 invoke another policy rule for further processing of the request. 647 5.6 Policy Behavior 649 A policy behavior controls how traffic is treated, what network 650 resources must be utilized, and/or what network services are provided. 651 Policy behaviors define one or more mechanisms that are used to 652 implement the policy. Therefore, different devices can carry out the 653 same policy using different behaviors. For example, one router might 654 use a dropping behavior and another might use a queueing behavior 655 during times of congestion in order to satisfy an overall delivery 656 goal. Policy behaviors can include one or more of the following: 658 - permit or deny forwarding of traffic based on: 659 - source and destination address 660 - source and destination port number 661 - protocol type and options 662 - other factors specific to vendor implementations 663 - permit or deny access to a requested resource or service 664 - encrypt the header and/or the payload 665 - start or stop accounting and/or auditing 666 - start or stop logging 668 5.7 Policy State 670 A policy state is a description of the settings of one or more network 671 elements. These settings correspond to providing the set of services to 672 be provided by the network. For example, a Service Level Agreement can 673 describe services contracted for by subscribers - this corresponds to a 674 state that various network elements must be put into in order to 675 provide those services. 677 5.8 Policy Conflict 679 A policy conflict occurs when the conditions of two or more policies 680 can be simultaneously satisfied, but the actions of at least one of 681 the policies can not be simultaneously executed. This implies 682 several things: 684 - one or more policy rules of each of the policies is satisfied by 685 the same request 686 - each condition of each of the conflicting policy rules is satisfied 687 by the same request 688 - one or more actions specified by one policy conflict with one or 689 more actions specified by the other policy 691 Policy conflicts can be resolved in a number of different ways. The 692 simplest is to change the conditions and/or actions of one of the 693 policies so that it no longer conflicts with the other policies. 694 However, if the policies must remain inherently conflicting, then there 695 are a number of ways to resolve the conflict on an individual event 696 basis, including the following: 698 - apply a "match-first" criteria, wherein conflicts are resolved by 699 matching the first policy that is found 700 - apply a priority order criteria, wherein conflicts are resolved by 701 finding all policy rules which match a given event and selecting 702 only the rule with the highest priority 703 - use additional metadata to determine which rule or rules should be 704 applied. The difference between this and straight priority is that 705 priority is inherently linear, whereas metadata is not (e.g., 706 branching can be used). 708 5.9 Service Level Agreement (SLA) 710 An SLA is a service contract between a customer and a Service Provider 711 that specifies the expected operational characteristics of their 712 relationship. Example operational characteristics include the details 713 of the treatment which a customer's traffic and/or requests for 714 service should receive. The details of the operational characteristics 715 are defined in terms of Service Level Objectives (SLOs). The SLA 716 documents the agreed levels and parameters of services provided, and 717 can cover a wide range of parameters including items that effect 718 the network element and items that don't (e.g., service hours and 719 availability, user support levels, etc.). 721 5.10 Service Level Objective (SLO) 723 An SLO partitions an SLA into individual objectives that can be mapped 724 into policies that can be executed. The SLOs define metrics to enforce, 725 police, and/or monitor the SLA. Some commonly used metrics to determine 726 whether or not an SLA is being fulfilled include component system 727 availability (e.g., up-time and MTBF), performance (e.g., response 728 time), and serviceability (e.g., MTTR). 730 5.11 Policy Event 732 A policy event is a notification that triggers one or more policy 733 evaluations. A particular event may or may not initiate a policy 734 decision and/or a policy enforcement action. 736 5.12 Policy Evaluation 738 Policy evaluation is the determination of whether or not the network 739 (or a part of it) is in a desired policy state. This is usually 740 determined by processing static and/or dynamic data against one or more 741 policy rules, the key point being that the decision is made by 742 comparing definitional data stored in the policy repository with 743 current data from the network that does not have to be stored in the 744 policy repository. If it is found that the network elements are not in 745 the desired policy state, then one or more policy actions will be taken 746 to move the network elements from their current state to the desired 747 state. This is called policy enforcement. 749 5.13 Policy Enforcement 751 Policy enforcement is the action of placing the network (or a part of 752 the network) in a desired policy state using a set of management 753 commands. When this definition is applied to network elements, these 754 management commands change the configuration of the device(s) using 755 one or more mechanisms. Enforcement is carried out in the context of a 756 policy rule. 758 5.14 Policy Policing 760 Policy policing is an on-going active or passive examination of the 761 network and its constituent devices for checking network health, 762 whether policies are being satisfied, and whether clients are taking 763 unfair advantage of network services. This is done for one or more 764 of the following reasons: 766 - to monitor network statistics as part of checking network health 767 - to monitor network statistics as part of checking whether policies 768 that are currently in use are being satisfied 769 - to ensure that clients of a given set of policies are not abusing 770 their privileges 772 5.15 Policy Agent 774 A policy agent is a software module that generates and responds to 775 policy events, evaluates policies, and enforces policies. 777 5.16 Policy-Driven Service 779 A policy-driven service is a set of cooperating policy agents that 780 Define, monitor and enforce a particular policy. 782 5.17 Policy Audit 784 A policy audit matches conditions examines one or more active policies 785 to determine if their actions are being executed correctly and the 786 desired result (e.g., flow of traffic) is being carried out. This 787 is equivalent to checking the state of the network to determine the set 788 of policies that are and are not being satisfied. 790 5.18 Policy Consistency Checking 792 Policy consistency checking is an analysis of currently active policies 793 to determine their consistency or possible inconsistency with each 794 other. When an inconsistency is discovered, a policy discrepancy is 795 reported. 797 5.19 Policy Discrepancy 799 A policy discrepancy is a notification that two or more policies are in 800 actual or potential conflict in the sense that implementation of one 801 policy may prevent or otherwise adversely effect the implementation of 802 the other policies. 804 5.20 Policy Mechanism 806 A policy mechanism is a set of vendor-specific commands that configures 807 a network element to put a policy rule into effect. 809 5.21 Policy Verification 811 Policy Verification is an analysis of a policy to determine if the 812 desired state can be established and maintained for the duration of 813 the corresponding policy rule being active. 815 5.22 Policy Restoration 817 Policy Restoration is one or more actions taken to restore the system 818 to a desired policy state. This could be invoked because of a policy 819 action in response to an event, or because the current state got 820 corrupted. 822 6. Policy Example 824 This section will provide an example of the canonical use of 825 policies, policy rules, policy conditions and policy actions. 827 Assume that the following business rule is to be implemented as 828 a policy: 830 Provide the JitterFreeMPEG2 video service for authorized users 831 between authorized points, but only at agreed-upon times 833 This rule can be loosely translated as: 835 IF user IN ApprovedUsers AND service IN VideoServices AND 836 source IN VideoSources AND destination IN VideoDestinations AND 837 time IN ApprovedTimePeriods 838 THEN provide JitterFreeMPEG2 840 The policy condition is loosely translated as: 841 IF the user is a member of an approved group (ApprovedUsers) that 842 are authorized to have this service) 843 AND the service requested is one supported (VideoServicesgroup) 844 AND the source of the request is approved (in the VideoSources 845 group or has been authenticated) 846 AND the destination is approved (in the VideoDestinations group 847 or has been authenticated) 848 AND the time requested is OK (in ApprovedTimePeriods) 850 Here, the policy condition types are: 851 user, service, source, destination, and time 852 and the policy condition elements are: 853 ApprovedUsers, VideoServices, VideoSources, VideoDestinations, 854 and ApprovedTimePeriods, which are all instances of pre-defined 855 groups of objects. 857 The policy action is: 858 IF the conditions are satisfied 859 THEN provide the user with video having a QoS defined by the 860 JitterFreeMPEG2 service 862 Note that this policy could require "sub-policies" in order for it to 863 be implemented. For example, RSVP requests might be used to 864 precondition the path between VideoSources and VideoDestinations. 866 7. Terminology For Implementing Policy GUIs 868 Part of the task of defining policy terminology is to enable policies 869 to be represented in a user-friendly GUI. This section provides 870 guidelines for doing this through the introduction of additional 871 terminology designed expressly for this purpose. 873 7.1 Types Of Policies 875 An effective policy GUI MUST be able to categorize and sort policies in 876 ways that are meaningful to the user. Three are three broad means of 877 doing this, based on differentiating between how a policy is used, 878 how a policy is triggered, and the attributes of the policy. 880 7.2 How A Policy Is Used - Service And Usage Policies 882 Service and Usage Policies are a means of categorizing policies by what 883 they do and how they are used. Service policies describe services 884 available in the network. Usage policies describe which policies will 885 use which services when the usage policies are satisfied. Usage 886 policies describe particular mechanism(s) employed to either maintain 887 the current state of the object, or to transition an object from one 888 state to a new state, in order to utilize the specified services. 890 For example, the fact that a user can get a particular conditioning 891 treatment, or can use IPSEC to encrypt the payloads of traffic, are 892 both services that are provided and are represented as service 893 policies. On the other hand, differentiating between two flows and 894 assigning different services to the flows is an example of using usage 895 policies to differentiate the handling of the flows. 897 7.3 How A Policy Is Triggered - Static vs. Dynamic Policies 899 There are two fundamentally different ways that policies can be 900 applied - statically in response to a set of pre-defined conditions and 901 dynamically in response to one or more events. Both static and dynamic 902 policies use statically defined rules to determine how the policy 903 effects the objects that it is applied on. Furthermore, both types of 904 policies are applied in response to an event. The difference lies in 905 how they are applied. 907 7.3.1 Static Policies 909 Static policies apply a fixed set of actions in a pre-determined way 910 according to a set of pre-defined parameters that determine how the 911 policy is used. These parameters restrict the application of the policy 912 in some way. Examples include restricting the application of the policy 913 to only certain times of the day, week, month, or year. For instance, 914 the accounting department gets 75% of the bandwidth at the close of the 915 quarter, or anyone can use streaming video after 7:00PM. The above 916 examples each illustrate a means of restricting the application of the 917 policy based on some external data or set of conditions. 919 7.3.2 Dynamic Policies 921 This type of policy gets enforced when needed (i.e., when the network 922 gets congested, or when a user with Gold Service logs on). Although the 923 conditions of the enforcement are pre-defined, there is no set time or 924 parameter that triggers the policy. Rather, the policy is triggered 925 when a condition occurs. For example, Gold Service has one set of 926 actions when the network is not congested and an additional set of 927 actions when the network is congested. The mechanism that implements 928 the gold service doesn't change; however, additional sets of actions 929 (that ensure the delivery of Gold Service) are invoked when the network 930 is congested. Since the network can be congested in different ways, 931 different sets of actions are invoked. 933 This is fundamentally different than the static policies defined above 934 in that static policies always invoke the same set of actions the same 935 way in response to an event. Dynamic policies may invoke different 936 actions based on the semantics of the event. 938 7.4 Classifying Policies Based On Attributes 940 Policies can be classified by the attributes that they possess. This 941 includes what the policy applies to (e.g., a class of user or a certain 942 type of application) as well as certain attributes that fundamentally 943 change the applicability (conditions) and effect (actions) of the 944 policy. Examples of these include physical location. For example, if a 945 user is connected to his or her corporate Intranet through the public 946 internet, then a different security policy might be applied to that 947 communication and different restrictions may be placed on accessing 948 resources than when that user connects through the corporate network. 950 7.5 Policy Triggers 952 Some policies only come into force if certain usage conditions are met. 953 For example, if the current network bandwidth utilization is low, users 954 may be allowed to use certain applications (e.g., streaming video or 955 interactive games) that they otherwise are not allowed to use. 956 Furthermore, this privilege may be revoked if the traffic reaches a 957 certain level. 959 8. Security Considerations 961 Security and denial of service considerations are not explicitly 962 Considered in this memo, as they are appropriate for the udnerlying 963 Policy architecture. However, the policy architecture must be secure 964 as far as the following aspects are concerned. First, the mechanisms 965 proposed under the framework must minimize theft and denial of service 966 threats. Second, it must be ensured that the entities (such as PEPs and 967 PDPs) involved in policy control can verify each other's identity and 968 establish necessary trust before communicating. 970 9. Acknowledegments 972 Many thanks to the useful discussions and suggestions from the Internet 973 Community at large but especially to Andrea Westerinen, John Lee, 974 Lee Rafalow, Steve Schleimer and Fred Baker. 976 10. References 978 [TERMS] S. Bradner, "Key words for use in RFCs to Indicate 979 Requirement Levels", Internet RFC 2119, March 1997. 980 [DIFFARCH] D. Black, S. Blake, M. Carlson, E. Davies, Z. Whang, 981 W. Weiss, "An Architecture for Differentiated Services", 982 Internet draft , 983 May 1998 984 [DIFFSERV] K. Nichols and S. Blake, "Definition of the 985 Differentiated Services Field (DS Byte) in the 986 IPv4 and IPv6 Headers", Internet draft 987 , May 1998 988 [DSFIELD] K. Nichols and S. Blake, "Definition of the Differentiated 989 Services Field (DS Byte) in the IPv4 and IPv6 Headers", 990 Internet Draft , 991 May 1998. 992 [LDAP] This refers to the current collection of LDAP RFCs 993 (2251 - 2256) but especially to RFC 2251 (the protocol). 994 [RAPFRAME] R. Yavatkar, D. Pendarakis, R. Guerin, "A Framework for 995 Policy-based Admission Control", Internet Draft, 996 < draft-ietf-rap-framework-01.txt>, May 1998 997 [SLA] R. Rajan, J-C Martin, editors, "Schema for Service Level 998 Administration of Differentiated Services and 999 Integrated Services in Networks", Internet Draft 1000 , June 1998 1002 11. Authors' Addresses 1004 John Strassner 1005 Bldg 1 1006 Cisco Systems 1007 170 West Tasman Drive 1008 San Jose, CA 95134 1009 Phone: +1-408-527-1069 1010 Fax: +1-408-527-1722 1011 E-mail: johns@cisco.com 1013 Ed Ellesson 1014 JDGA/501 1015 IBM Corporation 1016 4205 S. Miami Blvd. 1017 Research Triangle Park, NC 27709 1018 Phone: +1-919-254-4115 1019 Fax: +1-919-254-6243 1020 E-mail: ellesson@raleigh.ibm.com