[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 01

Internet Engineering Task Force                         John Strassner
INTERNET DRAFT                                          Cisco Systems
5 August 1998                                           Ed Ellesson
                                                        IBM

           Terminology for describing network policy and services
                     draft-strassner-policy-terms-00.txt

Status of Memo

This document is an Internet-Draft.  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."

To learn the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.ietf.org (US East Coast), nic.nordu.net
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).

Abstract

Recent work in the IETF has led to multiple protocols which support
the classification of packets for the purposes of treating certain
classes or flows of packets in a particular way compared to other
packets. The successful wide-scale deployment of these protocols
depends on the ability to administer and distribute consistent policy
information to the multiple devices in the network which perform the
classification and packet conditioning or treatment. As a result,
there is a clear need to develop a scalable framework for policy
administration and distribution that will enable interoperability
among multiple devices and device types that must work together to
achieve a consistent implementation of policy.

Unfortunately, terms like 'policy' and 'service' are not
currently defined in sufficient detail as to enable the definition,
specification, and implementation of policy servers and how policy is
recognized and enforced at the device level. At present, both 'policy'
and 'service' (as well as other related terms) are overloaded with
multiple (often conflicting) meanings. This makes communication about
policy in general and specifically policy-based networking cumbersome
and difficult.

This document defines a set of terms that the Internet community can
use to exchange ideas on how policy creation, administration,
management, and distribution could work among policy servers and
multiple device types.



Strassner and Ellesson      Expires 5 March 1999               [Page 1]


INTERNET DRAFT   draft-strassner-policy-terms-00.txt    5 August 1998

Definition of Key Word Usage

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED",  and "MAY" in this document
are to be interpreted as described in RFC 2119 [TERMS]. These words
will be capitalized to ensure that their intent in this context is
easily discernible.

Table of Contents

      Status of this memo                                           1
      Abstract                                                      1
      Definition of Key Word Usage                                  2
      Table of Contents                                             2
1.    Introduction and Motivation                                   4
2.    Previously Defined Terminology                                4
3.    Areas of Terminology Conflict                                 7
4.    Policy Mental Model                                           7
4.1   General Policy Architecture                                   8
4.2   How Policy Decisions Are Made                                 9
4.3   What Is A Policy (In General Terms)                           9
4.4   Real-World Requirements of Policy                            10
4.5   Policy Components                                            10
4.6   Policy-Based Applications And Network Policy                 10
4.7   Difference Between Policy And Service                        11
4.8   Need For Canonical Representation Of Policy                  11
5.    Policy Terminology                                           12
5.1   Policy                                                       12
5.2   Policy Rule                                                  12
5.3   Policy Condition                                             12
5.4   Policy Action                                                13
5.5   Policy Decision                                              13
5.6   Policy Behavior                                              13
5.7   Policy State                                                 13
5.8   Policy Conflict                                              14
5.9   Service Level Agreement                                      14
5.10  Service Level Objective                                      14
5.11  Policy Event                                                 15
5.12  Policy Evaluation                                            15
5.13  Policy Enforcement                                           15
5.14  Policy Policing                                              15
5.15  Policy Agent                                                 15
5.16  Policy-Driven Service                                        15
5.17  Policy Audit                                                 16
5.18  Policy Consistency Checking                                  16
5.19  Policy Discrepancy                                           16
5.20  Policy Mechanism                                             16
5.21  Policy Verification                                          16
5.22  Policy Restoration                                           16
6.    Policy Example                                               16



Strassner and Ellesson      Expires 5 March 1999               [Page 2]


INTERNET DRAFT   draft-strassner-policy-terms-00.txt    5 August 1998

Table of Contents (continued)

7.    Terminology For Implementing Policy GUIs                     18
7.1   Types Of Policies                                            18
7.2   How A Policy Is Used - Service And Usage Policies            18
7.3   How A Policy Is Triggered - Static vs. Dynamic Policies      18
7.3.1 Static Policies                                              18
7.3.2 Dynamic Policies                                             19
7.4   Classifying Policies Based On Attributes                     19
7.5   Policy Triggers                                              19
8.    Security Considerations                                      19
9.    Acknowledgements                                             20
10.   References                                                   20
11.   Author's Addresses                                           20







































Strassner and Ellesson      Expires 5 March 1999               [Page 3]


INTERNET DRAFT   draft-strassner-policy-terms-00.txt    5 August 1998

1. Introduction and Motivation

