idnits 2.17.1 draft-strassner-policy-terms-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-16) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 20 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: ---------------------------------------------------------------------------- == 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: 11 errors (**), 0 flaws (~~), 4 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 5 August 1998 Ed Ellesson 4 IBM 6 Terminology for describing network policy and services 7 draft-strassner-policy-terms-00.txt 9 Status of Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six 17 months and may be updated, replaced, or obsoleted by other documents 18 at any time. It is inappropriate to use Internet-Drafts as reference 19 material or to cite them other than as "work in progress." 21 To learn the current status of any Internet-Draft, please check the 22 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 23 Directories on ftp.ietf.org (US East Coast), nic.nordu.net 24 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 26 Abstract 28 Recent work in the IETF has led to multiple protocols which support 29 the classification of packets for the purposes of treating certain 30 classes or flows of packets in a particular way compared to other 31 packets. The successful wide-scale deployment of these protocols 32 depends on the ability to administer and distribute consistent policy 33 information to the multiple devices in the network which perform the 34 classification and packet conditioning or treatment. As a result, 35 there is a clear need to develop a scalable framework for policy 36 administration and distribution that will enable interoperability 37 among multiple devices and device types that must work together to 38 achieve a consistent implementation of policy. 40 Unfortunately, terms like 'policy' and 'service' are not 41 currently defined in sufficient detail as to enable the definition, 42 specification, and implementation of policy servers and how policy is 43 recognized and enforced at the device level. At present, both 'policy' 44 and 'service' (as well as other related terms) are overloaded with 45 multiple (often conflicting) meanings. This makes communication about 46 policy in general and specifically policy-based networking cumbersome 47 and difficult. 49 This document defines a set of terms that the Internet community can 50 use to exchange ideas on how policy creation, administration, 51 management, and distribution could work among policy servers and 52 multiple device types. 54 Definition of Key Word Usage 56 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 57 "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document 58 are to be interpreted as described in RFC 2119 [TERMS]. These words 59 will be capitalized to ensure that their intent in this context is 60 easily discernible. 62 Table of Contents 64 Status of this memo 1 65 Abstract 1 66 Definition of Key Word Usage 2 67 Table of Contents 2 68 1. Introduction and Motivation 4 69 2. Previously Defined Terminology 4 70 3. Areas of Terminology Conflict 7 71 4. Policy Mental Model 7 72 4.1 General Policy Architecture 8 73 4.2 How Policy Decisions Are Made 9 74 4.3 What Is A Policy (In General Terms) 9 75 4.4 Real-World Requirements of Policy 10 76 4.5 Policy Components 10 77 4.6 Policy-Based Applications And Network Policy 10 78 4.7 Difference Between Policy And Service 11 79 4.8 Need For Canonical Representation Of Policy 11 80 5. Policy Terminology 12 81 5.1 Policy 12 82 5.2 Policy Rule 12 83 5.3 Policy Condition 12 84 5.4 Policy Action 13 85 5.5 Policy Decision 13 86 5.6 Policy Behavior 13 87 5.7 Policy State 13 88 5.8 Policy Conflict 14 89 5.9 Service Level Agreement 14 90 5.10 Service Level Objective 14 91 5.11 Policy Event 15 92 5.12 Policy Evaluation 15 93 5.13 Policy Enforcement 15 94 5.14 Policy Policing 15 95 5.15 Policy Agent 15 96 5.16 Policy-Driven Service 15 97 5.17 Policy Audit 16 98 5.18 Policy Consistency Checking 16 99 5.19 Policy Discrepancy 16 100 5.20 Policy Mechanism 16 101 5.21 Policy Verification 16 102 5.22 Policy Restoration 16 103 6. Policy Example 16 104 Table of Contents (continued) 106 7. Terminology For Implementing Policy GUIs 18 107 7.1 Types Of Policies 18 108 7.2 How A Policy Is Used - Service And Usage Policies 18 109 7.3 How A Policy Is Triggered - Static vs. Dynamic Policies 18 110 7.3.1 Static Policies 18 111 7.3.2 Dynamic Policies 19 112 7.4 Classifying Policies Based On Attributes 19 113 7.5 Policy Triggers 19 114 8. Security Considerations 19 115 9. Acknowledgements 20 116 10. References 20 117 11. Author's Addresses 20 118 1. Introduction and Motivation 120 Recent work in the IETF has led to protocols which support the 121 classification of packets for the purposes of treating certain 122 classes or flows of packets in a particular way compared to other 123 packets. The purpose of such classification may include preferential 124 queuing or dropping, admitting or denying access, or encrypting the 125 packet's payload, to cite just a few examples. Protocols that 126 explicitly support some or all of these functions include COPS, 127 RADIUS, RSVP, IntServ, DiffServ, ISSLL, DSSLL, and IPSEC. 129 The successful wide-scale deployment these and other protocols depends 130 on the ability for the administrator of a network domain to administer 131 and distribute consistent policy information to the multiple devices 132 in the network which perform the classification and packet 133 conditioning or treatment. Protocols that could be used for the 134 distribution of the policy include LDAP, COPS, SNMP, and TELNET/CLI. 135 The multiple types of devices that must work in concert across even a 136 single domain to achieve the desired policy can include hosts (clients 137 and servers), routers, switches, firewalls, bandwidth brokers, subnet 138 bandwidth managers, network access servers, and policy servers, to name 139 just a few. 141 As a result, there is a clear need to develop a scalable framework for 142 policy administration and distribution that will allow interoperability 143 among the multiple devices and device types that must work together to 144 achieve a consistent implementation of the network administrator's 145 policy. Unfortunately, terms like "policy" and "service" are not 146 currently defined in sufficient detail as to enable the definition, 147 specification, and implementation of policy servers and how policy is 148 recognized and enforced at the device level. At present, both "policy" 149 and "service" (as well as other related terms) are overloaded with 150 multiple (often conflicting) meanings. This makes communication about 151 policy in general and specifically policy-based networking cumbersome 152 and difficult. 154 This document defines a set of terms that the Internet community can 155 use to exchange ideas on how policy creation, administration, 156 management, and distribution could work among policy servers and 157 multiple device types. 159 2. Previously Defined Terminology 161 The following terms have been previously defined in other Internet 162 Drafts and are used in this draft to better define policy and policy- 163 based networking terms. 165 Definitions taken from draft-ietf-diffserv-00.txt: 166 - Service: a description of the overall treatment of a customer's 167 traffic within a particular domain or end-to-end. 169 Definitions taken from draft-ietf-diffserv-arch-00.txt 170 - Differentiated Services (DS): a paradigm for providing quality- 171 of-service (QoS) in the Internet by employing a small, 172 well-defined set of building blocks from which a variety of 173 services may be built. 175 - DS behavior aggregate: a stream of packets that have the same 176 DS codepoint. 178 - DS capable [node]: [a node] able to support differentiated 179 services functions and behaviors as defined in [DSFIELD], 180 [DIFFARCH], and other [related] documents. 182 - DS codepoint: a specific bit-pattern of the DS field. 184 - Mechanism: a specific algorithm or operation (e.g., queueing 185 discipline) that is implemented in a node to realize a set of one 186 or more per-hop behaviors. 188 - Per-Hop-Behavior (PHB): the externally observable forwarding 189 behavior applied at a DS capable node to a DS behavior aggregate. 191 - Policing: the process of applying traffic conditioning functions 192 such as marking or discarding to a traffic stream in accordance 193 with the state of a corresponding meter. 195 - Service: the overall treatment of a defined subset of a customer's 196 traffic within a DS domain or end-to-end. 198 - Service Level Agreement (SLA): a service contract between a 199 customer and a service provider that specifies the details of a 200 TCA and the corresponding service behavior a customer should 201 receive. A customer may be a user organization or another 202 DS domain. 204 - Service Provisioning: a policy which defines how traffic Policy 205 conditioners are configured on DS edge nodes and how traffic 206 streams are mapped to DS behavior aggregates to achieve a range 207 of service behaviors. 209 - Traffic conditioning: control functions performed to enforce rules 210 specified in a TCA and to prepare traffic for differentiated 211 services, including classifying, metering, marking, policing, and 212 shaping. 214 - Traffic Conditioning Agreement (TCA): an agreement specifying 215 classifier rules and the corresponding traffic profiles and 216 metering, marking, policing and/or shaping rules which are to 217 apply to the traffic streams selected by the classifier. 219 Definitions taken from draft-ietf-rap-framework-01.txt: 220 - Administrative Domain: A collection of network elements under the 221 same administrative control and grouped together for administrative 222 purposes. 224 - Network Element (also called a Node): A networking device, such as 225 a router, a switch, or a hub, where resource allocation decisions 226 have to be made and the decisions have to be enforced. 228 - Policy: The combination of rules and services where rules define 229 the criteria for resource access and usage. 231 - Policy control: The application of rules to determine whether or 232 not access to a particular resource should be granted. 234 - Policy Object: Contains policy-related info such as policy 235 elements and is carried by the QoS signaling protocol. 237 - Policy Element: Subdivision of policy objects; contains single 238 units of information necessary for the evaluation of policy rules. 240 - Policy Decision Point (PDP): The point where policy decisions 241 are made. 243 - Policy Enforcement Point (PEP): The point where the policy 244 decisions are actually enforced. 246 - Policy Ignorant Node (PIN): A network element that does not 247 explicitly support policy control using the mechanisms defined in 248 this document. 250 - Resource: Something of value in a network infrastructure to which 251 rules or policy criteria are first applied before access is 252 granted. 254 - Service Provider: Controls the network infrastructure and may be 255 responsible for the charging and accounting of services. 257 - Soft State Model - Soft state is a form of the stateful model that 258 times out installed state at a PEP or PDP. 260 - Installed State: A new and unique request made from a PEP to a PDP 261 that must be explicitly deleted. 263 - Trusted Node: A node that is within the boundaries of an 264 administrative domain (AD) and is trusted in the sense that the 265 admission control requests from such a node do not necessarily need 266 a PDP decision. 268 3. Areas of Terminology Conflict 270 Section 2 listed previously-defined terms that are related to the 271 definition of policy and policy-based networking. Of these terms, the 272 following terms that have been previously defined need more definition 273 in order to satisfy the goals of this document, and will be redefined 274 in subsequent sections of this document: 276 NAME OF THE TERM DEFINED IN PROBLEM WITH DEFINITION 277 Service [DIFFSERV], Too simplistic a definition; needs 278 [DIFFARCH] to be a more general concept 280 Policing [DIFFARCH] Too specific to traffic conditioning 282 Service Level [DIFFARCH] Too specific to traffic conditioning 283 Agreement (SLA) 285 Service [DIFFARCH] Too specific to Differentiated 286 Provisioning Services architecture 288 Policy [RAPFRAME] Too simplistic a definition 290 Policy control [RAPFRAME] Too simplistic a definition 292 Policy Object [RAPFRAME] Too specific to using QoS 293 signaling protocol as transport 295 4. Policy Mental Model 297 In the general sense, policies represent business goals and objectives, 298 and describe how resources are allocated to meet these goals and 299 objectives. With respect to networking, policy refers to the ability to 300 administer and manage network elements in order to provide a set of 301 services to clients of the network. "Clients" in this context refer to 302 users as well as applications and services. 304 An underlying assumption of this draft is that policy is stored in a 305 centralized repository. This repository may be, but is not limited to, 306 a directory accessed using the LDAP protocol [LDAP]. The rest of this 307 section defines the underlying mental model to support this definition 308 of policy and policy-based networking. 310 4.1 General Policy Architecture 312 A general architecture is shown in Figure 1 below. This architecture is 313 similar to that proposed in [SLA] with some minor modifications. 315 +-------------------+ 316 | Management Tool | 317 +-------------------+ 318 | Repository Client | 319 +--------+----------+ 320 | <--- Repository Access Protocol 321 | 322 +--------------------+ 323 | Policy Repository | 324 | (Directory Server, | 325 | Database, etc. ) | 326 +--------+-----------+ 327 | <--- Repository Access Protocol 328 | 329 +--------+------------+ 330 | Repository Client | 331 +---------------------+ 332 | Policy Decision | 333 | Point (PDP) | 334 +---------------------+ 335 | <--- Policy Protocol 336 | 337 +--------+------------+ 338 | Policy Enforcement | 339 | Point (PEP) | 340 +---------------------+ 342 Figure 1. Architectural Overview 344 The above diagram illustrates one common implementation that combines 345 the use of a policy repository, a PDP, and a PEP. This diagram is not 346 meant to imply that these entities must be located in physically 347 separate devices, nor is it meant to imply that the only protocols 348 used for communicating policy are those illustrated. Rather, it is 349 simply meant to show one possible implementation for the purpose of 350 defining the three important entities fundamental to policy: a 351 repository, a PDP, and a PEP. Please refer to [SLA] for a description 352 of how these entities are used and interact with each other. 354 It is assumed that policy decisions will always be made in the PDP and 355 implemented in the PEP. Specifically, the PEP is not able to make 356 decisions on its own. This simplifies the definition and modeling of 357 policy while leaving open the possibility for a single device to have 358 both a Local PDP (LPDP) as well as a PEP. 360 The Repository Access Protocol and the Policy Protocol are in general 361 different protocols. If the Policy Repository is a directory, then LDAP 362 is one example of a Repository Access Protocol. However, the Policy 363 Protocol could be any combination of COPS, SNMP, and Telnet/CLI. Given 364 this rich diversity, a common language is needed to represent policy 365 rules. The rest of this document defines the necessary terminology to 366 enable the definition of such a language as well as the definition of 367 how policy is defined, manipulated, and used in the PDP and the PEP. 369 4.2 How Policy Decisions Are Made 371 Any PEP that encounters an event requiring a policy-based decision 372 first asks a PDP how to handle this request. This results in one or 373 more policy decisions made by the PDP that are in turn communicated to 374 the PEP. A policy decision results in a specific set of operations that 375 either provide a service that was contracted for, or implement a change 376 in state (e.g., in the network) to provide a service. For example, if 377 the network is designed to support differentiated classes of service 378 for handling different types of traffic, network elements could send 379 requests to a policy server asking how to map a given type of traffic. 380 Policy decisions would then be made instructing what type of queueing 381 mechanisms to use to handle that traffic (as an example). 383 4.3 What Is A Policy (In General Terms) 385 A policy is formally defined as an aggregation of policy rules. Each 386 policy rule is comprised of a set of conditions and a corresponding set 387 of actions. The conditions define when the policy rule is applicable. 388 Once a policy rule is so activated, one or more actions contained by 389 that policy rule may then be executed. These actions are associated 390 with either meeting or not meeting the set of conditions specified in 391 the policy rule. 393 Policies can contain policies. This notion of hierarchy is crucial, as 394 it enables complex policies to be built from a set of simpler policies, 395 and simplifies their management. It also enables reuse of policy 396 building blocks (policy rules, conditions and actions). 398 This definition of policy can be enhanced in several different ways. 399 However, it is the feelings of the authors that as simple as possible 400 (but no simpler) a definition must first be used and put into practice 401 before more complicated definitions of policy are deployed. Otherwise, 402 it will be much harder to achieve interoperability of policy servers. 404 Policy is a relationship among the attributes of the objects maintained 405 by a policy application that control and manages one or more aspects of 406 a set of PEPs. These PEPs are used to provide a set of services that 407 are regulated by one or more policies. Key to this definition is the 408 ability to separate the specification of the set of services to be 409 provided in a vendor-independent manner from the implementation of 410 vendor-specific mechanisms that are applied to vendor-specific network 411 elements to supply those services. 413 4.4 Real-World Requirements of Policy 415 A critical part of the underlying mental model is that it must be easy 416 to detect conflicts between different policies and resolve them. The 417 simplest view of a policy is that it specifies a set of actions 418 that MUST be performed if a set of associated conditions is met. 419 Therefore, the ability to detect and resolve conflicts between policy 420 definitions (conditions as well as actions that are taken when a 421 set of conditions are met) is crucial. One way of doing this is by 422 imposing a priority and/or order on both the satisfaction of policy 423 conditions as well as the execution of policy actions. However, it 424 should be noted that priority and order are fundamental concepts of 425 distributed systems and MUST be supported irrespective of being used 426 to supply a means for policy conflict resolution. 428 4.5 Policy Components 430 Policy is comprised of the following three functions: 432 1. Decision-making. This compares the current state of the network to 433 a desired state described by an application-specific policy and 434 decides how to achieve the desired state. 435 2. Enforcement. This implements a desired policy state through a set 436 of management commands; when applied to network elements, these 437 management commands change the configuration of the device using 438 one or more mechanisms. These mechanisms MAY be vendor-specific. 439 3. Policing. This is an on-going active or passive examination of the 440 network and its constituent devices for checking network health, 441 whether policies are being satisfied, and whether clients are 442 taking unfair advantage of network services. 444 Decision-making uses static and/or dynamic data to determine if a type 445 of policy is being satisfied and, if not, what steps are needed to 446 satisfy that policy. Enforcement refers to the interpretation and 447 execution of policies by consumers who are assumed to be trustworthy. 448 Policing is the auditing of policy compliance to verify that the policy 449 consumers properly implement policies. 451 4.6 Policy-Based Applications and Network Policy 453 Policy is defined in terms of applications or processes that monitor 454 and manipulate one or more entities in order to achieve a desired goal. 455 To make the following discussion simpler to understand, this paper 456 focuses on network policies. 458 A network policy defines the relationships between clients that desire 459 services of the network and the network elements that provide those 460 services. Network Policy applications model two important things: 461 1) the state of the SLAs that they are enforcing, and/or 462 2) some part of the state of the (overall) network in order to 463 ensure that their clients will obtain the services they require 464 of (that portion of) the network. 466 Such applications will maintain a number of objects of various types, 467 each with one or more attributes. Each of these objects either models 468 the state of one or more network elements or maintains some part of the 469 internal state of the policy application. 471 Each of these state machines contains the mapping of services desired 472 by users to the network elements that provide those services. A network 473 policy, then, is a relationship among attributes of the objects 474 maintained by the policy application that controls and manages some 475 aspect of the network in terms of one or more services that the network 476 provides. Since the application models some part of the state of the 477 entity, it is also accurate to say that a policy is a statement about 478 the desired state of the entity (e.g., the requirements to maintain its 479 current state or the need to transition to a different state). 481 4.7 Difference Between Policy And Service 483 A service is the expression of a relationship between a set of objects. 484 A policy is a statement about a set of relationships between objects 485 that provide a particular service. 487 4.8 Need For Canonical Representation Of Policy 489 Policies represent business functions and goals. These correspond to 490 network services, which are provided by vendor-specific network 491 elements. The problem is that vendors will describe the same business 492 function in different ways. This is because business functions are 493 described at a necessarily high level, and are therefore subject to 494 different interpretation. Since the network will implement the services 495 that correspond to these business functions, differences in network 496 elements will exacerbate this mapping. 498 The solution is to use a canonical representation of policy. All 499 policies MUST consist of a set of policy rules, and all policy rules 500 MUST consist of a set of policy conditions and policy actions. This 501 provides a consistent meta-structure for describing policy, enabling 502 a vendor-independent exchange of policy information. However, this 503 is not enough, because the definitions of policy conditions and 504 actions could still be different, and if they were, interoperability 505 of policy servers will not be achievable. Therefore, a canonical 506 representation of policy conditions and policy actions MUST also 507 be enforced. This in turn requires a categorization of policy rule, 508 policy condition, and policy action into a set of application-specific 509 domains (e.g., RSVP and Differentiated Services would have separate 510 policy conditions and actions that identify their applicability). 511 Given a class-based implementation of policy, the above could be 512 implemented easily through defining subclasses that corresponded to 513 the different policies, policy rules, policy conditions, and policy 514 actions that were under control of the PDP. 516 5. Policy Terminology 518 The following is a set of policy terminology definitions. 520 5.1 Policy 522 A policy is a named object that represents an aggregation of Policy 523 Rules. The policy describes the overall business function(s) to be 524 accomplished, while the set of policy rules define how those business 525 functions will be met. The business function(s) correspond to one or 526 more SLOs of an SLA. 528 5.2 Policy Rule 530 A policy rule is comprised of a set of conditions and a corresponding 531 set of actions. This combination in effect defines a sequence of 532 actions to be initiated when the corresponding set of conditions is 533 either satisfied or not satisfied. For simplicity, it is recommended 534 that positive (satisfaction) and negative (unable to meet) conditions 535 be realized as separate rules that are folded into a single policy. 536 Each policy rule is a declarative statement consisting of a Boolean 537 expression that describes a situation to which the policy applies. 538 When the expression is true, one set of actions is initiated, and 539 when false, a different set of actions is initiated. This version of 540 the document will only consider the expression of a rule as a condition 541 statement (e.g., IF some set of conditions are met, THEN take this set 542 of actions, ELSE take this other set of actions). 544 5.3 Policy Condition 546 Policy Conditions consist of two parts, a policy condition type and a 547 policy condition element. This structure is aimed at satisfying the 548 need for a canonical representation of a policy condition. 550 A policy condition type is a set of predefined conditions that can be 551 attached to a policy rule for evaluation. This canonical set of 552 conditions represent common conditions that all network vendors can 553 implement. By including this canonical representation of policy 554 conditions, the resulting set of policy conditions can be exchanged 555 between multiple vendors' policy servers. This is necessary for 556 interoperability as well as for a policy server to be able to parse 557 rules to determine if any rules conflict may potentially conflict 558 with each other. A policy condition element is a policy condition type 559 instance that is being tested. Policy condition elements are related 560 together to form a Boolean expression. The relations can be one of the 561 following operators: in, not in, equal, not equal, less than, less 562 than or equal, greater than, and greater than or equal. 564 5.4 Policy Action 566 A policy action is the changing of the configuration of one or more 567 network elements in order to achieve a desired policy state. This (new) 568 policy state provides one or more (new) behaviors. As with policy 569 conditions, a policy action is comprised of two parts, a policy action 570 type and a policy action element. The policy action type defines a 571 canonical set of operations or treatments that can be given to traffic 572 flowing into the network element (e.g., deny, change code point, etc.) 573 that is vendor-independent. Similarly, the policy action element 574 specifies the type of mechanism to be used to provide the specified 575 operation or treatment. 577 5.5 Policy Decision 579 A policy decision is the abstraction of activating and evaluating one 580 or more policy rules. Each policy rule is interpreted in the context 581 of a specific request (implied or explicit) for accessing and/or using 582 one or more resources. It connotes taking one or more pre-determined 583 actions based on whether or not a given set of policy conditions were 584 satisfied. Note that the action of a policy decision MAY be to simply 585 invoke another policy rule for further processing of the request. 587 5.6 Policy Behavior 589 A policy behavior controls how traffic is treated, what network 590 resources must be utilized, and/or what network services are provided. 591 Policy behaviors define one or more mechanisms that are used to 592 implement the policy. Therefore, different devices can carry out the 593 same policy using different behaviors. For example, one router might 594 use a dropping behavior and another might use a queueing behavior 595 during times of congestion in order to satisfy an overall delivery 596 goal. Policy behaviors can include one or more of the following: 598 - permit or deny forwarding of traffic based on: 599 - source and destination address 600 - source and destination port number 601 - protocol type and options 602 - other factors specific to vendor implementations 603 - permit or deny access to a requested resource or service 604 - encrypt the header and/or the payload 605 - start or stop accounting and/or auditing 606 - start or stop logging 608 5.7 Policy State 610 A policy state is a description of the settings of one or more network 611 elements. These settings correspond to providing the set of services to 612 be provided by the network. For example, a Service Level Agreement can 613 describe services contracted for by subscribers - this corresponds to a 614 state that various network elements must be put into in order to 615 provide those services. 617 5.8 Policy Conflict 619 A policy conflict occurs when the conditions of two or more policies 620 can be simultaneously satisfied, but the actions of at least one of 621 the policies can not be simultaneously executed. This implies 622 several things: 624 - one or more policy rules of each of the policies is satisfied by 625 the same request 626 - each condition of each of the conflicting policy rules is satisfied 627 by the same request 628 - one or more actions specified by one policy conflict with one or 629 more actions specified by the other policy 631 Policy conflicts can be resolved in a number of different ways. The 632 simplest is to change the conditions and/or actions of one of the 633 policies so that it no longer conflicts with the other policies. 634 However, if the policies must remain inherently conflicting, then there 635 are a number of ways to resolve the conflict on an individual event 636 basis, including the following: 638 - apply a "match-first" criteria, wherein conflicts are resolved by 639 matching the first policy that is found 640 - apply a priority order criteria, wherein conflicts are resolved by 641 finding all policy rules which match a given event and selecting 642 only the rule with the highest priority 643 - use additional metadata to determine which rule or rules should be 644 applied. The difference between this and straight priority is that 645 priority is inherently linear, whereas metadata is not (e.g., 646 branching can be used). 648 5.9 Service Level Agreement (SLA) 650 An SLA is a service contract between a customer and a Service Provider 651 that specifies the expected operational characteristics of their 652 relationship. Example operational characteristics include the details 653 of the treatment which a customer's traffic and/or requests for 654 service should receive. The details of the operational characteristics 655 are defined in terms of Service Level Objectives (SLOs). The SLA 656 documents the agreed levels and parameters of services provided, and 657 can cover a wide range of parameters including items that effect 658 the network element and items that don't (e.g., service hours and 659 availability, user support levels, etc.). 661 5.10 Service Level Objective (SLO) 663 An SLO partitions an SLA into individual objectives that can be mapped 664 into policies that can be executed. The SLOs define metrics to enforce, 665 police, and/or monitor the SLA. Some commonly used metrics to determine 666 whether or not an SLA is being fulfilled include component system 667 availability (e.g., up-time and MTBF), performance (e.g., response 668 time), and serviceability (e.g., MTTR). 670 5.11 Policy Event 672 A policy event is a notification that triggers one or more policy 673 evaluations. A particular event may or may not initiate a policy 674 decision and/or a policy enforcement action. 676 5.12 Policy Evaluation 678 Policy evaluation is the determination of whether or not the network 679 (or a part of it) is in a desired policy state. This is usually 680 determined by processing static and/or dynamic data against one or more 681 policy rules, the key point being that the decision is made by 682 comparing definitional data stored in the policy repository with 683 current data from the network that does not have to be stored in the 684 policy repository. If it is found that the network elements are not in 685 the desired policy state, then one or more policy actions will be taken 686 to move the network elements from their current state to the desired 687 state. This is called policy enforcement. 689 5.13 Policy Enforcement 691 Policy enforcement is the action of placing the network (or a part of 692 the network) in a desired policy state using a set of management 693 commands. When this definition is applied to network elements, these 694 management commands change the configuration of the device(s) using 695 one or more mechanisms. Enforcement is carried out in the context of a 696 policy rule. 698 5.14 Policy Policing 700 Policy policing is an on-going active or passive examination of the 701 network and its constituent devices for checking network health, 702 whether policies are being satisfied, and whether clients are taking 703 unfair advantage of network services. This is done for one or more 704 of the following reasons: 706 - to monitor network statistics as part of checking network health 707 - to monitor network statistics as part of checking whether policies 708 that are currently in use are being satisfied 709 - to ensure that clients of a given set of policies are not abusing 710 their privileges 712 5.15 Policy Agent 714 A policy agent is a software module that generates and responds to 715 policy events, evaluates policies, and enforces policies. 717 5.16 Policy-Driven Service 719 A policy-driven service is a set of cooperating policy agents that 720 Define, monitor and enforce a particular policy. 722 5.17 Policy Audit 724 A policy audit matches conditions examines one or more active policies 725 to determine if their actions are being executed correctly and the 726 desired result (e.g., flow of traffic) is being carried out. This 727 is equivalent to checking the state of the network to determine the set 728 of policies that are and are not being satisfied. 730 5.18 Policy Consistency Checking 732 Policy consistency checking is an analysis of currently active policies 733 to determine their consistency or possible inconsistency with each 734 other. When an inconsistency is discovered, a policy discrepancy is 735 reported. 737 5.19 Policy Discrepancy 739 A policy discrepancy is a notification that two or more policies are in 740 actual or potential conflict in the sense that implementation of one 741 policy may prevent or otherwise adversely effect the implementation of 742 the other policies. 744 5.20 Policy Mechanism 746 A policy mechanism is a set of vendor-specific commands that configures 747 a network element to put a policy rule into effect. 749 5.21 Policy Verification 751 Policy Verification is an analysis of a policy to determine if the 752 desired state can be established and maintained for the duration of 753 the corresponding policy rule being active. 755 5.22 Policy Restoration 757 Policy Restoration is one or more actions taken to restore the system 758 to a desired policy state. This could be invoked because of a policy 759 action in response to an event, or because the current state got 760 corrupted. 762 6. Policy Example 764 This section will provide an example of the canonical use of 765 policies, policy rules, policy conditions and policy actions. 767 Assume that the following business rule is to be implemented as 768 a policy: 770 Provide the JitterFreeMPEG2 video service for authorized users 771 between authorized points, but only at agreed-upon times 773 This rule can be loosely translated as: 775 IF user IN ApprovedUsers AND service IN VideoServices AND 776 source IN VideoSources AND destination IN VideoDestinations AND 777 time IN ApprovedTimePeriods 778 THEN provide JitterFreeMPEG2 780 The policy condition is loosely translated as: 781 IF the user is a member of an approved group (ApprovedUsers) that 782 are authorized to have this service) 783 AND the service requested is one supported (VideoServicesgroup) 784 AND the source of the request is approved (in the VideoSources 785 group or has been authenticated) 786 AND the destination is approved (in the VideoDestinations group 787 or has been authenticated) 788 AND the time requested is OK (in ApprovedTimePeriods) 790 Here, the policy condition types are: 791 user, service, source, destination, and time 792 and the policy condition elements are: 793 ApprovedUsers, VideoServices, VideoSources, VideoDestinations, 794 and ApprovedTimePeriods, which are all instances of pre-defined 795 groups of objects. 797 The policy action is: 798 IF the conditions are satisfied 799 THEN provide the user with video having a QoS defined by the 800 JitterFreeMPEG2 service 802 Note that this policy could require "sub-policies" in order for it to 803 be implemented. For example, RSVP requests might be used to 804 precondition the path between VideoSources and VideoDestinations. 806 7. Terminology For Implementing Policy GUIs 808 Part of the task of defining policy terminology is to enable policies 809 to be represented in a user-friendly GUI. This section provides 810 guidelines for doing this through the introduction of additional 811 terminology designed expressly for this purpose. 813 7.1 Types Of Policies 815 An effective policy GUI MUST be able to categorize and sort policies in 816 ways that are meaningful to the user. Three are three broad means of 817 doing this, based on differentiating between how a policy is used, 818 how a policy is triggered, and the attributes of the policy. 820 7.2 How A Policy Is Used - Service And Usage Policies 822 Service and Usage Policies are a means of categorizing policies by what 823 they do and how they are used. Service policies describe services 824 available in the network. Usage policies describe which policies will 825 use which services when the usage policies are satisfied. Usage 826 policies describe particular mechanism(s) employed to either maintain 827 the current state of the object, or to transition an object from one 828 state to a new state, in order to utilize the specified services. 830 For example, the fact that a user can get a particular conditioning 831 treatment, or can use IPSEC to encrypt the payloads of traffic, are 832 both services that are provided and are represented as service 833 policies. On the other hand, differentiating between two flows and 834 assigning different services to the flows is an example of using usage 835 policies to differentiate the handling of the flows. 837 7.3 How A Policy Is Triggered - Static vs. Dynamic Policies 839 There are two fundamentally different ways that policies can be 840 applied - statically in response to a set of pre-defined conditions and 841 dynamically in response to one or more events. Both static and dynamic 842 policies use statically defined rules to determine how the policy 843 effects the objects that it is applied on. Furthermore, both types of 844 policies are applied in response to an event. The difference lies in 845 how they are applied. 847 7.3.1 Static Policies 849 Static policies apply a fixed set of actions in a pre-determined way 850 according to a set of pre-defined parameters that determine how the 851 policy is used. These parameters restrict the application of the policy 852 in some way. Examples include restricting the application of the policy 853 to only certain times of the day, week, month, or year. For instance, 854 the accounting department gets 75% of the bandwidth at the close of the 855 quarter, or anyone can use streaming video after 7:00PM. The above 856 examples each illustrate a means of restricting the application of the 857 policy based on some external data or set of conditions. 859 7.3.2 Dynamic Policies 861 This type of policy gets enforced when needed (i.e., when the network 862 gets congested, or when a user with Gold Service logs on). Although the 863 conditions of the enforcement are pre-defined, there is no set time or 864 parameter that triggers the policy. Rather, the policy is triggered 865 when a condition occurs. For example, Gold Service has one set of 866 actions when the network is not congested and an additional set of 867 actions when the network is congested. The mechanism that implements 868 the gold service doesn't change; however, additional sets of actions 869 (that ensure the delivery of Gold Service) are invoked when the network 870 is congested. Since the network can be congested in different ways, 871 different sets of actions are invoked. 873 This is fundamentally different than the static policies defined above 874 in that static policies always invoke the same set of actions the same 875 way in response to an event. Dynamic policies may invoke different 876 actions based on the semantics of the event. 878 7.4 Classifying Policies Based On Attributes 880 Policies can be classified by the attributes that they possess. This 881 includes what the policy applies to (e.g., a class of user or a certain 882 type of application) as well as certain attributes that fundamentally 883 change the applicability (conditions) and effect (actions) of the 884 policy. Examples of these include physical location. For example, if a 885 user is connected to his or her corporate Intranet through the public 886 internet, then a different security policy might be applied to that 887 communication and different restrictions may be placed on accessing 888 resources than when that user connects through the corporate network. 890 7.5 Policy Triggers 892 Some policies only come into force if certain usage conditions are met. 893 For example, if the current network bandwidth utilization is low, users 894 may be allowed to use certain applications (e.g., streaming video or 895 interactive games) that they otherwise are not allowed to use. 896 Furthermore, this privilege may be revoked if the traffic reaches a 897 certain level. 899 8. Security Considerations 901 Security and denial of service considerations are not explicitly 902 Considered in this memo, as they are appropriate for the udnerlying 903 Policy architecture. However, the policy architecture must be secure 904 as far as the following aspects are concerned. First, the mechanisms 905 proposed under the framework must minimize theft and denial of service 906 threats. Second, it must be ensured that the entities (such as PEPs and 907 PDPs) involved in policy control can verify each other's identity and 908 establish necessary trust before communicating. 910 9. Acknowledegments 912 Many thanks to the useful discussions and suggestions from the Internet 913 Community at large but especially to Andrea Westerinen, John Lee, 914 Lee Rafalow, Steve Schleimer and Fred Baker. 916 10. References 918 [TERMS] S. Bradner, "Key words for use in RFCs to Indicate 919 Requirement Levels", Internet RFC 2119, March 1997. 920 [DIFFARCH] D. Black, S. Blake, M. Carlson, E. Davies, Z. Whang, 921 W. Weiss, "An Architecture for Differentiated Services", 922 Internet draft , 923 May 1998 924 [DIFFSERV] K. Nichols and S. Blake, "Definition of the 925 Differentiated Services Field (DS Byte) in the 926 IPv4 and IPv6 Headers", Internet draft 927 , May 1998 928 [DSFIELD] K. Nichols and S. Blake, "Definition of the Differentiated 929 Services Field (DS Byte) in the IPv4 and IPv6 Headers", 930 Internet Draft , 931 May 1998. 932 [LDAP] This refers to the current collection of LDAP RFCs 933 (2251 - 2256) but especially to RFC 2251 (the protocol). 934 [RAPFRAME] R. Yavatkar, D. Pendarakis, R. Guerin, "A Framework for 935 Policy-based Admission Control", Internet Draft, 936 < draft-ietf-rap-framework-01.txt>, May 1998 937 [SLA] R. Rajan, J-C Martin, editors, "Schema for Service Level 938 Administration of Differentiated Services and 939 Integrated Services in Networks", Internet Draft 940 , June 1998 942 Authors' Addresses 944 John Strassner 945 Bldg 1 946 Cisco Systems 947 170 West Tasman Drive 948 San Jose, CA 95134 949 Phone: +1-408-527-1069 950 Fax: +1-408-527-1722 951 E-mail: johns@cisco.com 953 Ed Ellesson 954 JDGA/501 955 IBM Corporation 956 4205 S. Miami Blvd. 957 Research Triangle Park, NC 27709 958 Phone: +1-919-254-4115 959 Fax: +1-919-254-6243 960 E-mail: ellesson@raleigh.ibm.com