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
<draft-ops-mumble-terminology-00.txt>
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 <draft-ietf-rap-cops-07.txt>, August 1999.
[COPSRSVP]Boyle, J., Cohen, R., Durham, D., Herzog, S., Rajan, R.,
Sastry, A., "COPS Usage for RSVP", <draft-ietf-rap-cops-
rsvp-05.txt>, June 1999.
[COPSPR] Reichmeyer, F., et. al., "COPS Usage for Policy
Provisioning", <draft-ietf-rap-cops-pr-01.txt>, November
1999.
[MODEL] Weiss, W., Strassner, J., Westerinen, A., "Terminology for
Describing Network Policy and Services ", IETF <draft-weiss-
policy-device-qos-model-00.txt>, August 1999.
[REFINE] Weiss, W., Strassner, J., Westerinen, A., "Terminology for
Describing Network Policy and Services", IETF <draft-weiss-
policy-device-qos-model-01.txt>, October 1999.
[INFO] Moore, B., Ellesson, E., Strassner, J., "Policy Framework
Core Information Model", IETF <draft-ietf-policy-core-info-
model-02.txt>, 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", <draft-mfine-cops-pib-00.txt>,
February 1999.
[PLYFRAME] Stevens, M., et. al., Policy Framework, Internet Draft,
<draft-ietf-policy-framework-00.txt>, September 1999.
[RAP] Yavatkar, R., et al., "A Framework for Policy Based
Admission Control", IETF <draft-ietf-rap-framework-03.txt>,
April 1999.
[RAPFRAME]Yavatkar, R., et al., "A Framework for Policy Based
Admission Control", IETF <draft-ietf-rap-framework-03.txt>,
April 1999.
[SECPOL] Srisuresh, P., Sanchez, L.A., "Policy Framework for IP
Security_, <draft-ietf-ipsec-policy-framework-00.txt>,
February 1999.
[TERMS] Strassner, J., Ellesson, E., "Terminology for Describing
Network Policy and Services", <draft-ietf-policy-terms-
00.txt>, 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]