Recent work in the IETF has led to protocols which support the
classification of packets for the purposes of treating certain
classes or flows of packets in a particular way compared to other
packets.  The purpose of such classification may include preferential
queuing or dropping, admitting or denying access, or encrypting the
packet's payload, to cite just a few examples. Protocols that
explicitly support some or all of these functions include COPS,
RADIUS, RSVP, IntServ, DiffServ, ISSLL, DSSLL, and IPSEC.

The successful wide-scale deployment these and other protocols depends
on the ability for the administrator of a network domain to administer
and distribute consistent policy information to the multiple devices
in the network which perform the classification and packet
conditioning or treatment.  Protocols that could be used for the
distribution of the policy include LDAP, COPS, SNMP, and TELNET/CLI.
The multiple types of devices that must work in concert across even a
single domain to achieve the desired policy can include hosts (clients
and servers), routers, switches, firewalls, bandwidth brokers, subnet
bandwidth managers, network access servers, and policy servers, to name
just a few.

As a result, there is a clear need to develop a scalable framework for
policy administration and distribution that will allow interoperability
among the multiple devices and device types that must work together to
achieve a consistent implementation of the network administrator's
policy. Unfortunately, terms like "policy" and "service" are not
currently defined in sufficient detail as to enable the definition,
specification, and implementation of policy servers and how policy is
recognized and enforced at the device level. At present, both "policy"
and "service" (as well as other related terms) are overloaded with
multiple (often conflicting) meanings. This makes communication about
policy in general and specifically policy-based networking cumbersome
and difficult.

This document defines a set of terms that the Internet community can
use to exchange ideas on how policy creation, administration,
management, and distribution could work among policy servers and
multiple device types.

2. Previously Defined Terminology

The following terms have been previously defined in other Internet
Drafts and are used in this draft to better define policy and policy-
based networking terms.

Definitions taken from draft-ietf-diffserv-00.txt:
  - Service: a description of the overall treatment of a customer's
    traffic within a particular domain or end-to-end.



Strassner and Ellesson      Expires 5 March 1999               [Page 4]


INTERNET DRAFT   draft-strassner-policy-terms-00.txt    5 August 1998

Definitions taken from draft-ietf-diffserv-arch-00.txt
  - Differentiated Services (DS):  a paradigm for providing quality-
    of-service (QoS) in the Internet by employing a small,
    well-defined set of building blocks from which a variety of
    services may be built.

  - DS behavior aggregate:  a stream of packets that have the same
    DS codepoint.

  - DS capable [node]:  [a node] able to support differentiated
    services functions and behaviors as defined in [DSFIELD],
    [DIFFARCH], and other [related] documents.

  - DS codepoint:  a specific bit-pattern of the DS field.

  - Mechanism: a specific algorithm or operation (e.g., queueing
    discipline) that is implemented in a node to realize a set of one
    or more per-hop behaviors.

  - Per-Hop-Behavior (PHB):  the externally observable forwarding
    behavior applied at a DS capable node to a DS behavior aggregate.

  - Policing: the process of applying traffic conditioning functions
    such as marking or discarding to a traffic stream in accordance
    with the state of a corresponding meter.

  - Service:  the overall treatment of a defined subset of a customer's
    traffic within a DS domain or end-to-end.

  - Service Level Agreement (SLA): a service contract between a
    customer and a service provider that specifies the details of a
    TCA and the corresponding service behavior a customer should
    receive. A customer may be a user organization or another
    DS domain.

  - Service Provisioning:  a policy which defines how traffic Policy
    conditioners are configured on DS edge nodes and how traffic
    streams are mapped to DS behavior aggregates to achieve a range
    of service behaviors.

  - Traffic conditioning:  control functions performed to enforce rules
    specified in a TCA and to prepare traffic for differentiated
    services, including classifying, metering, marking, policing, and
    shaping.

  - Traffic Conditioning Agreement (TCA): an agreement specifying
    classifier rules and the corresponding traffic profiles and
    metering, marking, policing and/or shaping rules which are to
    apply to the traffic streams selected by the classifier.




Strassner and Ellesson      Expires 5 March 1999               [Page 5]


INTERNET DRAFT   draft-strassner-policy-terms-00.txt    5 August 1998

