Internet Draft Francis Reichmeyer Expiration: March 2000 IPHighway File: draft-ops-mumble-terminology-00.txt Mark Stevens Lucent A Unified Terminology for Policy Based Networking 22-October-1999 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (1998). All Rights Reserved. Internet Draft Expires March 2000 [Page 1] Internet Draft 22-Oct-99 Abstract Policy Based Networking (PBN) is a topic of interest to many areas within the networking community. Initially considered for the implementation and control of QoS services, several groups are looking to deploy policy-based networks for a wider variety of applications, such as security and VPN. We have found, when trying to coordinate efforts of the different groups, that there are some misunderstandings among the groups, some of which can be attributed to the different terminology that has propagated through the groups. In this draft, we attempt to clear up some of these misunderstandings, concentrating on PBN for Policy Provisioning (rap), Differentiated Services (diffserv), IP Security (ipsp), and general Policy Framework (policy). The terminology discussed here is not meant to be an exhaustive list of PBN-related terms and concepts, but it is intended to represent at least the four areas mentioned. It is NOT intended that this draft defines an architecture or framework for PBN _ each group is clearly qualified to define these for themselves. Instead, we identify the terminology common to all PBN applications and suggest definitions, which are meaningful and useful, yet general enough to be applicable across all PBN applications. Reichmeyer, et al. Expires March 2000 [Page 2] Internet Draft 22-Oct-99 Table of Contents Abstract..............................................................2 Table of Contents.....................................................3 1 Introduction ......................................................4 2 Terminology for Common PBN Components .............................5 2.1PBN Management Models .............................................6 2.2Policy Decision Point/Policy Consumer .............................7 2.3Policy Enforcement Point/Policy Target ............................7 2.4Policy Repository .................................................8 2.5Policy Rules ......................................................8 2.6Policy Requests ...................................................9 2.7Policy Decisions ..................................................9 3 General PBN Terminology ...........................................9 3.1Roles .............................................................9 3.2Service Level Agreement (SLA) ....................................10 4 IP Security Policy Terminology ...................................10 5 DiffServ Policy Terminology ......................................11 6 References .......................................................12 7 Author Information ...............................................13 8 Full Copyright Notice ............................................14 Reichmeyer, et al. Expires March 2000 [Page 3] Internet Draft 22-Oct-99 1 Introduction Policy Based Networking (PBN) is a topic of interest to many areas within the networking community. Initially considered for the implementation and control of QoS services, people are looking to deploy policy-based networks for a wider variety of applications, such as security and VPN. As various groups begin developing architectures and protocol specifications related to their specific PBN needs, we have found that there is some overlap in the terminology defined _ different terms used to describe basically the same concept. We've also found, when trying to coordinate efforts of the different groups, that there are some misunderstandings among the people in the groups and some of that misunderstanding can be attributed to the different terminology that has propagated through the groups. In this draft, we attempt to clear up some of these misunderstandings as well as to eventually eliminate some of the overlap in like terms. We concentrate on the areas of Policy Provisioning (rap), policy for Differentiated Services (diffserv), IP Security policy (ipsp), and general Policy Framework (policy). The terminology discussed here is not meant to be an exhaustive list of PBN-related terms and concepts, but it is intended to represent at least the four areas mentioned. These areas are in the forefront of PBN development and are working to coordinate efforts so that a common PBN model can be agreed upon. This draft does NOT define an architecture or framework for PBN _ each group is undoubtedly better qualified to define these for their specific needs. Instead, we identify the terminology common to all PBN applications and suggest definitions, which are meaningful and useful, yet general enough to be applicable across all PBN applications. In doing so, it will be easier and more efficient to coordinate PBN efforts and provide the mechanisms for a single PBN system that supports all policy applications. Most of the terminology in this draft has appeared in other IETF Internet Drafts in one form or another; some is being introduced for the first time. As the terms in this draft are meant to be relevant to a number of different working groups, it is unrealistic to think that a first cut at this will be complete. The intention of this draft is to present the existing terminology and identify areas of conflict with terms and concepts that are common to multiple policy applications, e.g. where similar terms are used with different definitions, or different terms are used for the same definition. Upon reviewing the drafts from the various working groups and participating in meetings attended by representatives of the different groups, it becomes apparent there are differences in some of the "basic" PBN concepts. This is to be expected given the different starting points and goals of the groups. However, it should be possible to go back and revisit the terms and concepts and Reichmeyer, et al. Expires March 2000 [Page 4] Internet Draft 22-Oct-99 come up with a unified set of definitions that can be applied and shared among all policy applications. Once such a unified terminology exists, architectures for new PBN applications will be able to be described easily and efficiently using common building blocks. For example, with common terms and definitions for the functional components of a PBN system (two such terms are "PDP" and "PEP" while "Policy Consumer" and "Policy Target" have also been suggested for the same components) one can look at the architecture of a PBN application and identify where the functionality resides. In the following sections, we'll the various terms and definitions that currently exist for some of basic PBN components and concepts. We expect future versions of the draft to contain a complete list for a unified PBN terminology. 2 Terminology for Common PBN Components Describing different policy applications has resulted in some similar PBN terms and concepts with slightly varying meanings. For example, the PBN architectures for policy outsourcing and policy provisioning described by the RAP WG have both include a Policy Decision Point (PDP) that controls network devices that act as Policy Enforcement Points (PEP). However, the role of the PDP is slightly different in the two models and this can lead to processing policy rules differently in the two cases. In the outsourcing case, the PDP might issue a decision of the form "accept the admission control request" whereas in the provisioning case a PDP message might be "mark packets with this DHCP value." These different directives from the PDP have lead to some question about whether it, functionally, is a "decision point" in all cases. As a result, this same component has been called a Policy Consumer in the Policy WG framework document. In the actual enforcement of the policy at the data level in the network device, the behavior is similar, but the policy rules that need to be stored and processed are different. Both PEP and Policy Target have been used to define this component. If we consider a IP Security Policy application, the policy rules and processing might be different still, as will the terminology for the functional components of the system. Thus, although in these simplified examples, all three PBN applications define similar components, different terms are used and they mean slightly different things in each case. In order to describe a common PBN system, applicable to all cases, the components need to be defined in a way that is meaningful to all applications. Reichmeyer, et al. Expires March 2000 [Page 5] Internet Draft 22-Oct-99 The following concepts are common to all the PBN applications of interest here: - PBN Management Model o how components interact and process policy information - Policy Decision Point/Policy Consumer o component that controls the network devices - Policy Enforcement Point/Policy Target o component that applies the policy to IP data packets - Policy Repository o where PBN policies are stored - Policy Rules o "instructions" for the PBN system - Policy Requests o requests passed into or within a PBN system - Policy Decisions o directives generated as a result of a request The following sections examine these PBN concepts and present the existing terminology for each. 2.1 PBN Management Models The management model for PBN describes how the different components of the system interact and process policy information in order to implement policy based networking. There are two types of policy management models discussed: Outsourcing and Provisioning. The Outsourcing model describes how policy is implemented in situations where network devices refer to a PBN management component to provide policy decisions for requests initiated by the network devices themselves. The requests are typically the result of some event occurring at the device that requires a policy decision, for example receiving a signaling protocol message. A specific example is the COPS-RSVP [cops-rsvp] case, described in the RAP WG [rap- frame], where RSVP nodes outsource policy decisions for RSVP Path and Resv messages they receive. The Provisioning model describes how policy is implemented in situations where the PBN management system issues directives to the network devices preparing them, in advance, for some event that may occur in the network; usually the arrival of some IP data or control traffic that requires particular processing behavior. Since the policy prepares the network beforehand, prior to the packets actually arriving, we use the term provisioning policy. For a specific example, the Diffserv architecture [rfc2475] defines the following: Reichmeyer, et al. Expires March 2000 [Page 6] Internet Draft 22-Oct-99 - Service Provisioning Policy: a policy which defines how traffic conditioners are configured on DS boundary nodes and how traffic streams are mapped to DS behavior aggregates to achieve a range of services. 2.2 Policy Decision Point/Policy Consumer There are at least two models for implementing policy in IP networks, outsourcing and provisioning, as described above. Policy- based network management will probably utilize both models. A policy model based on outsourcing decisions establishes a software process that responds to queries triggered by events occurring within network elements. In the decision outsource model the software process is referred to a PDP or Policy Decision Point. The PDP is in a position to read and evaluate expressions of policy and render a decision on behalf of the device making the request for a decision. The PDP is where the decision is made in the outsource model. In an alternate policy model, decisions can be distributed. In such a model, it makes little sense to refer to a decision point. Policy expressions in this model may contain operands that cannot be obtained in real-time at a centralize point. As a result, translation and configuration operations occur. A software process is established to interpret policy. As the interpretation dictates, the configuration of devices may be altered. Altering the configuration of network elements effectively implements the policy, but in reality some of the operands in the policy are evaluated outside of the network element while other operands of the same policy are evaluated within the device. In such cases, the terms Policy Consumer and Policy Target are used. 2.3 Policy Enforcement Point/Policy Target Network devices play a part in PBN as the points in the network where the policy directives issued by PBN management are carried out on the IP data traffic in the network. The term Policy Enforcement Point (PEP) has been used to describe these devices [RAPFRAME] for both outsourcing and provisioning models, since the policy is enforced on the IP individual packets in both cases. For example, in the devices, packets get classified, queued, dropped, etc. based on the installed policy regardless of whether the installed policy is a result of a response to a request (outsourcing) or an asynchronous message (provisioning). The Policy Framework [TERMS] document offers the following definition: Reichmeyer, et al. Expires March 2000 [Page 7] Internet Draft 22-Oct-99 - Policy Enforcement: the action of placing the network (or a part of the network) in a desired policy state using a set of management commands. When this definition is applied to network elements, these management commands change the configuration of the device(s) using one or more mechanisms. Enforcement is carried out in the context of a policy rule. However, as described in the previous section, the Policy framework draft [PLYFRAME] uses the term Policy Target to refer to the PBN component controlled by Policy Consumers. To work toward reconciling the two views of enforcement, we must recognize that the term PEP implies that the enforcement of a policy occurs in one distinct location. The term Policy Target acknowledges that in certain situations activities related to the enforcement of a given policy can be distributed among more than on entity in a policy system. In policy model that outsources decisions, the enforcement is thought to be localized in the device that requested a decision be made by an external entity. In a policy model that utilizes translation and configuration, policy enforcement activities can be seen as happening in multiple locations. In the case where a Policy Rule contains both operands whose expansions cannot be done in a device, and operands that must be expanded in a device, enforcement is seen occurring as a result of actions taken in both an external process (the Policy Consumer) and the device itself (the Policy Target). The Policy Target is the device whose behavior is modified by the policy, but is not the only component in the policy system involved in the enforcement of the given policy. 2.4 Policy Repository A Policy Repository provides persistent storage and retrieval of Policy Rules. The repository simply stores data. It does not in general process or act on it. The term does not imply a particular access protocol. For persistent storage to be useful in a policy system, the organization of information representing Policy Rules must be standardized. The core policy schema is on example of a standard for organizing the storage of Policy Rules. 2.5 Policy Rules Policy Rules are expressions of policy stored in a Policy Repository and structurally organized according to the structural model defined by the core policy information model. See [INFO]. Ultimately, Policy Rules will have to contain operands and operators to express the conditions and the actions of a policy. A first pass at the standardization of the QoS operands can be found at [MODEL]. A forthcoming draft will refine the QoS information model. See [REFINE]. Operands will be of little use without standardized operators. At present there is no clear work in the area of operator Reichmeyer, et al. Expires March 2000 [Page 8] Internet Draft 22-Oct-99 definition available, but on going discussions in the Policy working group are expected to yield a plan for the development of a draft to define operators. 2.6 Policy Requests 2.7 Policy Decisions [TERMS] defines a policy decision as follows: - Policy Decision: the abstraction of activating and evaluating one or more policy rules. Each policy rule is interpreted in the context of a specific request (implied or explicit) for accessing and/or using one or more resources. It connotes taking one or more pre-determined actions based on whether or not a given set of policy conditions was satisfied. 3 General PBN Terminology A number of terms and concepts have appeared which may not necessarily be applicable to all PBN systems, but which none the less have been interpreted differently among the groups that have tried to apply them. This section discusses some of these terms. 3.1 Roles Roles (and role combinations) have been discussed in the context of the Policy Information Base [PIB], described for use with the COPS- PR policy protocol, as well as in the Policy Framework WG. [PIB] defines roles with regard to policy classes while [TERMS] approaches the concept of a role from the point of view of the policy schema and policy information model. In [PIB] a role is defined as simply a string that is associated with an interface to describe the functions of an interface. A "role-combination" is an unordered set of roles. Instances of a given policy rule class are applied to interface if and only if the set of roles in the role combination is identical to the set of the roles of the interface. As defined in [TERMS], a role, in the most general sense, describes the duties, rights, and permissions of an object with respect to the rest of the managed environment. A role is realized 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. Reichmeyer, et al. Expires March 2000 [Page 9] Internet Draft 22-Oct-99 3.2 Service Level Agreement (SLA) Service Level Agreements (SLA) are often referred to in PBN in the context of specifying and sharing policies between domains. Several definitions have been given for SLAs; the first one given here is proposed in the diff serv architecture RFC and the second one is a revised definition appearing the Policy Framework terminology draft. From [DIFFARCH]: Service Level Agreement: a service contract between a customer and a service provider that specifies the forwarding service a customer should receive. A customer may be a user organization (source domain) or another DS domain (upstream domain). A SLA may include traffic conditioning rules which constitute a TCA in whole or in part. From [TERMS]: Service Level Agreement: a service contract between a customer and a Service Provider that specifies the expected operational characteristics of their relationship. Example operational characteristics include the details of the treatment which a customer's traffic and/or requests for service should receive. The details of the operational characteristics are defined in terms of Service Level Objectives (SLOs). The SLA documents the agreed levels and parameters of services provided, and can cover a wide range of parameters including items that effect the network element and items that don't (e.g., service hours and availability, user support levels, etc.). Service Level Objective (SLO): partitions an SLA into individual objectives that can be mapped into policies that can be executed. The SLOs define metrics to enforce, police, and/or monitor the SLA. Some commonly used metrics to determine whether or not an SLA is being fulfilled include component system availability (e.g., up-time and MTBF), performance (e.g., response time), and serviceability (e.g., MTTR). 4 IP Security Policy Terminology While PBN frameworks, architectures, and protocols for Diff Serv, RSVP, general policy frameworks, etc. have been worked on with relatively close coordination, policy for IP Security applications has just recently begun to engage with the other groups. This section describes the terminology used in the IPSec policy specifications. The following definitions appear in [SEPOL]: Reichmeyer, et al. Expires March 2000 [Page 10] Internet Draft 22-Oct-99 - Security Gateway: A security gateway refers to an intermediate system that implements IPSec protocols. For example, a router or a firewall implementing IPSec is a security gateway. - Security Domain: A set of communicating entities and resources that share a common security policy enforced at one or more enforcement agents or at an individual host. The definition of security domain applies to networks protected by security gateways as well as to single hosts, since a host may be the enforcer of its own policies. Security domains could exist inside other security domains. 5 DiffServ Policy Terminology Policy for Differentiated Services encompasses the efforts of several groups since the initial concentration for PBN has been for QoS networks. With Diffserv, policy based management is concerned with controlling the elements and mechanisms defined by Diffserv to implement differentiated services. Hence, most definitions and terminology from the Diffserv WG could be related back to policy and included in a unified PBN terminology. For example, PIBs and QoS policy schema refer to definitions of packet classifiers, markers, shapers, etc. However it seems a bit unwieldy to include all of the terminology here. Most PBN efforts are committed to participating in and tracking the Diffserv specifications and conforming to them. Reichmeyer, et al. Expires March 2000 [Page 11] Internet Draft 22-Oct-99 6 References [COPS] Boyle, J., Cohen, R., Durham, D., Herzog, S., Raja, R., Sastry, A., "The COPS (Common Open Policy Service) Protocol", IETF , August 1999. [COPSRSVP]Boyle, J., Cohen, R., Durham, D., Herzog, S., Rajan, R., Sastry, A., "COPS Usage for RSVP", , June 1999. [COPSPR] Reichmeyer, F., et. al., "COPS Usage for Policy Provisioning", , November 1999. [MODEL] Weiss, W., Strassner, J., Westerinen, A., "Terminology for Describing Network Policy and Services ", IETF , August 1999. [REFINE] Weiss, W., Strassner, J., Westerinen, A., "Terminology for Describing Network Policy and Services", IETF , October 1999. [INFO] Moore, B., Ellesson, E., Strassner, J., "Policy Framework Core Information Model", IETF , October 1999. [PIB] Fine, M., McCloghrie, K., Hahn, S., Chan, K., Smith, A., "An Initial Quality of Service Policy Information Base for COPS- PR Clients and Servers", , February 1999. [PLYFRAME] Stevens, M., et. al., Policy Framework, Internet Draft, , September 1999. [RAP] Yavatkar, R., et al., "A Framework for Policy Based Admission Control", IETF , April 1999. [RAPFRAME]Yavatkar, R., et al., "A Framework for Policy Based Admission Control", IETF , April 1999. [SECPOL] Srisuresh, P., Sanchez, L.A., "Policy Framework for IP Security_, , February 1999. [TERMS] Strassner, J., Ellesson, E., "Terminology for Describing Network Policy and Services", , June 1999. Reichmeyer, et al. Expires March 2000 [Page 12] Internet Draft 22-Oct-99 7 Author Information Francis Reichmeyer IPHighway Inc. 400 Kelby St. Fort-Lee, NJ 07024 Email:franr@iphighway.com Mark Stevens Lucent Technologies 300 Baker Ave. Concord, MA 01742 Email:markstevens@lucent.com Reichmeyer, et al. Expires March 2000 [Page 13] Internet Draft 22-Oct-99 8 Full Copyright Notice Copyright (C) The Internet Society (1997). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Reichmeyer, et al. Expires March 2000 [Page 14]