idnits 2.17.1 draft-ietf-policy-terms-00.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 == It seems as if not all pages are separated by form feeds - found 0 form feeds but 29 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 48 instances of too long lines in the document, the longest one being 625 characters in excess of 72. ** There are 25 instances of lines with control characters in the document. ** The abstract seems to contain references ([TERMS], [CIM]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == 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. -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC2474' is mentioned on line 195, but not defined == Missing Reference: 'RFC2475' is mentioned on line 253, but not defined ** Downref: Normative reference to an Informational RFC: RFC 2475 (ref. 'DIFFARCH') -- 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'RAPFRAME' -- Possible downref: Non-RFC (?) normative reference: ref. 'PLYARCH' -- Possible downref: Non-RFC (?) normative reference: ref. 'CIM' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISWG' -- Possible downref: Non-RFC (?) normative reference: ref. 'DSWG' -- Possible downref: Non-RFC (?) normative reference: ref. 'RAPWG' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISSLLWG' -- Possible downref: Non-RFC (?) normative reference: ref. 'IPSECWG' Summary: 10 errors (**), 0 flaws (~~), 6 warnings (==), 12 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 23 June 1999 Ed Ellesson 4 IBM 6 Terminology for describing network policy and services 7 draft-ietf-policy-terms-00.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. In addition, information modeling approaches, like CIM 50 [CIM], define specific meanings for these terms that must be 51 coordinated with the IETF community. 53 This document defines a set of terms that the Internet community can 54 use to exchange ideas on how policy creation, administration, 55 management, and distribution could work among policy servers and 56 multiple device types. 58 Definition of Key Word Usage 60 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 61 "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document 62 are to be interpreted as described in RFC 2119 [TERMS]. These words 63 will be capitalized to ensure that their intent in this context is 64 easily discernible. 66 Table of Contents 68 Status of this memo 1 69 Abstract 1 70 Definition of Key Word Usage 2 71 Table of Contents 2 72 1. Introduction and Motivation 4 73 2. Previously Defined Terminology 5 74 3. Areas of Terminology Conflict 9 75 4. Policy Mental Model 10 76 4.1 General Policy Architecture 11 77 4.2 How Policy Decisions Are Made 13 78 4.3 What Is A Policy (In General Terms) 13 79 4.4 Real-World Requirements of Policy 14 80 4.4.1 Applicable to Large-Scale Solutions 14 81 4.4.2 Secure 15 82 4.4.3 Easy to Detect Conflicts 15 83 4.5 Policy Components 15 84 4.6 Policy-Based Applications And Network Policy 16 85 4.7 Difference Between Policy And Service 16 86 4.8 Need For Canonical Representation Of Policy 17 87 5. Policy Terminology 17 88 5.1 Policy Group 17 89 5.2 Policy Rule 18 90 5.3 Policy Condition 18 91 5.4 Policy Action 19 92 5.5 Policy Decision 19 93 5.6 Policy Behavior 19 94 5.7 Policy State 20 95 5.8 Effect of Executing a Policy 20 96 5.9 Policy Domain 20 97 5.10 Policy Conflict 21 98 5.10.1 Global Conflict Detection 21 99 5.10.2 Local Conflict Detection 21 100 5.11 Service Level Agreement 22 101 5.12 Service Level Objective 22 102 5.13 Policy Event 22 103 5.14 Policy Evaluation 22 104 Table of Contents (continued) 106 5.15 Policy Enforcement 23 107 5.16 Policy Policing 23 108 5.17 Policy Agent 23 109 5.18 Policy-Driven Service 23 110 5.19 Policy Audit 23 111 5.20 Policy Consistency Checking 24 112 5.21 Policy Discrepancy 24 113 5.22 Policy Mechanism 24 114 5.23 Policy Verification 24 115 5.24 Policy Restoration 24 116 5.25 Roles 24 117 5.25.1 Role Combinations 25 118 6. Policy Example 25 119 7. Terminology For Implementing Policy GUIs 26 120 7.1 Types Of Policies 26 121 7.2 How A Policy Is Used - Service And Usage Policies 27 122 7.3 Classifying Policies Based On Attributes 27 123 8. Security Considerations 27 124 9. Acknowledgements 27 125 10. References 28 126 11. Authors' Addresses 29 127 12. Full Copyright Statement 29 128 1. Introduction and Motivation 130 Recent work in the IETF has led to protocols which support the 131 classification of packets for the purposes of treating certain 132 classes or flows of packets in a particular way compared to other 133 packets. The purpose of such classification may include preferential 134 queuing or dropping, admitting or denying access, or encrypting the 135 packet's payload, to cite just a few examples. Protocols that 136 explicitly support some or all of these functions include COPS, 137 RADIUS, RSVP, and IPSEC. In addition, the IntServ [ISWG], DiffServ [DSWG], RAP [RAPWG], ISSLL [ISSLLWG] and IPSEC [IPSECWG] working groups are defining approaches to using these protocols. 139 The successful wide-scale deployment these and other protocols depends 140 on the ability for the administrator of a network domain to administer 141 and distribute consistent policy information to the multiple devices 142 in the network which perform the classification and packet 143 conditioning or treatment. Protocols that could be used for the 144 distribution of the policy include LDAP, COPS, SNMP, and TELNET/CLI. 145 The multiple types of devices that must work in concert across even a 146 single domain to achieve the desired policy can include hosts (clients 147 and servers), routers, switches, firewalls, bandwidth brokers, subnet 148 bandwidth managers, network access servers, and policy servers, to name 149 just a few. 151 As a result, there is a clear need to develop a scalable framework for 152 policy administration and distribution that will allow interoperability 153 among the multiple devices and device types that must work together to 154 achieve a consistent implementation of the network administrator's 155 policy. Unfortunately, terms like "policy" and "service" are not 156 currently defined in sufficient detail as to enable the definition, 157 specification, and implementation of policy servers and how policy is 158 recognized and enforced at the device level. At present, both "policy" 159 and "service" (as well as other related terms) are overloaded with 160 multiple (often conflicting) meanings. This makes communication about 161 policy in general and specifically policy-based networking cumbersome 162 and difficult. 164 This document defines a set of terms that the Internet community can 165 use to exchange ideas on how policy creation, administration, 166 management, and distribution could work among policy servers and 167 multiple device types. 169 2. Previously Defined Terminology 171 The following terms have been previously defined in other Internet 172 Drafts and are used in this draft to better define policy and policy- 173 based networking terms. 175 Definitions taken from RFC2474 (Definition of the DS Field): 177 Classifier: an entity which selects packets based on the content of 178 packet headers according to defined rules. 180 Differentiated Services Boundary: the edge of a DS domain, where 181 classifiers and traffic conditioners are likely to be deployed. A 182 differentiated services boundary can be further sub-divided into 183 ingress and egress nodes, where the ingress/egress nodes are the 184 downstream/upstream nodes of a boundary link in a given traffic 185 direction. A differentiated services boundary typically is found at 186 the ingress to the first-hop differentiated services-compliant 187 router (or network node) that a host's packets traverse, or at the 188 egress of the last-hop differentiated services-compliant router or 189 network node that packets traverse before arriving at a host. This 190 is sometimes referred to as the boundary at a leaf router. A 191 differentiated services boundary may be co-located with a host, 192 subject to local policy. 194 Differentiated Services-Compliant: in compliance with the 195 requirements specified in [RFC2474]. 197 Differentiated Services Domain: a contiguous portion of the Internet 198 over which a consistent set of differentiated services policies are 199 administered in a coordinated fashion. A differentiated services 200 domain can represent different administrative domains or autonomous 201 systems, different trust regions, different network technologies 202 (e.g., cell/frame), hosts and routers, etc. 204 Differentiated Services Field: the IPv4 header TOS octet or the IPv6 205 Traffic Class octet when interpreted in conformance with the 206 definition given in this document (RFC2474). 208 Mechanism: The implementation of one or more per-hop behaviors 209 according to a particular algorithm. 211 Per-hop Behavior (PHB): a description of the externally observable 212 forwarding treatment applied at a differentiated services-compliant 213 node to a behavior aggregate. The description of a PHB SHOULD be 214 sufficiently detailed to allow the construction of predictable 215 services, as documented in [RFC2475]. 217 Per-hop Behavior Group: a set of one or more PHBs that can only be 218 meaningfully specified and implemented simultaneously, due to a 219 common constraint applying to all PHBs in the set such as a queue 220 servicing or queue management policy. 222 Traffic Conditioning: control functions that can be applied to a 223 behavior aggregate, application flow, or other operationally useful 224 subset of traffic, e.g., routing updates. These MAY include 225 metering, policing, shaping, and packet marking. Traffic 226 conditioning is used to enforce agreements between domains and to 227 condition traffic to receive a differentiated service within a 228 domain by marking packets with the appropriate codepoint in the DS 229 field and by monitoring and altering the temporal characteristics of 230 the aggregate where necessary. 232 Traffic Conditioner: an entity that performs traffic conditioning 233 functions and which MAY contain meters, policers, shapers, and 234 markers. Traffic conditioners are typically deployed in DS boundary 235 nodes (i.e., not in interior nodes of a DS domain). 237 Service: a description of the overall treatment of (a subset of) a 238 customer's traffic across a particular domain, across a set of 239 interconnected DS domains, or end-to-end. Service descriptions are 240 covered by administrative policy and services are constructed by 241 applying traffic conditioning to create behavior aggregates which 242 experience a known PHB at each node within the DS domain. Multiple 243 services can be supported by a single per-hop behavior used in 244 concert with a range of traffic conditioners. 246 Definitions taken from RFC2475 (Differentiated Services Architecture): 248 - DS boundary node: a DS node that connects one DS domain to a 249 node either in another DS domain or in a domain that is not 250 DS-capable. 252 - DS-capable: capable of implementing differentiated services 253 as described in this architecture [RFC2475]; usually used in 254 reference to a domain consisting of DS-compliant nodes. 256 - DS codepoint: a specific value of the DSCP portion of the 257 DS field, used to select a PHB. 259 - DS-compliant: enabled to support differentiated services 260 functions and behaviors as defined in [DSFIELD], this document 261 (DS Architecture), and other differentiated services documents; 262 usually used in reference to a node or device. 264 - DS domain: a DS-capable domain; a contiguous set of nodes which 265 operate with a common set of service provisioning policies and PHB 266 definitions. 268 - DS egress node: a DS boundary node in its role in handling traffic 269 as it leaves a DS domain. 271 - DS ingress node: a DS boundary node in its role in handling traffic 272 as it enters a DS domain. 274 - DS interior node: a DS node that is not a DS boundary node. 276 - Marking: the process of setting the DS codepoint in a packet based 277 on defined rules; pre-marking, re-marking. 279 - Mechanism: a specific algorithm or operation (e.g., queueing 280 discipline) that is implemented in a node to realize a set of 281 one or more per-hop behaviors. 283 - Metering: the process of measuring the temporal properties (e.g., 284 rate) of a traffic stream selected by a classifier. The 285 instantaneous state of this process may be used to affect the 286 operation of a marker, shaper, or dropper, and/or may be used for 287 accounting and measurement purposes. 289 - Policing: the process of discarding packets (by a dropper) within a 290 traffic stream in accordance with the state of a corresponding 291 meter enforcing a traffic profile. 293 - Service: the overall treatment of a defined subset of a customer's 294 traffic within a DS domain or end-to-end. 296 - Service Level Agreement: a service contract between a customer and 297 a service provider that specifies the forwarding service a customer 298 should receive. A customer may be a user organization (source 299 domain) or another DS domain (upstream domain). A SLA may include 300 traffic conditioning rules which constitute a TCA in whole or 301 in part. 303 - Service Provisioning Policy: a policy which defines how traffic 304 conditioners are configured on DS boundary nodes and how traffic 305 streams are mapped to DS behavior aggregates to achieve a range 306 of services. 308 - Shaping: the process of delaying packets within a traffic stream 309 to cause it to conform to some defined traffic profile. 311 - Traffic conditioning: control functions performed to enforce 312 rules specified in a TCA, including metering, marking, shaping, 313 and policing. 315 - Traffic Conditioning Agreement (TCA): an agreement specifying 316 classifier rules and any corresponding traffic profiles and 317 metering, marking, discarding and/or shaping rules which are to 318 apply to the traffic streams selected by the classifier. A TCA 319 encompasses all of the traffic conditioning rules explicitly 320 specified within a SLA along with all of the rules implicit from 321 the relevant service requirements and/or from a DS domain's 322 service provisioning policy. 324 - Traffic profile: a description of the temporal properties of a 325 traffic stream such as rate and burst size. 327 - Traffic stream: an administratively significant set of one or 328 more microflows which traverse a path segment. A traffic stream 329 may consist of the set of active microflows which are selected by 330 a particular classifier. 332 Definitions taken from the Differentiated Services Working Group Charter: 334 Differentiated Services: The differentiated services approach to 335 providing quality of service in networks employs a small, well- 336 defined set of building blocks from which a variety of services may 337 be built. 339 Definitions taken from draft-ietf-rap-framework-01.txt: 341 - Administrative Domain: A collection of network elements under the 342 same administrative control and grouped together for administrative 343 purposes. 345 - Installed State: A new and unique request made from a PEP to a PDP 346 that must be explicitly deleted. 348 - Network Element (also called a Node): A networking device, such as 349 a router, a switch, or a hub, where resource allocation decisions 350 have to be made and the decisions have to be enforced. 352 - QoS Signaling Protocol: A signaling protocol that carries an 353 admission control request for a bandwidth resource, e.g., RSVP. 355 - Policy: The combination of rules and services where rules define 356 the criteria for resource access and usage. 358 - Policy control: The application of rules to determine whether or 359 not access to a particular resource should be granted. 361 - Policy Object: Contains policy-related info such as policy 362 elements and is carried in a request or response related to 363 resource allocation decision. 365 - Policy Element: Subdivision of policy objects; contains single 366 units of information necessary for the evaluation of policy rules. 367 A single policy element carries an user or application 368 identification whereas another policy element may carry user 369 credentials or credit card information. Examples of policy 370 elements include identity of the requesting user or application, 371 user/app credentials, etc. The policy elements themselves are 372 expected to be independent of which QoS signaling protocol is used. 374 - Policy Decision Point (PDP): The point where policy decisions are 375 made. 377 - Policy Enforcement Point (PEP): The point where the policy 378 decisions are actually enforced. 380 - Policy Ignorant Node (PIN): A network element that does not 381 explicitly support policy control using the mechanisms defined in 382 this document (RAP Framework). 384 - Resource: Something of value in a network infrastructure to which 385 rules or policy criteria are first applied before access is 386 granted. Examples of resources include the buffers in a router and 387 bandwidth on an interface. 389 - Service Provider: Controls the network infrastructure and may be 390 responsible for the charging and accounting of services. 392 - Trusted Node: A node that is within the boundaries of an 393 administrative domain (AD) and is trusted in the sense that the 394 admission control requests from such a node do not necessarily need 395 a PDP decision. 397 3. Areas of Terminology Conflict 399 Section 2 listed previously-defined terms that are related to the 400 definition of policy and policy-based networking. Of these terms, the 401 following terms that have been previously defined need more definition 402 in order to satisfy the goals of this document, and will be redefined 403 in subsequent sections of this document: 405 NAME OF THE TERM DEFINED IN PROBLEM WITH DEFINITION 406 Service [DIFFSERV], Tied directly to network traffic; 407 [DIFFARCH] needs to be defined more generally 409 Policing [DIFFARCH] Too specific to traffic conditioning 411 Service Level [DIFFARCH] Too specific to forwarding of network 412 Agreement (SLA) traffic and traffic conditioning 414 Service [DIFFARCH] Too specific to Differentiated 415 Provisioning Services architecture 417 Policy [RAPFRAME] Too simplistic a definition; too 418 focused on network resource control 420 Policy control [RAPFRAME] Too simplistic a definition; too 421 focused on network resource control 423 Policy Object [RAPFRAME] Too specific to using QoS 424 signaling protocol as transport; too 425 focused on network resource control 427 PDP [RAPFRAME] Too RSVP-specific. Needs to add 428 clarification that policy decisions 429 can also be made at the PEP. 431 Policy Element [RAPFRAME] Not just for evaluation of policy 432 Rules 434 Domain [DIFFSERV] Specific to just treatment of 435 Traffic using DiffServ; needs to 436 be generalized 438 4. Policy Mental Model 440 In the general sense, policies represent business goals and objectives, 441 and describe how resources are allocated to meet these goals and 442 objectives. In the general sense, a "resource" is any object that can 443 potentially be in short supply, due to many different clients 444 simultaneously requesting it. With respect to the Policy Framework 445 working group, we will differentiate between "resources" as defined 446 above and "network resources", which refers explicitly to resources 447 of a network element (e.g., interface bandwidth). Thus, the term 448 "network resources" matches the definitions of previous documents 449 referenced above. 451 Again, with respect to networking, policy refers to the ability to 452 administer, manage, and control access to the network resources of 453 network elements in order to provide a set of services to clients 454 of the network. "Clients" in this context refer to users as well as 455 applications and services. 457 An underlying assumption of this draft is that policy is stored in a 458 centralized repository. This repository may be, but is not limited to, 459 a directory accessed using the LDAP protocol [LDAP]. The rest of this 460 section defines the underlying mental model to support this definition 461 of policy and policy-based networking. 463 4.1 General Policy Architecture 465 A general architecture is shown in Figure 1 below. 467 Policy Specifications 468 | 469 + - - - - - - - | - - - - - - - + Multi-role policy server 470 V 471 | +--------------------+ | 472 | Policy | 473 | | Management Tool | | 474 +----*----+----------+ 475 | * + | 476 * +++++++++++++++++++++++++++++++ 477 | * | + 478 * +---------+----------+ 479 | * | | Policy Repository | 480 * | (Directory Server, | <-- Policy 481 | * | | Database, etc. ) | rules 482 * +---------+----------+ 483 | * | + 484 * +++++++++++++++++++++++++++++++ 485 | * + | 486 +----*----+----------+ 487 | | Policy Decision | | 488 | Point (PDP) | 489 | +---------+----------+ | 490 # 491 + - - - - - - - # - - - - - - - + 492 # 493 # <--- Policy Protocol for communicating control 494 # of device policy mechanisms to the PEP 495 # 496 +---------+----------+ +++++++++ Repository Access Protocol 497 | Policy Enforcement | (e.g., LDAP) - REQUIRED 498 | Point (PEP) | ********* OPTIONAL communication path 499 +--------------------+ ######### Policy Protocol 500 (e.g., COPS) - REQUIRED 502 Figure 1. Architectural Overview 504 The above diagram illustrates one common implementation that combines 505 the use of a policy management tool, a policy repository, a PDP, and 506 a PEP. 508 This diagram is not meant to imply that these entities must be 509 located in physically separate devices, nor is it meant to imply that 510 the only protocols used for communicating policy are those illustrated. 511 Rather, it is simply meant to show one possible implementation for the 512 purpose of defining the four important entities fundamental to policy: 513 a policy entry/management tool, a policy repository, a PDP, and a PEP. 514 Please refer to [PLYARCH] for a description of how these entities are 515 used and interact with each other. 517 Note the use of the term "multi-role policy server". This refers to the ability of the policy server to manage and distribute policies of a variety of disciplines, not just those pertaining to networking. However, this document, and the focus of the Policy Framework working group, is limited specifically to networking. 519 Note also how the policy repository spans the policy server and the rest of the environment. This reinforces thinking of the policy repository as a logically centralized (but possibly physically distributed) repository. It also emphasizes one of the prime goals of the work being done in the Policy Framework working group: interoperability. This is shown explicitly in Figure 2 below. 521 Policy Specifications 522 | 523 _________________|_____________________ 524 | | 525 V V 526 +-------------+ +------------+ +-------------+ 527 | POLICY |<--->| POLICY |<--->| POLICY | 528 | SERVER A | | REPOSITORY | | SERVER B | 529 +-------------+ +------------+ +-------------+ 530 | | 531 | | 532 V V 533 +-------------+ +-------------+ 534 | POLICY |-+ | POLICY |-+ 535 | DEVICES | | | DEVICES | | 536 +-------------+ | +-------------+ | 537 | | | | 538 +-------------+ +-------------+ 540 Figure 2. Logically Centralized Policy 541 Repository for Interoperability 543 Specifically, the above figure provides the flexibility for two 544 different policy servers (A and B) to manage their own devices, while 545 still enabling the policy servers to exchange policy information. The 546 two policy servers could represent different vendors or the same vendor. 547 The latter may be required because of physical location reasons, or 548 because the types of devices that Policy Server A manages are very 549 different than those managed by Policy Server B (e.g., QoS policy vs. 550 firewall policy). 552 Although Figure 2 does not show it, the architecture described in Figure 1 also is intended to support the case where a multi-role policy server is not used, and the policy management tool is supplied by one vendor, while the PDP(s) are supplied by another. 554 Again, the point of interoperability in this case, as well as in the 555 the multiple multi-role policy server case, is the Policy Repository. 556 This is discussed further in [PLYARCH]. 558 It has been previously assumed that all policy decisions will always be 559 made in the PDP and implemented in the PEP. In other words, the PEP is 560 not able to make decisions on its own. This is too simplistic a 561 definition. The problem is that policies that are a function of packet 562 conditions can not be evaluated in the PDP, if the PDP is physically 563 separate from the PEP. This is discussed further in [PLYARCH]. 565 The Repository Access Protocol and the Policy Protocol are in general 566 different protocols. If the Policy Repository is a directory, then LDAP 567 is one example of a Repository Access Protocol. However, the Policy 568 Protocol could be any combination of COPS, SNMP, and Telnet/CLI. In fact, different policy protocols could be used between different devices that are governed by the same PDP. 570 4.2 How Policy Decisions Are Made 572 Any PEP that encounters an event requiring a policy-based decision that 573 it can not make by itself first asks its PDP how to handle this request. 574 This results in one or more policy decisions made by the PDP that are 575 in turn communicated to the PEP. A policy decision results in a specific 576 set of operations that either provide a service that was contracted for, 577 or implement a change in state (e.g., in the network) to provide a 578 service. For example, if the network is designed to support 579 differentiated classes of service for handling different types of 580 traffic, network elements could send requests to a policy server asking 581 how to map a given type of traffic, or these network elements could 582 be configured via the policy server or PDP that provides this mapping. 583 Policy decisions would then be made instructing what type of queuing 584 mechanisms to use to handle that traffic (as an example). 586 4.3 What Is A Policy (In General Terms) 588 A policy is formally defined as an aggregation of policy rules. Each 589 policy rule is comprised of a set of conditions and a corresponding set 590 of actions. The conditions define when the policy rule is applicable. 591 Once a policy rule is so activated, one or more actions contained by 592 that policy rule may then be executed. These actions are associated 593 with either meeting or not meeting the set of conditions specified in 594 the policy rule. 596 Policies can contain policies. This notion of hierarchy is crucial, as 597 it enables complex policies to be built from a set of simpler policies, 598 thereby simplifying their management. It also enables reuse of policy 599 building blocks (policy rules, conditions and actions). 601 This definition of policy can be enhanced in several different ways. 602 However, it is the feelings of the authors that as simple as possible 603 (but no simpler) a definition must first be used and put into practice 604 before more complicated definitions of policy are deployed. Otherwise, 605 it will be much harder to achieve interoperability of policy servers, 606 or other policy entities. 608 Policy is a relationship among the attributes of the objects maintained 609 by a policy application that control and manages one or more aspects of 610 a set of PEPs. These PEPs are used to provide a set of services that 611 are regulated by one or more policies. Key to this definition is the 612 ability to separate the specification of the set of services to be 613 provided in a vendor-independent manner from the implementation of 614 vendor-specific mechanisms that are applied to vendor-specific network 615 elements to supply those services. 617 4.4 Real-World Requirements of Policy 619 There are several important requirements of policy. Principal among these are that it must be: 621 - able to be used for large-scale distributed systems as well as 622 small point solutions 623 - widely available to those entities that need access to it 624 - secure 625 - easy to detect conflicts 627 4.4.1 Applicable to Large-Scale Solutions 629 Nothing in the definition of policy, the architecture that is recommended for managing and distributing policy, or the structure of policy itself should prohibit its applicability to large numbers of objects. By large, we mean potentially millions of objects (e.g., IP phones). 631 Policy should be able to be put into a form that enables it to be easily distributed to objects in a domain that need it. One way of accomplishing this is to be able to group policy information and objects into policy domains. The existing use of the word domain has been constrained mostly to refer to a set of contiguous network 632 devices that are under common administrative control. This set of common devices are used to provide a common and consistent set of differentiated services, which are administered in a coordinated fashion. 634 The term domain, as used in the Policy Framework working group, will be expanded to describe a grouping of not necessarily contiguous devices that are administered in a common way. Here, device is also expanded to encompass hosts, firewalls, and other network resources. 636 4.4.2 Secure 638 Security is extremely important for objects that are controlled using policies. This is because limited resources are controlled by policies, and unauthorized access can lead to unfair, or illegal, delegation of and access to these resources. Extra precautions must be taken for managers and policy agents to be authenticated and authorized to perform management actions, in order to protect the system being managed. 640 4.4.3 Easy to Detect Conflicts 642 A critical part of the underlying mental model is that it must be easy 643 to detect conflicts between different policies and resolve them. The 644 simplest view of a policy is that it specifies a set of actions 645 that MUST be performed if a set of associated conditions is met. 646 Therefore, the ability to detect and resolve conflicts between policy 647 definitions (conditions as well as actions that are taken when a 648 set of conditions are met) is crucial. 650 There are many reasons that policies can conflict. A policy can be a member of multiple policy domains, and multiple policies can apply to the same domain. Conflict detection can be done before implementation by syntactic analysis, which will catch the large majority of conflicts. Peculiar cases can occur, such as two policies that appear to conflict but actually don't because they are applied when different situations occur. 652 One way of doing this is by imposing a priority on both the satisfaction of policy conditions as well as the execution of policy actions. However, it should be noted that priority is a fundamental concepts of distributed systems and MUST be supported irrespective of being used to supply a means for policy conflict resolution. 654 4.5 Policy Components 656 Policy is comprised of the following three functions: 658 1. Decision-making. This compares the current state of the network to 659 a desired state described by an application-specific policy and 660 decides how to achieve or maintain the desired state. 661 2. Enforcement. This implements a desired policy state through a set 662 of management commands; when applied to network elements, these 663 management commands change the configuration of the device using 664 one or more mechanisms. These mechanisms MAY be vendor-specific. 665 3. Monitoring: This is an on-going active or passive examination of the 666 network and its constituent devices for checking network health, 667 whether policies are being satisfied, and whether clients are 668 taking unfair advantage of network services. 670 Decision-making uses static and/or dynamic data to determine if a type 671 of policy is being satisfied and, if not, what steps are needed to 672 satisfy that policy. Enforcement refers to the interpretation and 673 execution of policies by consumers who are assumed to be trustworthy. 674 Policing is the auditing of policy compliance to verify that the policy 675 consumers properly implement policies. 677 4.6 Policy-Based Applications and Network Policy 679 Policy is defined in terms of applications or processes that monitor 680 and manipulate one or more entities in order to achieve a desired goal. 681 To make the following discussion simpler to understand, this paper 682 focuses on network policies. 684 A network policy defines the relationships between clients that desire 685 services of the network and the network elements that provide those 686 services. Network Policy applications model two important things: 687 1) the state of the SLAs that they are enforcing, and/or 688 2) some part of the state of the (overall) network in order to 689 ensure that their clients will obtain the services they require 690 of (that portion of) the network. 692 Such applications will maintain a number of objects of various types, 693 each with one or more attributes. Each of these objects either models 694 the state of one or more network elements or maintains some part of the 695 internal state of the policy application. 697 These applications contain the mapping of services desired by users to the network elements that provide those services. A network policy, then, is a relationship among attributes of the objects maintained by the policy application that controls and manages some aspect of the network in terms of one or more services that the network provides. Since the application models some part of the state of the entity, it is also accurate to say that a policy is a statement about the desired state of the entity (e.g., the requirements to maintain its current state or the need to transition to a different state). 699 4.7 Difference Between Policy And Service 701 Service is a very overloaded word. In CIM, a "service" is used to abstract and manage functionality. Service objects represent the management aspects of the functionality provided by an entity (CIM also defines ServiceAccessPoints, which manage the consumption (or access) of that functionality). The functionality is provided by some other object (e.g., a device and/or software feature object). 703 The information model of the Policy Framework working group is based on CIM and DEN. A service is therefore the abstraction of managing functionality provided by one or more other objects. It is NOT the functionality itself. Furthermore, a policy is a statement that controls the access to and/or utilization of resources. A policy can be used to configure and control a service, but it is not the service itself. 705 4.8 Need For Canonical Representation of Policy 707 Policies represent business functions and goals. These correspond to 708 network services, which are provided by vendor-specific network 709 elements. The problem is that vendors will describe the same business 710 function in different ways. This is because business functions are 711 described at a necessarily high level, and are therefore subject to 712 different interpretation. Since the network will implement the services 713 that correspond to these business functions, differences in network 714 elements will exacerbate this mapping. 716 A partial solution is to enforce a consistent representation of policy. All policies MUST consist of a set of policy rules, and all policy rules MUST consist of a set of policy conditions and policy actions. This provides a consistent meta-structure for describing policy, enabling a vendor-independent exchange of policy information. 718 The policy structure should be amenable to implementing simple policies in a correspondingly lightweight fashion. Hence, simple policy rules are rules whose conditions and actions can be embedded in the policy rule directly. Complex policy rules view the policy rule as a container, in which separate policy condition and/or policy action objects are aggregated. 720 This structure provides a flexible and extensible representation of policy. However, it does not guarantee interoperability. One possible solution is to use a canonical representation of policy rules, policy conditions and policy actions. This in turn requires a categorization of policy rule, policy condition, and policy action into a set of application-specific domains (e.g., RSVP and Differentiated Services would have separate policy conditions and actions that identify their applicability). 722 Given a class-based implementation of policy, the above could be 723 implemented easily through defining subclasses that corresponded to 724 the different policies, policy rules, policy conditions, and policy 725 actions that were under control of the PDP. This will be discussed more in [PLYARCH]. 727 5. Policy Terminology 729 The following is a set of policy terminology definitions. 731 5.1 Policy Group 733 A PolicyGroup is a named object that represents an aggregation of 734 PolicyRules. The policy encompassed within a PolicyGroup can describe 735 the overall business function(s) to be accomplished, while the set of 736 policy rules define how those business functions will be met. In this 737 case, the business function(s) correspond to one or more SLOs of an SLA. 739 Alternatively, the PolicyGroup aggregation could be used to group 740 PolicyRules or other PolicyGroups for the purposes of scoping the 741 jursidiction of the policies, or for the purpose of making the 742 administration of the policies more conveniently accessible to those 743 who are assigned to perform this administration. 745 5.2 PolicyRule 747 A PolicyRule is composed of a set of conditions and a corresponding 748 set of actions. This combination in effect defines a sequence of 749 actions to be executed when the corresponding set of conditions is 750 either satisfied or not satisfied. For simplicity, it is recommended 751 that positive (satisfaction) and negative (unable to meet) conditions 752 be realized as separate rules that are folded into a single PolicyRule object. 754 Each PolicyRule is a declarative statement consisting of a Boolean 755 expression that describes a situation to which the policy applies. 756 In its most general form, when the expression is true, one set of 757 actions is initiated, and when false, a different set of actions is 758 initiated. This version of the document will only consider the expression of a rule as a condition statement (e.g., IF some set of conditions are met, THEN take this set of actions). 760 5.3 Policy Condition 762 Policy Conditions consist of two parts, a policy condition type and a 763 policy condition element. This structure is aimed at satisfying the 764 need for a canonical representation of a policy condition. 766 A policy condition type is a set of predefined conditions that can be 767 attached to a policy rule for evaluation. This canonical set of 768 conditions represent common conditions that all network vendors can 769 implement. By including this canonical representation of policy 770 conditions, the resulting set of policy conditions can be exchanged 771 between multiple vendors' policy servers. This is necessary for 772 interoperability as well as for a policy server to be able to parse 773 rules to determine if any rules conflict may potentially conflict 774 with each other. A policy condition element is a policy condition type 775 instance that is being evaluated. Policy condition 776 elements are related together to form a Boolean expression. The 777 relations can be one of the following operators: in, not in, equal, 778 not equal, less than, less than or equal, greater than, and greater 779 than or equal. (Note: These operators are to be captured in the 780 ExpressionCondition object of the information model current at the 781 time of this writing, as well as in discipline-specific schema 782 subclassed from the core information model that are yet to be defined). 784 5.4 Policy Action 786 A policy action is the changing of the configuration of one or more 787 network elements in order to achieve a desired policy state. This (new) 788 policy state provides one or more (new) behaviors. As with policy 789 conditions, a policy action is comprised of two parts, a policy action 790 type and a policy action element. The policy action type defines a 791 canonical set of operations or treatments that can be given to traffic 792 flowing into the network element (e.g., deny, change code point, etc.) 793 that is vendor-independent. Similarly, the policy action element 794 specifies the type of mechanism and/or attribute values to be used to provide the specified operation or treatment. 796 5.5 Policy Decision 798 A policy decision is the abstraction of activating and evaluating one 799 or more policy rules. Each policy rule is interpreted in the context 800 of a specific request (implied or explicit) for accessing and/or using 801 one or more resources. It connotes taking one or more pre-determined 802 actions based on whether or not a given set of policy conditions were 803 satisfied. 805 5.6 Policy Behavior 807 A policy behavior controls how traffic is treated, what network 808 resources must be utilized, and/or what network services are provided. 809 Policy behaviors define one or more mechanisms that are used to 810 implement the policy. Therefore, different devices can carry out the 811 same policy using different behaviors. 813 For example, one router might use a dropping behavior and another might use a queuing behavior during times of congestion in order to satisfy an overall delivery goal. Policy behaviors can include one or more of the following: 815 - permit or deny forwarding of traffic based on: 816 - source and destination address 817 - source and destination port number 818 - protocol type and options 819 - other factors specific to vendor implementations, such as host 820 name and/or time of day 821 - permit or deny access to a requested resource or service 822 - encrypt the header and/or the payload 823 - mark or remark the packet 824 - start or stop accounting and/or auditing 825 - start or stop logging 827 5.7 Policy State 829 A policy state is a description of the settings of one or more network 830 elements. These settings correspond to providing the set of services to 831 be provided by the network. For example, a Service Level Agreement can 832 describe services contracted for by subscribers - this corresponds to a 833 state that various network elements must be put into in order to 834 provide those services. 836 5.8 Effect of Executing a Policy 838 A policy determines the behavior of one or more objects that it affects. This behavior takes one of three basic forms: 840 - allocate (or deny) resources to a given requestor 841 - add or remove resources to a client already using a service that 842 the policy controls 843 - allow or prohibit access to a resource 845 The first two types of policy are contractual policies - they provide resources for a service. The last is an authorization policy - it defines what clients are permitted to do. 847 5.9 Policy Domain 849 A policy domain is a collection of objects that have been explicitly grouped together in order to administratively share the same policies. Domains can be nested, in order to reflect hierarchical semantics. Examples are organizational structures, subnets, and a grouping of policies that supply (for example) increasing freedom and/or privileges at lower and lower levels. 851 A domain does not encapsulate the objects it contains; rather, it holds references to objects that it contains. A domain is thus very similar in concept to a directory or folder in a file system. 853 Domains can be nested within domains. Note, however, that a nested domain is not necessarily a subset of the parent domain, because an object in the nested domain may not be a direct member of its parent domain. 855 Policy domains provide a convenient abstraction for specifying policy for individual objects within a large system. Policy domains separate the policy from the entities that the policy affects. This enables the domain membership to be changed without having to change the policy, and vice-versa. It also provides the flexibility to add and remove objects from a policy domain without changing the definition of the policy itself. 857 5.10 Policy Conflict 859 A policy conflict occurs when the conditions of two or more policies 860 can be simultaneously satisfied, but the actions of at least one of 861 the policies can not be simultaneously executed. This implies 862 several things: 864 - one or more policy rules of each of the policies is satisfied by 865 the same request 866 - each condition of each of the conflicting policy rules is satisfied 867 by the same request 868 - one or more actions specified by one policy conflict with one or 869 more actions specified by the other policy 871 Policy conflicts can be resolved in a number of different ways. The 872 simplest is to change the conditions and/or actions of one of the 873 policies so that it no longer conflicts with the other policies. 874 However, if the policies must remain inherently conflicting, then there 875 are a number of ways to resolve the conflict on an individual event 876 basis, including the following: 878 - apply a "match-first" criteria, wherein conflicts are resolved by 879 matching the first policy that is found 880 - apply a priority order criteria, wherein conflicts are resolved by 881 finding all policy rules which match a given event and selecting 882 only the rule with the highest priority 883 - use additional metadata to determine which rule or rules should be 884 applied. 886 5.10.1 Global Conflict Detection 888 Global conflict detection refers to the ability to detect conflicts that do not affect any one specific object. For example, two policies both select the same user; one gives him GOLD service and the other gives him Bronze service. Another example: one policy says that engineers get GOLD service, and a second policy says that FTP traffic gets Bronze service; what happens when an engineer uses FTP? Since these types of global conflicts do not affect any one specific object, they can be resolved by a centralized component or by each individual PDP. 890 5.10.2 Local Conflict Detection 892 Local conflict detection refers to conflicts that affect specific devices, and/or topology-specific conditions that have conflicting actions. In either case, this type of conflict does affect specific objects. For example, one policy could specify a PHB with 3 queues, while a second policy could specify a PHB with 6 queues. If both of these policies are assigned to the same interface, then there is a local conflict. Note that the global conflict detection component would not have caught this, because it appears that these two policies do not conflict (one has 3 queues and one has 6 queues). It is only when the policies are applied to the network element that this conflict can be detected. 894 5.11 Service Level Agreement (SLA) 896 An SLA is a service contract between a customer and a Service Provider 897 that specifies the expected operational characteristics of their 898 relationship. Example operational characteristics include the details 899 of the treatment which a customer's traffic and/or requests for 900 service should receive. The details of the operational characteristics 901 are defined in terms of Service Level Objectives (SLOs). The SLA 902 documents the agreed levels and parameters of services provided, and 903 can cover a wide range of parameters including items that effect 904 the network element and items that don't (e.g., service hours and 905 availability, user support levels, etc.). 907 5.12 Service Level Objective (SLO) 909 An SLO partitions an SLA into individual objectives that can be mapped 910 into policies that can be executed. The SLOs define metrics to enforce, 911 police, and/or monitor the SLA. Some commonly used metrics to determine 912 whether or not an SLA is being fulfilled include component system 913 availability (e.g., up-time and MTBF), performance (e.g., response 914 time), and serviceability (e.g., MTTR). 916 5.13 Policy Event 918 A policy event is a notification that triggers one or more policy 919 evaluations. A particular event may or may not initiate a policy 920 decision and/or a policy enforcement action. (Note that events are 921 not explicitly recognized in the schema or framework at the time of 922 this writing. Events can be thought of as implicitly requesting 923 a policy evaluation, when appropriate.) 925 5.14 Policy Evaluation 927 Policy evaluation is the determination of whether or not the network 928 (or a part of it) is in a desired policy state. This is usually 929 determined by processing static and/or dynamic data against one or more 930 policy rules, the key point being that the decision is made by 931 comparing definitional data stored in the policy repository with 932 current data from the network that does not have to be stored in the 933 policy repository. If it is found that the network elements are not in 934 the desired policy state, then one or more policy actions will be taken 935 to move the network elements from their current state to the desired 936 state. This is called policy enforcement. 938 5.15 Policy Enforcement 940 Policy enforcement is the action of placing the network (or a part of 941 the network) in a desired policy state using a set of management 942 commands. When this definition is applied to network elements, these 943 management commands change the configuration of the device(s) using 944 one or more mechanisms. Enforcement is carried out in the context of a 945 policy rule. 947 5.16 Policy Monitoring 949 Policy monitoring is an on-going active or passive examination of the 950 network and its constituent devices for checking network health, 951 whether policies are being satisfied, and whether clients are taking 952 unfair advantage of network services. This is done for one or more 953 of the following reasons: 955 - to ensure that clients are receiving the services that they have 956 contracted for 957 - to monitor network statistics as part of checking network health 958 - to monitor network statistics as part of checking whether policies 959 that are currently in use are being satisfied 960 - to ensure that clients of a given set of policies are not abusing 961 their privileges 963 5.17 Policy Agent 965 A policy agent is a software module that generates and responds to 966 policy events, evaluates policies, and enforces policies. 968 5.18 Policy-Driven Service 970 A policy-driven service is a set of cooperating policy agents that 971 define, manage, enforce, and monitor a particular policy. 973 5.19 Policy Audit 975 A policy audit examines conditions in one or more active policies 976 to determine if their actions are being executed correctly and the 977 desired result (e.g., flow of traffic) is being carried out. This 978 is equivalent to checking the state of the network to determine the set 979 of policies that are and are not being satisfied. 981 5.20 Policy Consistency Checking 983 Policy consistency checking is an analysis of currently active policies 984 to determine their consistency or possible inconsistency with each 985 other. When an inconsistency is discovered, a policy discrepancy is 986 reported. 988 5.21 Policy Discrepancy 990 A policy discrepancy is a notification that two or more policies are in 991 actual or potential conflict in the sense that implementation of one 992 policy may prevent or otherwise adversely effect the implementation of 993 the other policies. 995 5.22 Policy Mechanism 997 A policy mechanism is a set of vendor-specific commands that configures 998 a network element to put a policy rule into effect. 1000 5.23 Policy Verification 1002 Policy verification is an analysis of a policy to determine if the 1003 desired state can be established and maintained for the duration of 1004 the corresponding policy rule being active. 1006 5.24 Policy Restoration 1008 Policy Restoration is one or more actions taken to restore the system 1009 to a desired policy state. This could be invoked because of a policy 1010 action in response to an event, or because the current state got 1011 corrupted. 1013 5.25 Roles 1015 In the most general sense, a role describes the duties, rights, and 1016 permissions of an object with respect to the rest of the managed environment. 1018 Specifically for the Policy Framework working group, a role is realized 1019 via the collection object in the policy information model. This collection object aggregates a network object with other objects that a policy is to be applied to. A role is therefore a means of grouping together a set of objects, so that one or more policies can be specified as being applied to the entire group of objects. This provides a better means of abstraction that relying on one or more attribute values to group the objects. 1021 For example, the role (collection object, in our info model) "edge interface" can be assigned to the interface of devices to distinguish them for other interfaces, such as "backbone interface", that perform different functions. This enables all devices that have interfaces matching one of these roles to be referred to by using the descriptive role name, as opposed to having to list a set of IP addresses with their masks. 1023 Roles can be used to identify specific objects (e.g., device interfaces) that should be configured in a common manner using one or more policies. These interfaces may be defined by the purpose that they play in the network (e.g., "edge" vs. "backbone"), the characteristics of the object (e.g., frame relay interfaces require a different configuration than ATM interfaces), or other factors. 1025 "Roles" provide a powerful abstraction mechanism. They enable new policies to be specified for a single role, and have them applied to the devices that use that role. This is much more efficient and less error prone than having to specify a new policy for each and every individual network component. In addition, it enables policies to be modified at the (single) role level, instead of having to search for every occurrence of every policy and individually modify the policy. 1026 But most importantly, it enables the devices and their interfaces to be abstracted from the Policy Server. In other words, the Policy Server no longer needs to have intimate knowledge of each and every device (let alone each and every device interface!) in the network. 1028 At the device (PEP) level, a role is modeled as a collection of interfaces with common interface functions, or collection of objects that contain the common interfaces. In either case, more than one role per object can be defined (see Role Combinations, section 5.25.1, below). 1030 5.25.1 Role Combinations 1032 Role combinations enable an interface to be described by multiple roles. Thus, an object could belong to multiple roles, which is implemented as. multiple collection objects (e.g., "IP Interface", "Classification", and "Edge"). Each of these roles identify particular functions that the object performs in the network, which has its own set of configuration, 1033 or authorization, or other specific functions that are controlled by policy. 1035 6. Policy Example 1037 This section will provide an example of the canonical use of 1038 policies, policy rules, policy conditions and policy actions. 1039 (Note that we are making assumptions here regarding discipline-specific 1040 subclasses of PolicyCondition and PolicyAction, for the purposes 1041 of this example. At the time of this writing, these discipline-specific 1042 subclasses have not yet been defined.) 1044 Assume that the following business rule is to be implemented as 1045 a policy: 1047 Provide the JitterFreeMPEG2 video service for authorized users 1048 between authorized points, but only at agreed-upon times 1050 This rule can be loosely translated as: 1052 IF user IN ApprovedUsers AND service IN VideoServices AND 1053 source IN VideoSources AND destination IN VideoDestinations 1054 AND time IN ApprovedTimePeriods 1055 THEN provide JitterFreeMPEG2 1057 The policy condition is loosely translated as: 1058 IF the user is a member of an approved group (ApprovedUsers) 1059 that are authorized to have this service) 1060 AND the service requested is one supported (VideoServicesgroup) 1061 AND the source of the request is approved (in the VideoSources 1062 group or has been authenticated) 1063 AND the destination is approved (in the VideoDestinations group 1064 or has been authenticated) 1065 AND the time requested is OK (in ApprovedTimePeriods) 1067 Here, the policy condition types are: 1068 user, service, source, destination, and time 1069 and the policy condition elements are: 1070 ApprovedUsers, VideoServices, VideoSources, VideoDestinations, 1071 and ApprovedTimePeriods, which are all instances of pre-defined 1072 groups of objects. 1074 The policy action is: 1075 IF the conditions are satisfied 1076 THEN provide the user with video having a QoS defined by the 1077 JitterFreeMPEG2 service 1079 Note that this policy could require "sub-policies" in order for it to 1080 be implemented. For example, RSVP requests might be used to 1081 precondition the path between VideoSources and VideoDestinations. 1083 7. Terminology For Implementing Policy GUIs 1085 Part of the task of defining policy terminology is to enable policies 1086 to be represented in a user-friendly GUI. This section provides 1087 guidelines for doing this through the introduction of additional 1088 terminology designed expressly for this purpose. 1090 7.1 Types Of Policies 1092 An effective policy GUI MUST be able to categorize and sort policies in 1093 ways that are meaningful to the user. There are three broad means of 1094 doing this, based on differentiating between how a policy is used, 1095 how a policy is triggered, and the attributes of the policy. 1097 7.2 How A Policy Is Used - Service And Usage Policies 1099 Service and Usage Policies are a means of categorizing policies by what 1100 they do and how they are used. Service policies describe services 1101 available in the network. Usage policies describe which policies will 1102 use which services when the conditions of the usage policies are satisfied. Usage policies describe particular mechanism(s) employed to either maintain the current state of the object, or to transition an object from one state to a new state, in order to utilize the specified services. 1104 For example, the fact that a user can get a particular conditioning 1105 treatment, or can use IPSEC to encrypt the payloads of traffic, are 1106 both services that are provided and are represented as service 1107 policies. On the other hand, differentiating between two flows and 1108 assigning different services to the flows is an example of using usage 1109 policies to differentiate the handling of the flows. 1111 7.3 Classifying Policies Based On Attributes 1113 Policies can be classified by the attributes that they possess. This 1114 includes what the policy applies to (e.g., a class of user or a certain 1115 type of application) as well as certain attributes that fundamentally 1116 change the applicability (conditions) and effect (actions) of the 1117 policy. Examples of these include physical location. For example, if a 1118 user is connected to his or her corporate Intranet through the public 1119 internet, then a different security policy might be applied to that 1120 communication and different restrictions may be placed on accessing 1121 resources than when that user connects through the corporate network. 1123 8. Security Considerations 1125 Security and denial of service considerations are not explicitly 1126 Considered in this memo, as they are appropriate for the underlying 1127 policy architecture and not for its terminology. However, the policy 1128 architecture must be secure as far as the following aspects are concerned. 1129 First, the mechanisms proposed under the framework must minimize theft 1130 and denial of service threats. Second, it must be ensured that the entities 1131 (such as PEPs and PDPs) involved in policy control can verify each other's 1132 identity and establish necessary trust before communicating. This terminology 1133 draft reinforces the need for policies to be secure. 1135 9. Acknowledegments 1137 Many thanks to the useful discussions and suggestions from the Internet 1138 Community at large but especially to Andrea Westerinen, John Lee, 1139 Lee Rafalow, Steve Schleimer and Fred Baker. 1141 10. References 1143 [TERMS] S. Bradner, "Key words for use in RFCs to Indicate 1144 Requirement Levels", Internet RFC 2119, March 1997. 1145 [DIFFARCH] D. Black, S. Blake, M. Carlson, E. Davies, Z. Whang, 1146 W. Weiss, "An Architecture for Differentiated Services", 1147 RFC2475, 1148 December 1998 1149 [DIFFSERV] K. Nichols and S. Blake, "Definition of the 1150 Differentiated Services Field (DS Byte) in the 1151 IPv4 and IPv6 Headers", RFC2474, December 1998 1152 [DSFIELD] K. Nichols and S. Blake, "Definition of the Differentiated 1153 Services Field (DS Byte) in the IPv4 and IPv6 Headers", 1154 Internet Draft , 1155 May 1998. 1156 [LDAP] This refers to the current collection of LDAP RFCs 1157 (2251 - 2256) but especially to RFC 2251 (the protocol). 1158 [RAPFRAME] R. Yavatkar, D. Pendarakis, R. Guerin, "A Framework for 1159 Policy-based Admission Control", Internet Draft, 1160 , May 1998 1161 [PLYARCH] G. Waters, et. al., Policy Framework Architecture, 1162 Internet Draft, , 1163 June 1999, and subsequent revisions/replacements of this 1164 document. 1165 [CIM] CIM Specification and CIM Schemata are available at: 1166 http://www.dmtf.org/spec/cims.html 1168 [ISWG] Integrated Services Working Group, whose home page is: 1169 http://www.ietf.org/html.charters/intserv-charter.html 1171 [DSWG] Differentiated Services Working Group, whose home page is: 1172 http://www.ietf.org/html.charters/diffserv-charter.html 1174 [RAPWG] RSVP Admission Policy Working Group, whose home page is: 1175 http://www.ietf.org/html.charters/rap-charter.html 1177 [ISSLLWG] Integrated Services over Specific Link Layers, 1178 whose home page is: 1179 http://www.ietf.org/html.charters/issll-charter.html 1181 [IPSECWG] IP Security Protocol Working Group, whose home page is: 1182 http://www.ietf.org/html.charters/ipsec-charter.html 1183 11. Authors' Addresses 1185 John Strassner 1186 Cisco Systems 1187 Bldg E 1188 190 West Tasman Drive 1189 San Jose, CA 95134 1190 Phone: +1-408-527-1069 1191 Fax: +1-408-527-2477 1192 E-mail: johns@cisco.com 1194 Ed Ellesson 1195 JDGA/501 1196 IBM Corporation 1197 4205 S. Miami Blvd. 1198 Research Triangle Park, NC 27709 1199 Phone: +1-919-254-4115 1200 Fax: +1-919-254-6243 1201 E-mail: ellesson@raleigh.ibm.com 1203 12. Full Copyright Statement 1205 Copyright (C) The Internet Society (1999). All Rights Reserved. 1207 This document and translations of it may be copied and furnished to 1208 others, and derivative works that comment on or otherwise explain it 1209 or assist in its implementation may be prepared, copied, published 1210 and distributed, in whole or in part, without restriction of any 1211 kind, provided that the above copyright notice and this paragraph are 1212 included on all such copies and derivative works. However, this 1213 document itself may not be modified in any way, such as by removing 1214 the copyright notice or references to the Internet Society or other 1215 Internet organizations, except as needed for the purpose of 1216 developing Internet standards in which case the procedures for 1217 copyrights defined in the Internet Standards process must be 1218 followed, or as required to translate it into languages other than 1219 English. 1221 The limited permissions granted above are perpetual and will not be 1222 revoked by the Internet Society or its successors or assigns. 1224 This document and the information contained herein is provided on an 1225 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1226 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1227 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1228 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1229 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.