Definitions taken from draft-ietf-rap-framework-01.txt:
  - Administrative Domain: A collection of network elements under the
    same administrative control and grouped together for administrative
    purposes.

  - Network Element (also called a Node): A networking device, such as
    a router, a switch, or a hub, where resource allocation decisions
    have to be made and the decisions have to be enforced.

  - Policy: The combination of rules and services where rules define
    the criteria for resource access and usage.

  - Policy control: The application of rules to determine whether or
    not access to a particular resource should be granted.

  - Policy Object:  Contains policy-related info such as policy
    elements and is carried by the QoS signaling protocol.

  - Policy Element: Subdivision of policy objects; contains single
    units of information necessary for the evaluation of policy rules.

  - Policy Decision Point (PDP): The point where policy decisions
    are made.

  - Policy Enforcement Point (PEP): The point where the policy
    decisions are actually enforced.

  - Policy Ignorant Node (PIN): A network element that does not
    explicitly support policy control using the mechanisms defined in
    this document.

  - Resource: Something of value in a network infrastructure to which
    rules or policy criteria are first applied before access is
    granted.

  - Service Provider: Controls the network infrastructure and may be
    responsible for the charging and accounting of services.

  - Soft State Model - Soft state is a form of the stateful model that
    times out installed state at a PEP or PDP.

  - Installed State: A new and unique request made from a PEP to a PDP
    that must be explicitly deleted.

  - Trusted Node: A node that is within the boundaries of an
    administrative domain (AD) and is trusted in the sense that the
    admission control requests from such a node do not necessarily need
    a PDP decision.





Strassner and Ellesson      Expires 5 March 1999               [Page 6]


INTERNET DRAFT   draft-strassner-policy-terms-00.txt    5 August 1998

3. Areas of Terminology Conflict

Section 2 listed previously-defined terms that are related to the
definition of policy and policy-based networking. Of these terms, the
following terms that have been previously defined need more definition
in order to satisfy the goals of this document, and will be redefined
in subsequent sections of this document:

 NAME OF THE TERM   DEFINED IN      PROBLEM WITH DEFINITION
  Service           [DIFFSERV],   Too simplistic a definition; needs
                    [DIFFARCH]    to be a more general concept

  Policing          [DIFFARCH]    Too specific to traffic conditioning

  Service Level     [DIFFARCH]    Too specific to traffic conditioning
  Agreement (SLA)

  Service           [DIFFARCH]    Too specific to Differentiated
  Provisioning                    Services architecture

  Policy            [RAPFRAME]    Too simplistic a definition

  Policy control    [RAPFRAME]    Too simplistic a definition

  Policy Object     [RAPFRAME]    Too specific to using QoS
                                  signaling protocol as transport

4. Policy Mental Model

In the general sense, policies represent business goals and objectives,
and describe how resources are allocated to meet these goals and
objectives. With respect to networking, policy refers to the ability to
administer and manage network elements in order to provide a set of
services to clients of the network. "Clients" in this context refer to
users as well as applications and services.

An underlying assumption of this draft is that policy is stored in a
centralized repository. This repository may be, but is not limited to,
a directory accessed using the LDAP protocol [LDAP]. The rest of this
section defines the underlying mental model to support this definition
of policy and policy-based networking.












Strassner and Ellesson      Expires 5 March 1999               [Page 7]


INTERNET DRAFT   draft-strassner-policy-terms-00.txt    5 August 1998

4.1  General Policy Architecture

A general architecture is shown in Figure 1 below. This architecture is
similar to that proposed in [SLA] with some minor modifications.

                    +-------------------+
                    | Management Tool   |
                    +-------------------+
                    | Repository Client |
                    +--------+----------+
                             |  <--- Repository Access Protocol
                             |
                    +--------------------+
                    | Policy Repository  |
                    | (Directory Server, |
                    |  Database, etc. )  |
                    +--------+-----------+
                             |  <--- Repository Access Protocol
                             |
                    +--------+------------+
                    |   Repository Client |
                    +---------------------+
                    |   Policy Decision   |
                    |     Point (PDP)     |
                    +---------------------+
                             | <---  Policy Protocol
                             |
                    +--------+------------+
                    |  Policy Enforcement |
                    |     Point (PEP)     |
                    +---------------------+

                Figure 1. Architectural Overview

The above diagram illustrates one common implementation that combines
the use of a policy repository, a PDP, and a PEP. This diagram is not
meant to imply that these entities must be located in physically
separate devices, nor is it meant to imply that the only protocols
used for communicating policy are those illustrated. Rather, it is
simply meant to show one possible implementation for the purpose of
defining the three important entities fundamental to policy: a
repository, a PDP, and a PEP. Please refer to [SLA] for a description
of how these entities are used and interact with each other.

