One document matched: draft-strassner-policy-terms-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-22 14:37:01 |