It is assumed that policy decisions will always be made in the PDP and
implemented in the PEP. Specifically, the PEP is not able to make
decisions on its own. This simplifies the definition and modeling of
policy while leaving open the possibility for a single device to have
both a Local PDP (LPDP) as well as a PEP.




Strassner and Ellesson      Expires 5 March 1999               [Page 8]


INTERNET DRAFT   draft-strassner-policy-terms-00.txt    5 August 1998

The Repository Access Protocol and the Policy Protocol are in general
different protocols. If the Policy Repository is a directory, then LDAP
is one example of a Repository Access Protocol. However, the Policy
Protocol could be any combination of COPS, SNMP, and Telnet/CLI. Given
this rich diversity, a common language is needed to represent policy
rules. The rest of this document defines the necessary terminology to
enable the definition of such a language as well as the definition of
how policy is defined, manipulated, and used in the PDP and the PEP.

4.2  How Policy Decisions Are Made

Any PEP that encounters an event requiring a policy-based decision
first asks a PDP how to handle this request. This results in one or
more policy decisions made by the PDP that are in turn communicated to
the PEP. A policy decision results in a specific set of operations that
either provide a service that was contracted for, or implement a change
in state (e.g., in the network) to provide a service. For example, if
the network is designed to support differentiated classes of service
for handling different types of traffic, network elements could send
requests to a policy server asking how to map a given type of traffic.
Policy decisions would then be made instructing what type of queueing
mechanisms to use to handle that traffic (as an example).

4.3  What Is A Policy (In General Terms)

A policy is formally defined as an aggregation of policy rules. Each
policy rule is comprised of a set of conditions and a corresponding set
of actions. The conditions define when the policy rule is applicable.
Once a policy rule is so activated, one or more actions contained by
that policy rule may then be executed. These actions are associated
with either meeting or not meeting the set of conditions specified in
the policy rule.

Policies can contain policies. This notion of hierarchy is crucial, as
it enables complex policies to be built from a set of simpler policies,
and simplifies their management. It also enables reuse of policy
building blocks (policy rules, conditions and actions).

This definition of policy can be enhanced in several different ways.
However, it is the feelings of the authors that as simple as possible
(but no simpler) a definition must first be used and put into practice
before more complicated definitions of policy are deployed. Otherwise,
it will be much harder to achieve interoperability of policy servers.

Policy is a relationship among the attributes of the objects maintained
by a policy application that control and manages one or more aspects of
a set of PEPs. These PEPs are used to provide a set of services that
are regulated by one or more policies. Key to this definition is the
ability to separate the specification of the set of services to be
provided in a vendor-independent manner from the implementation of
vendor-specific mechanisms that are applied to vendor-specific network
elements to supply those services.

Strassner and Ellesson      Expires 5 March 1999               [Page 9]


INTERNET DRAFT   draft-strassner-policy-terms-00.txt    5 August 1998

4.4 Real-World Requirements of Policy

A critical part of the underlying mental model is that it must be easy
to detect conflicts between different policies and resolve them. The
simplest view of a policy is that it specifies a set of actions
that MUST be performed if a set of associated conditions is met.
Therefore, the ability to detect and resolve conflicts between policy
definitions (conditions as well as actions that are taken when a
set of conditions are met) is crucial. One way of doing this is by
imposing a priority and/or order on both the satisfaction of policy
conditions as well as the execution of policy actions. However, it
should be noted that priority and order are fundamental concepts of
distributed systems and MUST be supported irrespective of being used
to supply a means for policy conflict resolution.

4.5 Policy Components

Policy is comprised of the following three functions:

  1. Decision-making. This compares the current state of the network to
     a desired state described by an application-specific policy and
     decides how to achieve the desired state.
  2. Enforcement. This implements a desired policy state through a set
     of management commands; when applied to network elements, these
     management commands change the configuration of the device using
     one or more mechanisms. These mechanisms MAY be vendor-specific.
  3. Policing. This is an on-going active or passive examination of the
     network and its constituent devices for checking network health,
     whether policies are being satisfied, and whether clients are
     taking unfair advantage of network services.

Decision-making uses static and/or dynamic data to determine if a type
of policy is being satisfied and, if not, what steps are needed to
satisfy that policy. Enforcement refers to the interpretation and
execution of policies by consumers who are assumed to be trustworthy.
Policing is the auditing of policy compliance to verify that the policy
consumers properly implement policies.

4.6 Policy-Based Applications and Network Policy

Policy is defined in terms of applications or processes that monitor
and manipulate one or more entities in order to achieve a desired goal.
To make the following discussion simpler to understand, this paper
focuses on network policies.

A network policy defines the relationships between clients that desire
services of the network and the network elements that provide those
services. Network Policy applications model two important things:
1) the state of the SLAs that they are enforcing, and/or
2) some part of the state of the (overall) network in order to
     ensure that their clients will obtain the services they require
     of (that portion of) the network.

Strassner and Ellesson      Expires 5 March 1999              [Page 10]


INTERNET DRAFT   draft-strassner-policy-terms-00.txt    5 August 1998

Such applications will maintain a number of objects of various types,
each with one or more attributes. Each of these objects either models
the state of one or more network elements or maintains some part of the
internal state of the policy application.

Each of these state machines contains 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).

4.7 Difference Between Policy And Service

A service is the expression of a relationship between a set of objects.
A policy is a statement about a set of relationships between objects
that provide a particular service.

4.8 Need For Canonical Representation Of Policy

Policies represent business functions and goals. These correspond to
network services, which are provided by vendor-specific network
elements. The problem is that vendors will describe the same business
function in different ways. This is because business functions are
described at a necessarily high level, and are therefore subject to
different interpretation. Since the network will implement the services
that correspond to these business functions, differences in network
elements will exacerbate this mapping.

The solution is to use a canonical 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. However, this
is not enough, because the definitions of policy conditions and
actions could still be different, and if they were, interoperability
of policy servers will not be achievable. Therefore, a canonical
representation of policy conditions and policy actions MUST also
be enforced. 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).
Given a class-based implementation of policy, the above could be
implemented easily through defining subclasses that corresponded to
the different policies, policy rules, policy conditions, and policy
actions that were under control of the PDP.




Strassner and Ellesson      Expires 5 March 1999              [Page 11]


INTERNET DRAFT   draft-strassner-policy-terms-00.txt    5 August 1998

5. Policy Terminology

The following is a set of policy terminology definitions.

5.1 Policy

A policy is a named object that represents an aggregation of Policy
Rules. The policy describes the overall business function(s) to be
accomplished, while the set of policy rules define how those business
functions will be met. The business function(s) correspond to one or
more SLOs of an SLA.

5.2 Policy Rule

A policy rule is comprised of a set of conditions and a corresponding
set of actions. This combination in effect defines a sequence of
actions to be initiated when the corresponding set of conditions is
either satisfied or not satisfied. For simplicity, it is recommended
that positive (satisfaction) and negative (unable to meet) conditions
be realized as separate rules that are folded into a single policy.
Each policy rule is a declarative statement consisting of a Boolean
expression that describes a situation to which the policy applies.
When the expression is true, one set of actions is initiated, and
when false, a different set of actions is 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, ELSE take this other set of actions).

5.3 Policy Condition

Policy Conditions consist of two parts, a policy condition type and a
policy condition element. This structure is aimed at satisfying the
need for a canonical representation of a policy condition.

A policy condition type is a set of predefined conditions that can be
attached to a policy rule for evaluation. This canonical set of
conditions represent common conditions that all network vendors can
implement. By including this canonical representation of policy
conditions, the resulting set of policy conditions can be exchanged
between multiple vendors' policy servers. This is necessary for
interoperability as well as for a policy server to be able to parse
rules to determine if any rules conflict may potentially conflict
with each other. A policy condition element is a policy condition type
instance that is being tested. Policy condition elements are related
together to form a Boolean expression. The relations can be one of the
following operators:  in, not in, equal, not equal, less than, less
than or equal, greater than, and greater than or equal.






Strassner and Ellesson      Expires 5 March 1999              [Page 12]


INTERNET DRAFT   draft-strassner-policy-terms-00.txt    5 August 1998

5.4 Policy Action

A policy action is the changing of the configuration of one or more
network elements in order to achieve a desired policy state. This (new)
policy state provides one or more (new) behaviors. As with policy
conditions, a policy action is comprised of two parts, a policy action
type and a policy action element. The policy action type defines a
canonical set of operations or treatments that can be given to traffic
flowing into the network element (e.g., deny, change code point, etc.)
that is vendor-independent. Similarly, the policy action element
specifies the type of mechanism to be used to provide the specified
operation or treatment.

5.5 Policy Decision

A policy decision is 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 were
satisfied. Note that the action of a policy decision MAY be to simply
invoke another policy rule for further processing of the request.

5.6 Policy Behavior

A policy behavior controls how traffic is treated, what network
resources must be utilized, and/or what network services are provided.
Policy behaviors define one or more mechanisms that are used to
implement the policy. Therefore, different devices can carry out the
same policy using different behaviors. For example, one router might
use a dropping behavior and another might use a queueing behavior
during times of congestion in order to satisfy an overall delivery
goal. Policy behaviors can include one or more of the following:

  - permit or deny forwarding of traffic based on:
    - source and destination address
    - source and destination port number
    - protocol type and options
    - other factors specific to vendor implementations
  - permit or deny access to a requested resource or service
  - encrypt the header and/or the payload
  - start or stop accounting and/or auditing
  - start or stop logging

5.7  Policy State

A policy state is a description of the settings of one or more network
elements. These settings correspond to providing the set of services to
be provided by the network. For example, a Service Level Agreement can
describe services contracted for by subscribers - this corresponds to a
state that various network elements must be put into in order to
provide those services.

Strassner and Ellesson      Expires 5 March 1999              [Page 13]


INTERNET DRAFT   draft-strassner-policy-terms-00.txt    5 August 1998

5.8 Policy Conflict

A policy conflict occurs when the conditions of two or more policies
can be simultaneously satisfied, but the actions of at least one of
the policies can not be simultaneously executed. This implies
several things:

  - one or more policy rules of each of the policies is satisfied by
    the same request
  - each condition of each of the conflicting policy rules is satisfied
    by the same request
  - one or more actions specified by one policy conflict with one or
    more actions specified by the other policy

Policy conflicts can be resolved in a number of different ways. The
simplest is to change the conditions and/or actions of one of the
policies so that it no longer conflicts with the other policies.
However, if the policies must remain inherently conflicting, then there
are a number of ways to resolve the conflict on an individual event
basis, including the following:

  - apply a "match-first" criteria, wherein conflicts are resolved by
    matching the first policy that is found
  - apply a priority order criteria, wherein conflicts are resolved by
    finding all policy rules which match a given event and selecting
    only the rule with the highest priority
  - use additional metadata to determine which rule or rules should be
    applied. The difference between this and straight priority is that
    priority is inherently linear, whereas metadata is not (e.g.,
    branching can be used).

5.9  Service Level Agreement (SLA)

An SLA is 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.).

5.10  Service Level Objective (SLO)

An 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).

Strassner and Ellesson      Expires 5 March 1999              [Page 14]


INTERNET DRAFT   draft-strassner-policy-terms-00.txt    5 August 1998

5.11 Policy Event

A policy event is a notification that triggers one or more policy
evaluations. A particular event may or may not initiate a policy
decision and/or a policy enforcement action.

5.12 Policy Evaluation

Policy evaluation is the determination of whether or not the network
(or a part of it) is in a desired policy state. This is usually
determined by processing static and/or dynamic data against one or more
policy rules, the key point being that the decision is made by
comparing definitional data stored in the policy repository with
current data from the network that does not have to be stored in the
policy repository. If it is found that the network elements are not in
the desired policy state, then one or more policy actions will be taken
to move the network elements from their current state to the desired
state. This is called policy enforcement.

5.13 Policy Enforcement

Policy enforcement is 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.

5.14 Policy Policing

Policy policing is an on-going active or passive examination of the
network and its constituent devices for checking network health,
whether policies are being satisfied, and whether clients are taking
unfair advantage of network services. This is done for one or more
of the following reasons:

  - to monitor network statistics as part of checking network health
  - to monitor network statistics as part of checking whether policies
    that are currently in use are being satisfied
  - to ensure that clients of a given set of policies are not abusing
    their privileges

5.15 Policy Agent

A policy agent is a software module that generates and responds to
policy events, evaluates policies, and enforces policies.

5.16 Policy-Driven Service

A policy-driven service is a set of cooperating policy agents that
Define, monitor and enforce a particular policy.


Strassner and Ellesson      Expires 5 March 1999              [Page 15]


INTERNET DRAFT   draft-strassner-policy-terms-00.txt    5 August 1998

5.17 Policy Audit

A policy audit matches conditions examines one or more active policies
to determine if their actions are being executed correctly and the
desired result (e.g., flow of traffic) is being carried out. This
is equivalent to checking the state of the network to determine the set
of policies that are and are not being satisfied.

5.18 Policy Consistency Checking

Policy consistency checking is an analysis of currently active policies
to determine their consistency or possible inconsistency with each
other.  When an inconsistency is discovered, a policy discrepancy is
reported.

5.19 Policy Discrepancy

A policy discrepancy is a notification that two or more policies are in
actual or potential conflict in the sense that implementation of one
policy may prevent or otherwise adversely effect the implementation of
the other policies.

5.20 Policy Mechanism

A policy mechanism is a set of vendor-specific commands that configures
a network element to put a policy rule into effect.

5.21 Policy Verification

Policy Verification is an analysis of a policy to determine if the
desired state can be established and maintained for the duration of
the corresponding policy rule being active.

5.22 Policy Restoration

Policy Restoration is one or more actions taken to restore the system
to a desired policy state. This could be invoked because of a policy
action in response to an event, or because the current state got
corrupted.

6. Policy Example

This section will provide an example of the canonical use of
policies, policy rules, policy conditions and policy actions.

Assume that the following business rule is to be implemented as
a policy:

        Provide the JitterFreeMPEG2 video service for authorized users
     between authorized points, but only at agreed-upon times



Strassner and Ellesson      Expires 5 March 1999              [Page 16]


INTERNET DRAFT   draft-strassner-policy-terms-00.txt    5 August 1998

This rule can be loosely translated as:

        IF user IN ApprovedUsers AND service IN VideoServices AND
        source IN VideoSources AND destination IN VideoDestinations AND
        time IN ApprovedTimePeriods
        THEN provide JitterFreeMPEG2

The policy condition is loosely translated as:
        IF  the user is a member of an approved group (ApprovedUsers) that
            are authorized to have this service)
        AND the service requested is one supported (VideoServicesgroup)
        AND the source of the request is approved (in the VideoSources
            group or has been authenticated)
        AND the destination is approved (in the VideoDestinations group
            or has been authenticated)
        AND the time requested is OK (in ApprovedTimePeriods)

Here, the policy condition types are:
    user, service, source, destination, and time
and the policy condition elements are:
    ApprovedUsers, VideoServices, VideoSources, VideoDestinations,
    and ApprovedTimePeriods, which are all instances of pre-defined
    groups of objects.

The policy action is:
    IF the conditions are satisfied
       THEN provide the user with video having a QoS defined by the
            JitterFreeMPEG2 service

Note that this policy could require "sub-policies" in order for it to
be implemented. For example, RSVP requests might be used to
precondition the path between VideoSources and VideoDestinations.





















Strassner and Ellesson      Expires 5 March 1999              [Page 17]


INTERNET DRAFT   draft-strassner-policy-terms-00.txt    5 August 1998

7. Terminology For Implementing Policy GUIs

Part of the task of defining policy terminology is to enable policies
to be represented in a user-friendly GUI. This section provides
guidelines for doing this through the introduction of additional
terminology designed expressly for this purpose.

7.1 Types Of Policies

An effective policy GUI MUST be able to categorize and sort policies in
ways that are meaningful to the user. Three are three broad means of
doing this, based on differentiating between how a policy is used,
how a policy is triggered, and the attributes of the policy.

7.2 How A Policy Is Used - Service And Usage Policies

Service and Usage Policies are a means of categorizing policies by what
they do and how they are used. Service policies describe services
available in the network. Usage policies describe which policies will
use which services when 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.

For example, the fact that a user can get a particular conditioning
treatment, or can use IPSEC to encrypt the payloads of traffic, are
both services that are provided and are represented as service
policies. On the other hand, differentiating between two flows and
assigning different services to the flows is an example of using usage
policies to differentiate the handling of the flows.

7.3 How A Policy Is Triggered - Static vs. Dynamic Policies

There are two fundamentally different ways that policies can be
applied - statically in response to a set of pre-defined conditions and
dynamically in response to one or more events. Both static and dynamic
policies use statically defined rules to determine how the policy
effects the objects that it is applied on. Furthermore, both types of
policies are applied in response to an event. The difference lies in
how they are applied.

7.3.1  Static Policies

Static policies apply a fixed set of actions in a pre-determined way
according to a set of pre-defined parameters that determine how the
policy is used. These parameters restrict the application of the policy
in some way. Examples include restricting the application of the policy
to only certain times of the day, week, month, or year. For instance,
the accounting department gets 75% of the bandwidth at the close of the
quarter, or anyone can use streaming video after 7:00PM. The above
examples each illustrate a means of restricting the application of the
policy based on some external data or set of conditions.

Strassner and Ellesson      Expires 5 March 1999              [Page 18]


INTERNET DRAFT   draft-strassner-policy-terms-00.txt    5 August 1998

7.3.2 Dynamic Policies

This type of policy gets enforced when needed (i.e., when the network
gets congested, or when a user with Gold Service logs on). Although the
conditions of the enforcement are pre-defined, there is no set time or
parameter that triggers the policy. Rather, the policy is triggered
when a condition occurs. For example, Gold Service has one set of
actions when the network is not congested and an additional set of
actions when the network is congested. The mechanism that implements
the gold service doesn't change; however, additional sets of actions
(that ensure the delivery of Gold Service) are invoked when the network
is congested. Since the network can be congested in different ways,
different sets of actions are invoked.

This is fundamentally different than the static policies defined above
in that static policies always invoke the same set of actions the same
way in response to an event. Dynamic policies may invoke different
actions based on the semantics of the event.

7.4 Classifying Policies Based On Attributes

Policies can be classified by the attributes that they possess. This
includes what the policy applies to (e.g., a class of user or a certain
type of application) as well as certain attributes that fundamentally
change the applicability (conditions) and effect (actions) of the
policy. Examples of these include physical location. For example, if a
user is connected to his or her corporate Intranet through the public
internet, then a different security policy might be applied to that
communication and different restrictions may be placed on accessing
resources than when that user connects through the corporate network.

7.5 Policy Triggers

Some policies only come into force if certain usage conditions are met.
For example, if the current network bandwidth utilization is low, users
may be allowed to use certain applications (e.g., streaming video or
interactive games) that they otherwise are not allowed to use.
Furthermore, this privilege may be revoked if the traffic reaches a
certain level.

8. Security Considerations

Security and denial of service considerations are not explicitly
Considered in this memo, as they are appropriate for the udnerlying
Policy architecture. However, the policy architecture must be secure
as far as the following aspects are concerned. First, the mechanisms
proposed under the framework must minimize theft and denial of service
threats. Second, it must be ensured that the entities (such as PEPs and
PDPs) involved in policy control can verify each other's identity and
establish necessary trust before communicating.



Strassner and Ellesson      Expires 5 March 1999              [Page 19]


INTERNET DRAFT   draft-strassner-policy-terms-00.txt    5 August 1998

9. Acknowledegments

Many thanks to the useful discussions and suggestions from the Internet
Community at large but especially to Andrea Westerinen, John Lee,
Lee Rafalow, Steve Schleimer and Fred Baker.

10. References

 [TERMS]    S. Bradner, "Key words for use in RFCs to Indicate
            Requirement Levels", Internet RFC 2119, March 1997.
 [DIFFARCH] D. Black, S. Blake, M. Carlson, E. Davies, Z. Whang,
            W. Weiss, "An Architecture for Differentiated Services",
            Internet draft <draft-ietf-diffserv-arch-00.txt>,
            May 1998
 [DIFFSERV] K. Nichols and S. Blake, "Definition of the
            Differentiated Services Field (DS Byte) in the
            IPv4 and IPv6 Headers", Internet draft
            <draft-ietf-diffserv-00.txt>, May 1998
 [DSFIELD]  K. Nichols and S. Blake, "Definition of the Differentiated
            Services Field (DS Byte) in the IPv4 and IPv6 Headers",
            Internet Draft <draft-ietf-diffserv-header-00.txt>,
            May 1998.
 [LDAP]     This refers to the current collection of LDAP RFCs
            (2251 - 2256) but especially to RFC 2251 (the protocol).
 [RAPFRAME] R. Yavatkar, D. Pendarakis, R. Guerin, "A Framework for
            Policy-based Admission Control", Internet Draft,
            < draft-ietf-rap-framework-01.txt>, May 1998
 [SLA]      R. Rajan, J-C Martin, editors, "Schema for Service Level
            Administration of Differentiated Services and
            Integrated Services in Networks", Internet Draft
            <draft-ellesson-sla-schema-02.txt>, June 1998

Authors' Addresses

John Strassner
    Bldg 1
    Cisco Systems
    170 West Tasman Drive
    San Jose, CA 95134
    Phone:  +1-408-527-1069
    Fax:    +1-408-527-1722
    E-mail:  johns@cisco.com

Ed Ellesson
   JDGA/501
   IBM Corporation
   4205 S. Miami Blvd.
   Research Triangle Park, NC 27709
   Phone: +1-919-254-4115
   Fax:   +1-919-254-6243
   E-mail: ellesson@raleigh.ibm.com


Strassner and Ellesson      Expires 5 March 1999              [Page 20]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/