One document matched: draft-ietf-policy-req-01.txt
Differences from draft-ietf-policy-req-00.txt
Internet Draft Hugh Mahon
Expiration: April 2000 Hewlett-Packard
File: draft-ietf-policy-req-01.txt Yoram Bernet
Microsoft
Shai Herzog
IP Highway
October, 22 1999
Requirements for a Policy Management System
Status of this Memo
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026. Internet-Drafts
are working documents of the Internet Engineering Task Force
(IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or made obsolete by other
documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as ``work
in progress.''
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved.
Abstract
This document describes why policy based management is interest-
ing to people managing IT environments and what is needed to make
policy management address those interests. Work to date is
described, as well as usage cases demonstrating how policy-based
Internet Draft Policy Requirements October 1999
management would actually work.
The goal for this document is to provide a set of requirements
for further development of standards for policy management sys-
tems. There has already been work in the area of policy manage-
ment and the work to date is described as well as additional
areas to be defined.
For readers in a hurry the Introduction (section 1) and Usage
Cases (section 5) will provide a great deal of information.
Readers interested in more detail about various aspects of Policy
Management should read from the beginning of the document to the
end.
This document is the result of discussions, e-mail, and other
communications within the Policy Framework Working Group and
among individuals.
Table of Contents
1. Introduction ......................................... 3
2. A Simple Policy Management System .................... 6
2.1 The Policy Consumer and Policy Target ............... 7
3. Policy Management in Action .......................... 9
3.1 Information Visible to the Administrator ............ 10
3.2 Policy Deployment Actions ........................... 11
3.2.1 Policy Configuration Usage ........................ 11
3.2.2 Results of Policy Configuration ................... 13
3.3 Alternate Architectures ............................. 13
3.3.1 Policy Status and Configuration Information ....... 13
3.3.2 Policy Notification ............................... 15
4. General Policy Management Issues ..................... 17
4.1 Provisioned vs. Signaled QoS Mechanisms ............. 17
4.2 Policy assignment ................................... 19
4.2.1 Policy applicability .............................. 21
4.3 Policy Operation .................................... 21
4.3.1 Policy Size ....................................... 22
4.3.2 Policy Capability ................................. 23
4.4 Policy Conflicts .................................... 24
4.4.1 Conflict (Inconsistency) Between Policies ......... 24
4.4.2 Rule Conflict Within a Policy ..................... 26
4.5 Time aspects of policy .............................. 26
4.6 Scalability ......................................... 27
4.6.1 Scalability and Policy Targets .................... 28
4.6.2 Scalability and Policy Consumers .................. 28
4.6.3 Scalability and the Repositories .................. 28
4.6.4 Scalability and the Policy Management Applica-
tion ............................................... 29
4.7 Administration of the Policy Management System ...... 30
4.7.1 Policy UI ......................................... 31
4.7.2 Policy Conflict Detection ......................... 31
4.7.3 Policy Repository ................................. 32
4.7.4 Policy Management Repository ...................... 32
Mahon,Bernet,Herzog Expires March 2000 [Page 2]
Internet Draft Policy Requirements October 1999
4.7.5 Policy Consumers .................................. 32
4.7.6 Policy Targets .................................... 32
4.8 Policy Conditions ................................... 33
4.8.1 Time/Date Conditions .............................. 33
4.8.2 Packet Conditions ................................. 33
4.9 Implementation examples ............................. 34
4.9.1 LDAP .............................................. 34
4.9.2 SNMP .............................................. 37
4.9.3 COPS .............................................. 39
4.9.4 HTTP .............................................. 41
4.10 Policy Interpretation .............................. 42
4.11 Policy information ................................. 42
5. Usage Cases .......................................... 42
5.1 An Accounting Department Example .................... 43
5.1.1 Policy Consumer For an Existing (Legacy) Device
.................................................... 48
5.1.2 Policy Consumer for a Policy Aware Device ......... 51
5.1.3 Other Policy Consumer Uses ........................ 52
5.2 New Traffic in the Net .............................. 52
5.3 Traffic Classification With Packet Conditions ....... 53
5.4 Other Uses of Policy ................................ 57
5.5 Network Failure ..................................... 58
5.6 The Role of Signaling in Policy Management .......... 61
5.6.1 Classification Assumptions Implicit in Top-Down
Provisioning ....................................... 61
5.6.2 Snooping Signaling Messages to Glean Classifica-
tion Information ................................... 62
5.6.3 Offering High Quality Guarantees .................. 63
5.6.4 Signaled QoS Usage Case I - IP Telephony .......... 64
5.6.5 Signaled QoS Usage Case II - SAP .................. 68
6. Security Considerations .............................. 70
7. Summary .............................................. 71
8. Intellectual Property ................................ 72
9. References ........................................... 73
10 Acknowledgements ..................................... 74
11. Author Information .................................. 74
12. Full Copyright Statement ............................ 74
1. Introduction
Policy based management has generated a lot of buzz in the
industry lately. Unfortunately hype can create unrealistic
expectations. While Policy Based Management won't solve all
problems, or make IT administration a trivial task, there is a
real need for Policy Based Management. So why are people
interested in Policy Based Management?
Mahon,Bernet,Herzog Expires March 2000 [Page 3]
Internet Draft Policy Requirements October 1999
Internet technology based networks are being used for more
functions and by more businesses. Their ability to do busi-
ness is affected by the health and abilities of their net-
works.
As networks grow the amount of things that need to be managed
grows. Not only are there more devices to be managed, but
also the number of kinds of things (e.g., capabilities, ser-
vices, types of interfaces, etc.) is growing. As more kinds
of things are introduced, so are more management interfaces
the IT administrators must learn and use to manage the envi-
ronment. In addition, many of those management tools work
with individual devices, so that an administrator must dupli-
cate the actions used to manage (configure) one device for
each other device, even if they are the same type of device
from the same vendor. The problem is exacerbated if the
devices are from different vendors, since they must perform
different tasks to manage similar capabilities. The same
problem exists not just for networking, but for just about
anything an IT administrator may need to manage.
In response to this situation, customers (IT administrators)
have for many years been asking vendors for tools which better
address their needs in managing such large and dynamic envi-
ronments. Their list of desired features includes:
- centralized management
- abstracted (or simplified) management data
- commonality across devices
- automation of management tasks
- fewer interfaces
- consistency across interfaces
Centralized management requires the ability to perform manage-
ment tasks via the network. Scalability factors into the
requirements since a centralized system is not practical if it
doesn't scale well to fit the management needs in the environ-
ment.
Abstracted (or simplified) management data fits with the fewer
interfaces objective by abstracting the functions and decision
criteria across multiple devices, lending itself to the next
desired feature, commonality across devices.
There are two aspects to commonality: the ability to learn how
to do something once and apply that across multiple things of
the same kind, and the ability to use the same data, not just
similar data, across multiple things. By using the same con-
figuration across multiple devices, the administrator can
achieve consistent behavior in the managed environment and
Mahon,Bernet,Herzog Expires March 2000 [Page 4]
Internet Draft Policy Requirements October 1999
reduce, or better yet eliminate, duplication of efforts. It
is this desire to use the same data across multiple devices
that is behind the desire to have fewer interfaces.
Automation of management tasks is the feature that causes a
change from most implementations of management tools with
existing technologies (e.g., SNMP). One aspect of automation
is the desire of customers to be able to re-use management
data where that re-use makes sense, and for the tools to sup-
port such re-use. In other words, wherever possible, the
tools support management information re-use, and do not
require the administrator to duplicate information already in
the management system, and can automatically get the informa-
tion where it needs to go and when it is needed rather than
require additional intervention by the human administrator.
Automation is also key in allowing the network to operate with
a minimum of human intervention (once the human administrators
have specified, through management data, how the environment
is to behave under given circumstances).
The key to providing a solution for these requirements is the
data used to manage the environment; what that data repre-
sents, how it gets from the administrator to what the data
affects, and the functionality that supports reuse and automa-
tion.
That data has been called 'policy'. Policy Based Management
is the term used to describe the technologies that address the
customer requirements described above.
In support of the above features, the efforts for defining
Policy Based Management have focused on the data representa-
tion and properties of a repository for that information.
The use of a repository is important to support reusability of
data across managed things, as well as allowing an administra-
tor to edit existing management data (both are forms of
reuse). In addition to being stored in a repository, the data
must get to where it will be used (this supports the require-
ments of centralized management and automation). (Information
distributed from a centralized repository also aids in consis-
tency of information throughout the managed environment.)
With common policy information the administrator can use the
same information to configure devices which are supposed to do
the same thing (addressing centralized management, commonality
across devices, and reducing the number of interfaces required
for multiple devices from different vendors). This policy
information can also be abstracted to a higher level, since it
will need to be device independent.
Common information does not require a common format (i.e.,
schema). In other words, it is possible to have common
Mahon,Bernet,Herzog Expires March 2000 [Page 5]
Internet Draft Policy Requirements October 1999
information for QoS management, and common information for
security uses, but have completely different formats for the
different uses of data. This would cause a duplication of
information that could be common (e.g., user information use
for access control), and so would be a bad thing because it
would lead to greater differences between disciplines than
necessary. Therefore, a common format is another requirement
to support the desire for automation and fewer interfaces.
To summarize the above: centralized management leads to the
need for a repository; scalability requires a means to commu-
nicate the data beyond the repository; abstraction requires a
common information model; automation requires the abstraction
and components to perform actions based on management data and
real-time inputs.
The rest of this document describes what is necessary to make
a policy-based management system work, and how such a system
would work in a real environment.
2. A Simple Policy Management System
To start the discussion of how things would operate in a Pol-
icy Management system a simple system must be described. Fig-
ure 1 provides a schematic view of a very basic Policy Manage-
ment System.
Mahon,Bernet,Herzog Expires March 2000 [Page 6]
Internet Draft Policy Requirements October 1999
+-------+
|Policy |
|UI |
| |
+-------+
^
|
V
+------------------------+
|Policy Repository |
| |
| |
+------------------------+
^ ^
/ |
/ |
V V
+---------+ +---------------+
|Policy | Policy | Policy |
|Decision | Consumers | Consumer 1 |
|Point | | |
+---------+ +---------------+
^ ^ ^ ^ ^
COPS RSVP| | | |COPS, \
Client type | | +------------+ | |SNMP, TelnetCLI, etc.
V +>| +--------+<-----------+ V V
+------------+ | |Policy | | +-----------+ +-----------+
|RSVP enabled| | |Target C| | Policy | Policy | | Policy |
|device | | +--------+ | Targets | Target A | | Target B |
| | |RSVP enabled| | | | |
+------------+ |device | +-----------+ +-----------+
+------------+
Figure 1. A schematic of a Policy Based Network Management System.
In this illustration, the designation of one policy target as
using COPS/RSVP (signaled policy model) and another as using
SNMP (provisioned policy model), is not intended to imply that
the two are mutually exclusive. In fact, it is likely that
many devices will support both models simultaneously.
The Policy UI is a place where the administrator can author or
edit policies and the components of policies.
The Policy Repository is a place where the policy information
is stored for use by the rest of the policy architecture.
Later figures present elaborations on the functions required
for a more complete Policy Management System.
Mahon,Bernet,Herzog Expires March 2000 [Page 7]
Internet Draft Policy Requirements October 1999
2.1. The Policy Consumer and Policy Target
There are two essential functions when viewing the managed
environment:
1. dealing with the management information
2. implementing the functionality/behavior specified by
the management information
The Policy Consumer is a logical component which can parse
Policy information. The Policy Target is a logical compo-
nent which implements the functionality or behavior speci-
fied by the Policy.
The Policy Consumer and Policy Target may be logically or
physically the same, or may be separate. The choice is
left to the implementor because different implementations
have valid reasons for implementing either way.
There is at least one other logical component, and that is
the piece which takes information and compares it with the
Policy (or information derived from it) to make a decision.
This component may reside with either the Policy Consumer
or the Policy Target. Again, there are valid reasons for
either. The discussion of Policy Management Systems in
this document will not make any assumptions about this
implementation dependent component.
To provide further examples, the Policy Consumer receives
policy intended for a Policy Target and processes the pol-
icy to allow the Policy Target to enforce the policy. The
Policy Consumer may use the policy interactively, that is,
directly use the policy information to make a decision each
time an event occurs which requires an enforcement decision
(such as the arrival of an RSVP reservation message). In
this real-time policy usage scenario the Policy Consumer is
acting in the role of the PDP (Policy Decision Point) as
described in the COPS architecture (see [COPSFRAME]).
The Policy Consumer could instead process the policy infor-
mation and convert it into configuration information for
the Policy Target to use without further operation of the
Policy Consumer. (Note that the Policy Consumer may inter-
act with the Policy Target even if Policy does not change.
This may be because of time or other reasons discussed
later in this document.)
If the Policy Consumer is resident on the device with the
Policy Target, then the details of the Policy Consumer and
Policy Target interaction are implementation dependent (if
indeed the logical distinction between Consumer and Target
exist, which is not a requirement of an implementation).
Mahon,Bernet,Herzog Expires March 2000 [Page 8]
Internet Draft Policy Requirements October 1999
If the Policy consumer is not resident on the device, pro-
cessing by the Policy Consumer may take one of a spectrum
of forms:
1. The Policy Consumer may be an outsourcing PDP, in
which case it responds to queries from the Policy Tar-
get (which is acting as a Policy Enforcement Point).
Such a scenario, in which the PEP issues requests to
the PDP about RSVP reservations, is what COPS was
originally developed for. See [COPSFRAME] for more
information about the functions of an of an outsourc-
ing PDP.
2. The Policy Consumer may receive policy information and
convert this into configuration information for a man-
aged element (e.g., a router) and then configure the
device to act in accordance with the policy informa-
tion. It should be noted that where policy is con-
verted (or the decision is made) is an implementation
decision, and there is no single best answer for all
desired optimizations.
3. Anywhere between 1 and 2, in which some processing or
decision making occurs in the Policy Consumer, and the
Policy Target takes configuration information or
caches decisions.
It is important to note that the Policy interface is at the
Policy Consumer, whether it resides on the managed element
or elsewhere. The interface between the Policy Consumer
and Policy Target (if it exists in a particular implementa-
tion) is beyond the scope of this document and the Policy
Framework WG.
A Policy Consumer may work with multiple Policy Targets. A
single device may use multiple Policy Consumers, and may
even have co-located Policy Consumers for some policy types
and remote Policy Consumers for other policy types. It is
not required that a single Policy Consumer encompass the
functionality to support all of the policy features of a
single device.
A Policy Target is a specific functional aspect of a device
or logical component. For example, a router has multiple
interfaces, and each interface has multiple capabilities,
such as priority queueing, Committed Access Rate, etc.
Each of these capabilities on an interface becomes a 'tar-
get' for Policy. By focusing on the most basic features
that can be configured, Policy enables the administrator to
deal with abstractions of the device. By allowing this
abstraction Policies can be applied across multiple kinds
Mahon,Bernet,Herzog Expires March 2000 [Page 9]
Internet Draft Policy Requirements October 1999
of devices which provide similar functionality at that
abstract level. So if a router has 4 interfaces, and each
interface has 4 manageable features, the router has 16 Pol-
icy Targets.
The scoping of the Policy Target is the same as the func-
tionality being managed. In other words, if a managed
function (or capability) is specific to a router interface,
the Policy Target is that function, and is considered local
to that interface and function. If a manageable function
is global to a device, the Policy Target related to that
function is global to the device.
Each Policy Target has one Policy Consumer. To have more
than one Policy Consumer responsible for configuring the
Policy Target would invite contention between the Policy
Consumers. There may be one or more Policy Consumers to
enable continued operation in a failure mode, but only one
at a time is to be the 'active' Policy Consumer. A Policy
Consumer, though, can work with multiple Policy Targets at
the same time.
Note that the figure contains an RSVP enabled device which
also contains a Policy Target. It is expected that a sin-
gle device may have multiple policy manageable capabili-
ties. Such a device may use outsourcing (the PDP/PEP rela-
tionship) for one feature, and one or even multiple Policy
Consumers to address other features that can be provi-
sioned.
Although the diagram illustrates the requirement for verti-
cal communication, under certain circumstances horizontal
communication between components will be necessary, and
this will be discussed in later sections. One such hori-
zontal communication is RSVP.
3. Policy Management in Action
The following list describes the expected sequence of actions
in a policy based management system. Each aspect will be dis-
cussed further in this section and following sections of this
document. In addition, later sections will discuss aspects of
policy not necessarily apparent in a simple description of
policy operation.
A. Administrator authors new policy (or edits existing pol-
icy)
B. Administrator associates policy with Policy Targets.
C. Policy and association with Policy Targets is stored in
repository.
Mahon,Bernet,Herzog Expires March 2000 [Page 10]
Internet Draft Policy Requirements October 1999
D. For each of the Policy Targets, a Policy Consumer is
notified that new policy is available for the Policy Tar-
get.
E. The Policy Consumer obtains the policy. See below for a
detailed description of the actions of the Policy Con-
sumer.
F. For each Policy Target which received policy information,
the Policy Consumer provides status information back to
the Administrator about policy deployment; success, or
failure and information about the failure.
3.1. Information Visible to the Administrator
A network Administrator must be able to author policy (see
[TERMINOLOGY] and [INFOMODEL]), and this could be done
using a text file or a special purpose user interface which
can provide assistance in authoring policy. Because it is
expected that policy information will be complex this docu-
ment will expect that a special purpose user interface will
be used. The actual function of such a user interface is
beyond the scope of this document and the work of the Pol-
icy Framework Working Group. There are, however, functions
of the user interface that can be determined and thus the
requirements for that UI can be documented.
An Administrator should not be forced to write policy new
each time a change is desired or policy is to be deployed
to a newly installed device on the network. For this rea-
son a repository is needed. The communication between the
UI and repository must be two-way, that is, the UI can
store policy in the repository, and the UI may extract pol-
icy from the repository for viewing and editing.
Because an Administrator will edit Policy Data, it would be
desirable to have versioning of Policy Data to allow the
Administrator to easily view (or use) earlier versions of
the data.
In addition to policies, there is a need for information
about what is to be managed with the policies. The infor-
mation about the Policy Targets would contain a name recog-
nizable by the administrator, some attributes of the Policy
Target relative to the policy types which can be assigned
to the Policy Target (more details described later), and
status attributes relative to policy deployment (so the
administrator can determine the usage of policy). It
should be noted that this status is not intended to reflect
the effectiveness of the policy, only the status of policy
deployment at each of the Policy Targets.
Mahon,Bernet,Herzog Expires March 2000 [Page 11]
Internet Draft Policy Requirements October 1999
3.2. Policy Deployment Actions
Once policy information is stored in the repository it must
be delivered to where it is to be used.
Here is one aspect of a policy based management system
which may be non-obvious: Each managed element, called a
Policy Target, will have associated with them a Policy Con-
sumer. The Administrator need not be conscious of the
association between Policy Targets and Policy Consumers (if
there is a difference) except during configuration of the
Policy Targets into the policy management system.
In other words, when the Administrator associates policy to
managed elements the mapping between the Policy Consumer
and Policy Target (managed element) can be, and probably
should be, hidden from the Administrator.
How policy is deployed from the repository to the Policy
Consumer is discussed in section 3.3.2.
As described in section 2.1, a Policy Consumer can be used
to configure a managed element based on the policy informa-
tion. The following is a simple example of such an opera-
tion.
3.2.1. Policy Configuration Usage
For this example a simple policy type assigning priority
to traffic will be used. This contains a single
attribute with a value ranging from zero to seven, 7
being highest priority.
Also for this example, the following conditions may be
used to identify traffic:
- Destination IPaddress
- Destination IPport
- Destination IPsubnet
- policyTimePeriodCondition
- Source IPaddress
- Source IPport
- Source IPsubnet
- IP precedence
A Policy Consumer working with an existing router (which
is not policy aware) would translate the policy informa-
tion into the router's configuration commands to enable
the router to act in accordance with the policy.
For example, a policy may be expressed in the form of an
'if-then-else' statement, such as:
Mahon,Bernet,Herzog Expires March 2000 [Page 12]
Internet Draft Policy Requirements October 1999
if (srcIPaddr == 192.168.34.2)
then
Priority=5
else if (destIPaddr == 192.168.72.12)
then
Priority=6
else if (destIPsubnet == 192.168.72.0/255.255.248.0)
then
Priority=7
endif
In the above example is a policy containing three rules,
each rule containing a single condition which is to
cause the traffic matching the expression to receive a
designated priority.
The Policy Target in this case is priority queuing on an
interface on the router. Also, since this router is not
policy aware (it was designed before policy standards
were developed) it is only configurable via a Command
Line Interface (CLI) accessible via Telnet.
The Policy Consumer for the router will translate the
policy into the appropriate configuration commands for
the router/interface combination. Prior to sending the
information to the router, the Policy Consumer will
check for other configuration related to the specific
router interface. If there is already configuration on
the interface which is for the function specified by the
policy, that previous configuration is removed (using
the appropriate CLI commands). Other configuration of
the device, even for the specific interface, which does
not affect the properties of operation relevant to the
policy description is not affected.
The ordering of steps will vary from implementation to
implementation in order to handle the particular
requirements for each device, but the key is that the
Policy Consumer concerns itself only with the configura-
tion of the device relative to behaviors described by
policy. As more policy types are defined this may
encompass all aspects of device configuration, but this
will not be the case for initial policy management tools
and system deployments.
Such configuration (communication between the Policy
Consumer and Policy Target) may be done using technolo-
gies other than Telnet CLI. Other such tools include,
but are not limited to, SNMP, COPS, and HTTP.
Mahon,Bernet,Herzog Expires March 2000 [Page 13]
Internet Draft Policy Requirements October 1999
3.2.2. Results of Policy Configuration
Once the device has been configured according to policy,
the Policy Consumer determines whether the deployment
was successful. In the case of the above example with a
policy unaware device, the Policy Consumer could query
the configuration of the device to determine that what
was sent was instantiated on the target. The Policy
Consumer would then provide for the Administrator feed-
back of the success or failure of the policy deployment
to the Policy Target.
It is not required that the same repository which stores
policy information also store the policy status
attribute information of the Policy Targets, but there
must be an information model that allows for the associ-
ation in order to allow an administrator to understand
the state of a Policy Target relative to the policy
deployed to it. Where this information is stored is dis-
cussed below.
Once feedback from the Policy Consumer is sent to a
repository, it should be presented for the Administrator
to see.
Many networks are managed and monitored using SNMP
today. In environments using SNMP, there are often con-
soles which are used to display the status of network
elements. Notification of events relative to policy
actions may be sent to such an SNMP management system,
but Administrators performing Policy management func-
tions may use a separate UI. The status of deployment
of policy to a Policy Target is therefore desirable as
an attribute of that Policy Target.
3.3. Alternate Architectures
In order to address notification and status reporting,
there need to be more functional elements than appear in
Figure 1. The following sections describe various ways to
address these needs.
3.3.1. Policy Status and Configuration Information
As described above, there is more information required
to manage Policy Targets than Policies. Network Admin-
istrators need feedback about policy deployment. In
addition, information about the capabilities of the Pol-
icy Targets would be useful to the Administrator (or
management application) in order to ensure that the pol-
icy can be implemented on the Policy Target(s) before
actual deployment.
Mahon,Bernet,Herzog Expires March 2000 [Page 14]
Internet Draft Policy Requirements October 1999
+-------+
|Policy |
|UI |
| |
+-------+
^ ^
/ \
/ \
/ \
v v
+-------------+ +------------+
|Management | |Policy rep |
|Repository | |(e.g., LDAP)|
|(e.g., rdb) | | |
+-------------+ +------------+
^ /
status \ /Policy data
and config\ /
info \ v
+---------------+
| Policy |
| Consumer |
| |
+---------------+
^ ^
| \
| \
V V
+-----------+ +-----------+
| Policy | | Policy |
| Target A | | Target B |
| | | |
+-----------+ +-----------+
Figure 2. Adds a repository for status information about
the Policy Targets.
Figure 2 shows the components which enable storage of
such information for display by the Policy User Inter-
face.
In addition to the Policy Repository represented in Fig-
ure 1, Figure 2 adds a Management Repository to store
information about the Policy Targets, their relationship
to Policy Consumers, and status of policy deployment to
the Policy Targets. In addition other attributes of the
Policy Targets may be stored for use of the administra-
tor or other policy application(s). Such information
would include attributes related to Policy Actions
(e.g., for Committed Rate Policy the maximum bandwidth
for a target) and Policy Conditions (what conditions are
supported, and what are valid values for the
Mahon,Bernet,Herzog Expires March 2000 [Page 15]
Internet Draft Policy Requirements October 1999
conditions).
In addition, status information regarding the opera-
tional status ('up' or 'down') of the Policy Targets,
and Policy Consumers should be sent to the Policy Man-
agement Repository in order to provide the Administrator
with the operational status of these components.
An LDAP enabled directory is suited to relatively static
information, that is, an LDAP enabled directory is best
suited to providing access to information that does not
change often (on time scales of hours or days).
Information such as status is volatile, meaning that it
can change frequently (seconds or minutes) (see section
4.5 Time Aspects of Policy). Based on current stan-
dards, then, LDAP enabled directories are not well
suited to storing status information.
The other attribute information about Policy Targets
could be stored in either the Directory or Management
Repository.
3.3.2. Policy Notification
Also described above is the need to have policy deliv-
ered to Policy Consumers in a timely manner.
Mahon,Bernet,Herzog Expires March 2000 [Page 16]
Internet Draft Policy Requirements October 1999
+-------------------+
|Policy Mmgt App. |
| - Policy UI |
| - Conflict detect |
| - Notification |
| - Mgmt repository |
| |
| |
+-------------------+
^ | ^
| | |
| | |
| | |
| | V
| | +------------+
| | |Policy rep |
| | |(e.g., LDAP)|
| | | |
| | +------------+
| |notif. /
status | | /Policy data
and config| | /
info | v v
+---------------+
| Policy |
| Consumer |
| |
+---------------+
^ ^
| \
| \
V V
+-----------+ +-----------+
| Policy | | Policy |
| Target A | | Target B |
| | | |
+-----------+ +-----------+
Figure 3. Provides for status and other information related
to policy, as well as notification to Policy
Consumers of new policy.
Network Administrators currently configure devices in
real time. Even though policy management provides addi-
tional features, Administrators will still want the man-
agement process to occur in human terms (for feedback
this means within a few seconds). In order for policy
to be received by the Policy Consumer and provide feed-
back to the Administrator in such a time frame the Pol-
icy Consumer must either poll the Policy Repository at
short intervals or be notified that there is information
to retrieve from the repository.
Mahon,Bernet,Herzog Expires March 2000 [Page 17]
Internet Draft Policy Requirements October 1999
Polling would place a burden on the Policy Consumer (and
the system it is implemented on), the Policy Repository
(and its host), and the network. Polling is an effec-
tive, if inefficient, way to determine if there is new
policy. To reduce the cost of polling, the polling
interval can be increased, so that queries are performed
less often, but this reduces the ability to receive pol-
icy in a timely manner.
Notification would be more efficient than polling, and
could be done to support timely delivery.
There are discussions of extending LDAP to provide a
notification capability, but this is still undefined, so
LDAP does not appear to be able to provide a more effi-
cient means than polling for policy distribution to Pol-
icy Consumers in the near future (2 to 3 years).
Because it writes the information to the Policy Reposi-
tory, the Policy UI is aware of when policy changes in
the repository. Functionality could be added so that
the Policy UI is more than just a UI and notifies the
Policy Consumer related to the Policy Target for which
there is new Policy. This notification could also
inform the Policy Consumer where to find the Policy
Data, for example, the Distinguished Name of the first
element (or top of DIT containment) of the Policy Data
in an LDAP enabled Directory Server.
4. General Policy Management Issues
Policy Management is a complex topic. This section of the
document will provide a discussion of the major areas of Pol-
icy Management.
4.1. Provisioned vs. Signaled QoS Mechanisms
There are two mechanisms by which resources may be allo-
cated: provisioned (or pre-defined, or pro-active) and sig-
naled (or on-demand, or reactive). Each has their
strengths and weaknesses.
With provisioned mechanisms, traffic treatment (such as
CAR, priority, shaping, etc.) can be specified as well as
the characteristics of the traffic to receive that treat-
ment (i.e., packet header information such as source and
destination IP address, IP port numbers, etc.). An admin-
istrator would observe traffic patterns on the network,
compare that with the desired state (based on business or
operational needs), and then craft policies which allocate
resources accordingly. Such mechanisms may work quite well
for traffic such as HTTP, telnet, or FTP, which are
Mahon,Bernet,Herzog Expires March 2000 [Page 18]
Internet Draft Policy Requirements October 1999
tolerant of variance in flow quality (jitter, packet re-
ordering, etc.), but still can benefit from having greater
throughput provided by the above mentioned QoS mechanisms.
The stength of signaling, simply put, is that it enables
parts of the network to offer high quality guarantees, and
to simultaneously be used efficiently. Without signaling,
it is necessary either to compromise the quality of the
guarantees, or to over-provision parts of the network. In
certain parts of the network, over-provisioning may be a
viable option. However, in other parts it may not. If the
network administrator is to have the flexibility to not
over-provision those parts of the network which would be
prohibitively expensive to over-provision *and* to support
high quality guarantees through them, then end to end sig-
naling must be availble to be used for policy based admis-
sion control decisions.
Signaling mechanisms can provide information beyond the QoS
needs of the traffic for which it is signaling. User
information (not available in packet headers), and applica-
tion identification (which would be hidden by IPSec, or
unavailable if well-known or registered ports aren't used)
can be provided, thus allowing higher quality information
about the traffic than may be available otherwise.
Since network administrators manage in temrs of users and
applications, and network devices classify in terms of IP
addresses and ports, any mechanism which improves the bind-
ing of users/applications to IP addresses and ports (or
laternate classification criteria in the case of IPSec),
improve the manageability of the network.
But the greatest value of the signal is that by traversing
the same path in the network as the traffic for which it is
signaling, it can communicate the specific QoS needs for
the connection. If the needs cannot be met anywhere along
the path, an explicit notification is provided, effectively
a 'busy signal', notifying the application that it will not
get the desired QoS.
The signal, then, acts as a horizontal communication mecha-
nism (relative to figures 1 and 3) assuring resource allo-
cation along the path of a connection, coordinating the QoS
mechanisms to ensure expected treatement for the traffic.
In contrast, provisioned mechanisms will act as individual
points to provide pre-specified levels of QoS, unaware of
what other devices are doing.
Why, then, wouldn't signaling be used for all traffic for
which better than best effort QoS is desired? The signal-
ing does incur a cost in additional network traffic, set up
time, and processing on the devices and end systems
Mahon,Bernet,Herzog Expires March 2000 [Page 19]
Internet Draft Policy Requirements October 1999
involved. Such overhead makes sense for connections that
will last for a minute or more, or where variance in QoS
can produce dramatically undesirable results. VoIP fits
both criteria. Traffic whose connections are short-lived
(e.g., HTTP), or can tolerate variable QoS within limits
(e.g., telnet, FTP), may not warrant such overhead.
A common need for both signaled and provisioned QoS mecha-
nisms, though, is policy. It is with policies that the
administrator would specify how much resource is to be
allocated to any particular use, whether it is to allow a
certain amount of bandwidth to be used for all VoIP traf-
fic, or limit how much bandwidth a single connection can
use (for example to prevent a single user from allocating
the entire VoIP bandwidth to send high quality audio to a
friend).
Related to the provisioned vs. signaled models is the use
of outsourcing vs. pre-configuration. Signaling lends
itself to outsourcing of policy based decisions better than
provisioned because of the granularity provided by the sig-
nal (one or a few signals for a connection that lasts a
long time versus classifying each packet). This, however,
doesn't mean that to use RSVP a device must use an external
PDP. It could use a local PDP (in the device) if it has
sufficient processing capability. Conversely, a device
that uses provisioned QoS mechanisms may outsource a deci-
sion when it recognizes a new flow, and then cache the
packet header information to provide policy specified QoS
for the rest of the flow.
4.2. Policy Assignment
Policies must be associated with a manageable entity, which
in this document are called Policy Targets. For example, a
router has multiple interfaces on it, and each interface is
an ingress point to a network (LAN, WAN, backbone, etc.).
Many such devices have the ability to affect the Quality of
Service of traffic going out through these interfaces (as
opposed to coming in through an interface). It is these
interfaces, which are the control points, which are the
targets of QoS policies.
Mahon,Bernet,Herzog Expires March 2000 [Page 20]
Internet Draft Policy Requirements October 1999
+---+ +----+
| |Client A | |Server 1
| |\ /| |
+---+ \ +---------+ / +----+
\ |Network | /
Dept +----|element |-----+ Corporate WAN
/ Int1| |Int2 \
/ +---------+ \
+---+/ \+----+
| | | |
| |Server 2 | |Client B
+---+ +----+
Figure 4. Policy assignment example.
Figure 4 represents a simple schematic of two networks con-
nected by a network element (e.g., a router). In this
example, the network element does not have the ability to
control traffic entering on an interface, but can control
(via queues, marking, etc.) the traffic going out through
an interface.
One network is a Departmental LAN, and the other is a Cor-
porate WAN. The network element connecting these two net-
works has two interfaces, Int1 and Int2. The traffic going
in to the Dept. LAN will be regulated at Int1, while the
traffic going to the Corporate WAN will be regulated at
Int2.
To control traffic going from the Dept. LAN to the Corp.
WAN, a policy would be deployed to Int2, whether it is
traffic which is returning to Client B from Server 2 or is
traffic from Client A to Server 1. Conversely, traffic
entering the Dept. LAN is controlled by Int1, whether the
traffic is a request to Server 2 or a response to Client A.
The distinction between the interfaces, and the policies
targeted to each is important for many reasons. For exam-
ple, if the manager of the Dept. LAN wanted to set higher
priority for Web usage of users of the Dept. LAN than Web
usage from outside of the Dept. LAN (i.e., to the Web
servers on the Dept. LAN from the rest of the company),
then the policies affecting the traffic must be structured
in one of two ways:
1. The policies deployed to Int1 are different than poli-
cies deployed to Int2 and the conditions can refer to
traffic type only (e.g., source and destination IP
Port numbers).
Mahon,Bernet,Herzog Expires March 2000 [Page 21]
Internet Draft Policy Requirements October 1999
2. The policies deployed to Int1 and Int2 are the same,
and the conditions refer not only to the traffic
types, but to the source or destination addresses or
subnets.
Either approach is valid. The advantage to #1 is that the
policy will be smaller, and should require less memory and
processing on the network element to implement (the number
of 'ifs' that must be processed to implement the policy
would be smaller). Of course, the same policy can be
deployed anywhere else in the network if the same kinds of
behaviors are desired at one or more specific points in the
network. And because specific addresses or subnets are not
used, the policy is easily reused (if only traffic type is
the characteristic).
The disadvantage of #2 is that it would be larger, since it
is specifying the behavior for flowing out both interfaces,
and thus would cause policy which would be used only on
Int2 (in this example) to be installed on Int1, and vice-
versa. The advantage of this approach is that the adminis-
trator may install this same policy anywhere in the network
and it will yield the same behavior, reducing the number of
policies the administrator would need to author and track.
4.2.1. Policy applicability
It is important to point out that while this document
often refers to policy applying to a 'device', policy is
applicable to other logical entities as well. A network
stack within a general computer system (i.e., host com-
puter), an application running on a host computer, a
firewall application running on a host computer, etc.
Thus, in the QoS example of policies, policy may be
applied to any physical or logical entity which gener-
ates, handles, or otherwise impacts the flow of network
traffic.
4.3. Policy Operation
There are many considerations regarding policy when it is
used to configure a device (as opposed to the decision out-
sourcing mode described by the COPS RSVP PDP/PEP interac-
tion).
How large are policies, what are the implications of expan-
sion, and even how well could policy map to a specific
device can enter into the usage of policy when specific
devices (instead of 'typical') are considered. This dis-
cussion is not intended to prescribe a 'least common denom-
inator' model for policy, but to describe how policy may be
Mahon,Bernet,Herzog Expires March 2000 [Page 22]
Internet Draft Policy Requirements October 1999
used with devices with limited capabilities.
4.3.1. Policy Size
Policy to express a certain set of behaviors may take
different sizes. The number of Policy Rules contained
within a given Policy, the number of conditions, etc.,
all depend on the requirements placed on the Administra-
tor.
While the intent of policy is to reduce device specific
considerations visible to the administrator it will be
difficult to eliminate all device considerations. This
is not unlike the fact that a PC user today must be cog-
nizant of whether or not a given application will work
on a PC equipped with a given amount of RAM.
Discussions with Network Administrators have revealed
that many do not wish to use more than a handful (4 or
5) of classes of network traffic. This may result in
only 4 or 5 rules within a policy. Of course, how those
classes are defined may vary. Below are some examples
of how classes of traffic may be identified:
1. destIPsubnet == 192.168.32.0/255.255.248.0 &&
destIPport == 80
2. srcIPport = 25
3. srcIPsubnet == 192.168.32.0/255.255.248.0 &&
dayOfWeek == _MTWRF_
The list of conditions enumerated in section 3.2.1 is a
subset of conditions expected to be defined for policy
management. With this set of conditions an administra-
tor can specify the type of traffic going between two
machines:
if ((srcIPaddr == 192.168.2.4) &&
(destIPaddr == 192.168.72.12) &&
(destIPport == 80))
then
priority=6
else if ((destIPaddr == 192.168.2.4) &&
(srcIPaddr == 192.168.72.12) &&
(srcIPport == 80))
then
priority=6
endif
Mahon,Bernet,Herzog Expires March 2000 [Page 23]
Internet Draft Policy Requirements October 1999
The translation of the above rules would be fairly sim-
ple. Some devices can handle many rules such as those
above, while other devices can only handle relatively
few (e.g., 16 or less).
Sizing of policy can also affect performance. For exam-
ple, a router could experience greater latency in for-
warding a packet if too many rules (or rules containing
many condition lists) were configured on the device. On
the other hand, a firewall configured with security pol-
icy may have no problem handling a hundred or more rules
describing what traffic is to be allowed through the
firewall.
The size of policy on the Policy Target, therefore, is a
combination of the complexity of the number of Policy
Rules and the actions and conditions expressed in the
policy as well as the capabilities of the device itself
relative to the ability of the policy to be expressed in
the configuration commands of the device. The same pol-
icy may consume less memory on one device than on
another because of differences in the configuration
capabilities of the two devices.
4.3.2. Policy Capability
If a device has the ability to control traffic and can
exert that control by basing the behavior on things such
as information in the packet header, it is a candidate
for use with QoS policies. (The criteria for whether or
not something can be used with policy is dependent on
what capability, functionality, or behavior the policy
types involved are abstracting.)
Not all devices have the same capabilities. While a
policy type may be able to be mapped to a function on a
device, that device may not offer all of the conditions
(means for classification) that other devices with simi-
lar functions offer. For example, a policy for specify-
ing Committed Rate may use the value of the IP Prece-
dence field to classify traffic. A particular router
may not be able to handle this feature. If a policy
with IP Precedence in a rule condition is targeted for a
device which cannot use IP Precedence, the UI should
notify the user and prevent deployment. At a minimum,
if the UI is not equipped for this, the Policy Consumer
should return a status message that the policy was not
implementable on the Policy Target (if there was no
work-around by using some other feature of the target).
In another variation on the capabilities of a device,
not all devices can handle multiple conditions which
together identify traffic. (This may not apply to time
Mahon,Bernet,Herzog Expires March 2000 [Page 24]
Internet Draft Policy Requirements October 1999
conditions. See sections 4.5 and 5.6.1.) If a Rule
within a Policy contains multiple conditions, and the
Target is on a device which cannot handle such a Rule,
the Administrator should receive a message indicating an
error in the Policy.
Some devices are simply limited in the number of rules,
or the total number of conditions within rules, that can
be evaluated. In such a case the Policy Consumer (or
some element higher in the system) should provide feed-
back of this limitation.
4.4. Policy Conflicts
There are two types of policy conflicts that could exist:
1. conflicts between two rules within a policy
2. conflicts between actions within a rule
4.4.1. Conflict Between Two Rules Within a Policy
Within a Policy Group are one or more Policy Rules. As
defined in [INFOMODEL] these Policy Rules contain Policy
Actions and Policy Conditions.
Within a single Policy, it is possible to have more than
one Policy Rule which will evaluate 'true' for one cir-
cumstance. The oft cited example is as follows:
Rule 1
if (srcIPaddr == 192.168.2.3)
Priority=5
Rule 2
if (srcIPsubnet == 192.168.1.0/255.255.248.0)
Priority=3
...
In the above example, both Rule 1 and Rule 2 would eval-
uate true if the source IP address were 192.168.2.3. If
a configuration were to be entered into an existing
device (e.g., a router) to implement this behavior there
would be a forced ordering of evaluation, so that the
first match would be the action implemented.
The Policy Framework WG currently defines in the Core
Information Model a priority value associated with the
Policy Rule. This priority is used by the administrator
to set which Policy Rule is to have a higher priority,
so that if more than one Policy Rule can evaluate as
true, which Policy Rule has precedence. Unfortunately
Mahon,Bernet,Herzog Expires March 2000 [Page 25]
Internet Draft Policy Requirements October 1999
there is no uniqueness to the priority value, so that it
is still possible to have multiple rules which could
evaluate true and there is no way for the system to
determine which has higher priority.
The problem with the priority approach is that since
priority values need not be unique for a given set of
rules, different systems may choose different rules to
apply given the same input, which would lead to incon-
sistent QoS for traffic matching the multiple Policy
Rules. Rule evaluation must be deterministic, such that
the same policy, encountering the same input conditions,
renders the same results wherever the policy is
installed. Rule evaluation must be clearly determinable
in order for the administrator to properly specify and
understand how the policy (containing multiple rules)
will operate in the managed environment. Without such
determinism, policy will not meet the needs of those
interested in using it.
4.4.2. Conflicts Between Actions Within a Rule
If a rule contains multiple actions, it is possible that
the actions (or the results of the actions) will con-
flict with each other. An example of this is that one
action sets one type of queueing on a device, and the
other action sets another type of queueing, which for
that particular device are incompatible. For each type
of device such conflict may be detectable, but in a gen-
eral case may not be.
4.5. Time Aspects of Policy
With the policyTimePeriodCondition (and the PolicyRuleVa-
lidityPeriod condition as part of the Policy Rule) it is
possible to have behaviors related to time (see section
4.10.1).
This leads to interesting possibilities for policy.
With time-based policies Administrators may establish poli-
cies to limit certain kinds of traffic to provide enough
bandwidth for the nightly backup. Some customers may only
want to pay for better QoS during business hours. Policy
can be put in place to allow an Accounting Department to
have better QoS for accessing corporate financial informa-
tion during the last three days of the month. All of these
would be possible without the manual intervention of the
Administrator at the time the policies are to go into or
out of effect.
To take advantage of time-based policies, most existing
devices (which do not have time- or date-based
Mahon,Bernet,Herzog Expires March 2000 [Page 26]
Internet Draft Policy Requirements October 1999
configuration capabilities) would need a Policy Consumer
implemented separately from the device. New managed ele-
ments may be developed with time and date keeping functions
on them, or Policy Targets may reside on a host system
which has those functions.
It is also possible that the Policy Management Application
would change policy stored in the Policy Repository based
on time. This would have the advantage of removing the
need for time keeping on the Policy Target (or Policy Con-
sumer), but it would mean that Policy data is not as static
as currently expected. It also would cause a lag in
deployment of Policy to the Target since more components
are involved (the Policy Management Application, the Repos-
itory if indirect delivery is involved, and the Policy Con-
sumer). This could be solved, but a solution would make
the entire system more expensive.
Another affect of time-based policy is on the status of the
policy deployment. Depending on the implementation of the
Policy Consumer and the conflict detection mechanisms in
the system (if any exist) there may be a problem with the
policy information that is not visible until portions of
the policy with time conditions become 'active'. In other
words, portions of the policy (rules, or condition lists in
a rule) with time conditions become 'active' when the time
or date match values in the policyTimePeriodCondition.
These rules or condition lists may contain information
which brings the rule into conflict with one or more other
rules. Or even worse, the time based rule may contain con-
ditions which are not supported by the Policy Target (see
section 4.3.2).
4.6. Scalability
Policy systems must be able to handle many Policy Targets.
Methods for handling such scalability depend on the size of
the environment to be managed and other issues related to
the managed environment.
4.6.1. Scalability and Policy Targets
Looking at the system (as described in Figure 3) from
the bottom up, the first components which are affected
are the Policy Targets. In terms of what they manage,
Policy Targets are fixed since they are by definition a
single manageable entity. Scalability is a factor,
though, in terms of the amount of data, or configura-
tion, the Policy Target can actually handle. Every
device (or 'thing') has a finite set of resources. For
example, it would be possible to write a set of Policy
Rules that when translated to device configuration could
be more than the Policy Target could handle. In such a
Mahon,Bernet,Herzog Expires March 2000 [Page 27]
Internet Draft Policy Requirements October 1999
case the Policy Consumer would provide notification of
the problem to the Policy Management Repository. (The
problem could be detected by the Policy Consumer, or
some component of the Policy Management Application in
order to provide feedback before the Policy actually is
sent to the Policy Target.)
4.6.2. Scalability and Policy Consumers
To enable more outsourcing PEPs, more PDPs could be
deployed in the environment. A limiting factor would be
if information relevant to one PEP were to affect deci-
sions made for another PEP. In this case, the manage-
ment relationship would maintain PEPs which are logi-
cally related to the same PDPs, or the PDPs could commu-
nicate state information to support relationships
between PEPs. Either solution is beyond the scope of
the Policy Framework WG.
For other Policy Consumers, more Consumers may be placed
in the environment to address the increased number of
Policy Targets. Any coordination necessary between mul-
tiple Policy Consumers (beyond information in the Policy
Data) is beyond the scope of the Policy Framework WG.
4.6.3. Scalability and the Repositories
There are at least two issues for scalability for repos-
itories:
- number of clients accessing them
- amount of data stored in the repositories
The Policy Repository (e.g., an LDAP enabled directory
server) would be used to provide the policy data for a
management domain (i.e., a logical collection of managed
entities under the control of a single IT group). If
the number of Policy Consumers (including PDPs) is such
that it puts a strain on the resources of the Policy
Repository it would be necessary to have duplicate
repositories to provide better response to the Policy
Consumers. Since Policy Data is expected to be rela-
tively static, the Policy Repository should not be over-
loaded by policy management over an extended period of
time, but may become overloaded if policy for many Pol-
icy Targets were to change, which would cause many Pol-
icy Consumers to query the repository in a short period
of time. To minimize the affect of such a loading of
the Policy Repository, it would be desirable to allow
for replication of the repository, leading to the usual
issues relating to data coherence across repositories.
Using LDAP further adds management issues because the
Mahon,Bernet,Herzog Expires March 2000 [Page 28]
Internet Draft Policy Requirements October 1999
LDAP enabled server must be configured to replicate data
to the correct LDAP servers for Policy Data in a timely
fashion. If the Policy Administrator and Directory
Administrator are not the same, the Policy Administrator
places requirements on, and uses the services provided
by, the Directory Administrator.
Because it would directly communicate with Policy Con-
sumers and PDPs the Policy Management Repository resides
logically at the same level as the Policy Repository.
The information that the Policy Management Repository
works with is more volatile than the information in the
Policy Repository, therefore it is more susceptible to
being overloaded than is the Policy Repository.
The reason that information in the Policy Management
Repository is more volatile is that it stores status
information (see section 3.3.1). This information is
subject to change at any time even if restricted to Pol-
icy Deployment status (see section 4.5).
The mechanisms for replication among multiple Policy
Management Repositories is beyond the scope of the Pol-
icy Framework WG, but in the interest of interoperabil-
ity should be defined.
4.6.4. Scalability and the Policy Management Application
The Policy Management Application can contain multiple
functional components. The scalability of one of those
components, the Policy Management Repository is dis-
cussed above.
The other logical components include, but are not lim-
ited to:
- Policy UI
- Policy Conflict Detection
- Policy Consumer notification
Scalability issues related to the Policy UI mainly con-
cern the size of data. (?)
Similarly, the number of policies (and the number of
Policy Targets) impacts how fast Policy Conflict Detec-
tion can be accomplished.
4.7. Administration of the Policy Management System
Any Policy Management System will require some management
of the system itself, but in order to provide value it must
Mahon,Bernet,Herzog Expires March 2000 [Page 29]
Internet Draft Policy Requirements October 1999
be simpler than managing the individual entities under its
control separately. That is, using the Policy Management
System must cost less (in terms of human administration
time) than managing the environment without it.
This is not to say that initially it will be easy to use a
Policy Management System, for as noted in the Introduction
to this draft, it will require new ways of thinking about
the managed environment. Indeed, it is the requirement to
think in terms of what value the networked computing envi-
ronment is providing that is one of the driving forces
behind the development of Policy Based Management. As net-
working has become a central tool for business, the net-
worked computing infrastructure (and the IT staff support-
ing it) is being measured on value rendered to the business
organization. The value is measured in terms of access to
information and the applications which manipulate that
information and make it available (and valuable) to others.
As has been mentioned earlier, the Policy Data has already
received a great deal of attention. It is the components
which will use the data which will require most of the
administration. Each component, and the aspects which must
be administered will be discussed in the following sec-
tions.
As noted in the Introduction, the Policy Management System
is a distributed system. As such, the components may be
physically together or separate. Also, depending on the
implementation, there may be no externally visible inter-
faces between some of the components. The following dis-
cussion will try to describe the administration needs with-
out assuming any particular implementation.
Installation of anything requires some effort. Installa-
tion of the components of the Policy Management System will
require some extra overhead relative to existing environ-
ments. The key value will be that it is easier for the
administrator to alter the behavior of the network using
the components of the Policy Management System rather than
using other tools. Since most of the tools available to
the administrator today require touching each network ele-
ment individually, and require specific knowledge of each
element, the Policy Management System can significantly
reduce administration costs if it 1) abstracts functions
without requiring detailed knowledge of each element in the
networked environment, and 2) allows sharing, reuse, and
centralized control of the network elements allowing the
administrator to perform tasks without manually contacting
each network element.
This section is not intended to be an exhaustive listing or
specification of the features of a Policy Management
Mahon,Bernet,Herzog Expires March 2000 [Page 30]
Internet Draft Policy Requirements October 1999
System, but rather to provide a realistic description of
the administrative tasks required of such a system.
4.7.1. Policy UI
The Policy UI may be part of other components of a Pol-
icy Management Application, such as the Policy Manage-
ment Repository. If it is instead a stand-alone compo-
nent it will require more administration. Much of this
depends on the implementation, and may be beyond the
scope of the Policy Framework WG.
The UI must be installed, requiring some amount of disk
space. It may be configured as to which Policy Reposi-
tory and Policy Management Repository are to be used.
If a Public Key mechanism is to be used for authentica-
tion or encryption between the UI and other components
of the Policy Management Application, then those keys
must be generated and put in place.
Any logging that the UI performs, either independently
or as part of the Policy Management Application, may
also require administration. Information to be config-
ured would include such items as log file location, max
log file size, other logging information destinations,
type of information to be placed in the log, etc.
4.7.2. Policy Conflict Detection
Since this is one of the least discussed logical compo-
nents, it is hard to assess the characteristics of this
component. Assuming Policy Conflict Detection to be a
separate component, it would need to be installed, con-
figured for communication (keys, Policy and Management
Repository location(s), etc.), logging, and any configu-
ration for the component itself, such as the Policy Tar-
gets for which it may be responsible, valid Policy Types
and Policy Conditions, etc.
4.7.3. Policy Repository
The Policy Repository will also require administration.
The amount of administration required will depend on the
technology chosen for the repository. A general purpose
mechanism may require more administration effort than a
purpose specific repository technology.
If an LDAP enabled directory is used, and the directory
is being used for other purposes within an IT environ-
ment, the tasks of installation and configuration will
mainly already be covered. In addition any security
configuration and optional replication configuration
specific to Policy Management would be required.
Mahon,Bernet,Herzog Expires March 2000 [Page 31]
Internet Draft Policy Requirements October 1999
Additional administration may be required to provide
access control for who or what is allowed to modify data
in the portions of the repository used for Policy.
4.7.4. Policy Management Repository
The Policy Management Repository would need to be
installed, configured with any security information, and
possibly configured for which repositories from which it
can receive information. If additional Policy Manage-
ment Repositories are installed to address scalability
for receiving information from Policy Consumers, it must
also be configured with information about the upstream
Policy Management Repository to which it reports status
and configuration information from Policy Consumers.
Logging would also need to be configured.
4.7.5. Policy Consumers
The function and implementation of Policy Consumers
could vary (see section 2.1), so issues of administra-
tion may not apply to all Policy Consumers.
At a minimum security information would need to be con-
figured during or after installation. So would informa-
tion about how to contact the Policy Repository and (if
separate from the Policy Repository) the Policy Manage-
ment Repository. Optionally, the Policy Consumer may be
configured for the Policy Targets for which it is
responsible. This configuration may be done at the Pol-
icy Consumer, at the Policy UI, or be automated as part
of a discovery process. Logging may also need to be
configured.
4.7.6. Policy Targets
Policy Targets (or the device which contains multiple
Targets) may need to be configured in order to work in
the Policy Management System. Such configuration items
could include security configuration (keys, passwords,
ACLs, etc.), logging, Policy Consumers (if implemented
off of the device containing the Policy Target), etc.
4.8. Policy Conditions
There are multiple types of Policy Conditions that could be
used. The following sections describe two types of Policy
Conditions and how they are used.
4.8.1. Time/Date Conditions
The policyTimePeriodCondition described in [INFOMODEL]
provides the ability to specify when a Policy Action may
Mahon,Bernet,Herzog Expires March 2000 [Page 32]
Internet Draft Policy Requirements October 1999
take place. This allows great flexibility in allowing
(or disallowing) particular usages of the network.
Often used examples of how time-based policies would be
used are to allow a set of users to have improved QoS
during business hours, an Accounting department to have
better QoS on the 15 and the last three days of the
month, and to give nightly backups priority during spec-
ified hours during the night.
Time is intended to be used as a period during which the
Action portion of the Policy Rule could be enacted
(depending on any other conditions which may be present
in the Condition portion of the Policy Rule). Time is
not intended to provide an event, or single point in
time which causes a specified action to occur (as in a
UNIX 'cron' job), but provide a time specification on
other conditions which may be observed when an event
which causes policy interpretation to occur.
The attributes of the policyTimePeriodCondition are:
ptpConditionTime
ptpConditionMonthOfYearMask
ptpConditionDayOfMonthMask
ptpConditionDayOfWeekMask
ptpConditionTimeOfDayMask
ptpConditionTimeZone
4.8.2. Packet Conditions
Packet Conditions are based on characteristics that may
be observed in the packet itself. For layer 3 devices
dealing with IP such characteristics which may be
directly observed include:
- Destination IPaddress
- Destination IPport
- Destination IPsubnet
- IPaddress (matches either source or destination)
- IPport (matches either source or destination)
- IPsubnet (matches either source or subnet)
- Source IPaddress
- Source IPport
- Source IPsubnet
- Type of Service - IP precedence bits
Source and destination subnet may be inferred from the
IP address information (the condition would contain the
subnet mask to allow determination of affinity).
Mahon,Bernet,Herzog Expires March 2000 [Page 33]
Internet Draft Policy Requirements October 1999
Devices with sufficient capability may be able to look
at other portions of the packet, below layer 3 and above
layer 3. Such other information that may be observed
include:
- Application Traffic (if not clear from the Port
number used, or more detailed than the Port
number reveals)
- Protocol Type (IP, IPX, ARP, DECNet, Appletalk,
SNA over Ether)
- URL
- VLAN ID
These conditions may allow an Administrator to infer who
(i.e., users associated with IP addresses) or what
(i.e., what applications) are using the network, or
both, and specify what type of QoS is to be provided to
those uses of the shared network resources. See section
5 for examples. Such bindings are made more reliable
when binding information received in signaling messages
is leveraged.
4.9. Implementation examples
Quite a bit has been described above about how Policy data
and other information related to Policy would be shipped
from one component to another. In discussions of Policy
Management Systems the subject of 'What would be the best
protocol?' always seems to come up. The short answer is
that there is no 'perfect' protocol because each has
strengths and shortcomings. The following sections will
describe the most common candidates for transporting infor-
mation within a Policy Management System
4.9.1. LDAP
While LDAP is often associated with a Directory Service,
it is simply the protocol for transporting information
stored within the Directory and accessing the informa-
tion in the Directory. LDAP does not specify the Direc-
tory itself.
LDAP is designed to provide access to information for
clients dispersed across a network. LDAP is not well
suited to providing this access for information that
changes often (on the order of minutes), nor is it well
suited for passing messages between clients. LDAP cur-
rently does not provide mechanisms for notifying clients
when information they care about changes in the server.
Mahon,Bernet,Herzog Expires March 2000 [Page 34]
Internet Draft Policy Requirements October 1999
LDAP is optimized to have data written to the directory
once, and then read thousands of times.
+-------------------+
|Policy Mmgt App. |
| - Policy UI |
| - Conflict detect |
| - Notification |
| - Mgmt repos. |
| |
| |
+-------------------+
^ | ^
| | |LDAP
| | |
| | |Policy Data
| | V
| | +------------+
| | |Policy rep |
| | | |
| | | |
| | +------------+
| |notif. /
status | | /Policy data
and config| | /LDAP
info | v v
+---------------+
| Policy |
| Consumer |
| |
+---------------+
^ ^
| \
| \
V V
+-----------+ +-----------+
| Policy | | Policy |
| Target A | | Target B |
| | | |
+-----------+ +-----------+
Figure 6. Diagram of a Policy Management System using LDAP.
Figure 6 is a modification of Figure 3 showing where
LDAP would be used for providing data within a Policy
Management System.
The Policy Management Application would retrieve Policy
Data from the Directory Service via LDAP in order to
allow the Administrator to view or modify existing pol-
icy. The Policy Management Application would also use
LDAP to write new or modified Policy Data to the
Mahon,Bernet,Herzog Expires March 2000 [Page 35]
Internet Draft Policy Requirements October 1999
Directory Server acting as the Policy Repository.
The Policy Consumer would either poll the Policy Reposi-
tory via LDAP or be notified by the Policy Management
Application via other means that new Policy is available
for the Policy Consumer to read.
Where the Policy would be stored in an LDAP enabled
Directory is also an open issue. For many reasons it
does not make sense to define a canonical location to be
used in all Directories.
There also needs to be an association between the Policy
Data and the Policy Targets the Policy Data affects.
This information about the association may be stored in
the Directory or elsewhere. If the association were
stored in the Directory, and the schema for the associa-
tion were standardized, the Policy Consumer could then
search the directory for the appropriate attribute which
stores the reference for the Policy Targets for which it
is responsible. The association object would then pro-
vide a pointer to the Policy for the Policy Targets.
If the association between Policy Data and the Policy
Targets were not stored in the Directory, then the mech-
anism that notifies the Policy Consumer of new policy
should also provide information about where to find the
Policy Data in the Directory. This may be a more eco-
nomical method for the Policy Consumer to find the Pol-
icy Data in the Directory since it would require less of
the Directory's resources (i.e., no search would be
required).
For the notification, the same, or yet another protocol
could be used to allow status to be sent to the Policy
Management Repository.
Taking the list of deployment steps from section 3 and
putting in the detail of using LDAP, we would have:
A. Administrator authors new policy (or edits existing
policy)
Aa. Administrator retrieves existing policy from Direc-
tory Service using LDAP and views or edits policy
B. Administrator associates policy with Policy Tar-
gets.
C. Policy and association with Policy Targets is
stored in Policy Repository via LDAP.
Mahon,Bernet,Herzog Expires March 2000 [Page 36]
Internet Draft Policy Requirements October 1999
D. For each of the Policy Targets, the associated Pol-
icy Consumers are notified that new policy is
available for the Policy Targets using Protocol X.
E. The Policy Consumer obtains the Policy from the
Policy Repository via LDAP. (The Policy Consumer
may issue a query to determine where to find the
Policy Data.)
F. The Policy Consumer processes the Policy Data and
configures the Policy Target(s) using the appropri-
ate mechanism(s) for the Target(s). (A standard-
ized interface between between the Policy Consumers
and Policy Targets would would support the require-
ment of commonality across devices, with all of the
attendant benefits.)
G. For each Policy Target which received Policy Data,
the Policy Consumer provides status information
back to the Policy Management Application via Pro-
tocol Y.
An added benefit of using LDAP is that any LDAP client
may obtain Policy Data (as long as the client is autho-
rized to access that information).
LDAP supports authentication of clients and privacy for
data transported across the network.
LDAP also has mechanisms for replication between multi-
ple LDAP servers which enables scaling.
As a primary means for storing Policy information, LDAP
does not support versioning of the data, nor, for that
matter, does the Policy Core Information provide for
versioning of the Policy data.
4.9.2. SNMP
SNMP provides asynchronous communications in both direc-
tions, although not symmetrical in nature.
Using Figure 6, SNMP could be the transport to provide
the notification using a 'Set' operation on a MIB, with
information about what Policy is to be used for each
Policy Target for which the Policy Consumer is responsi-
ble. The Policy Consumer in return could send status
back to the Policy Management Application at any time
using SNMP traps.
One drawback is that most SNMP implementations use UDP.
If UDP were used the Policy Management Application and
Policy Consumers would need to provide feedback to each
Mahon,Bernet,Herzog Expires March 2000 [Page 37]
Internet Draft Policy Requirements October 1999
other to ensure messages were actually received. SNMP
over TCP would allow communications between the Policy
Consumers and Policy Management Application to be
robust. Implementations of SNMP over TCP already exist.
SNMP could be used on all of the data paths in Figure 6,
not only notifying the Policy Consumers of new Policy
Data, but delivering Policy Data as well, eliminating
the need for the Policy Consumer to query the Policy
Repository.
For a TCP-based SNMP implementation a connection would
be established and maintained in order to allow messages
to be sent quickly between the client and server.
Taking the list of deployment steps, using an all SNMP
solution would yield:
A. Administrator authors new policy (or edits existing
policy)
Aa. Policy UI retrieves existing policy from Policy
Repository using SNMP Get and Administrator views
or edits policy
B. Administrator associates policy with Policy Tar-
gets.
C. Policy and association with Policy Targets is
stored in Policy Repository via SNMP Set.
D. For each of the Policy Targets, the associated Pol-
icy Consumers are provided with new policy for the
Policy Targets using SNMP Set commands.
E. The Policy Consumer processes the Policy Data and
configures the Policy Target(s) using the appropri-
ate mechanism(s) for the Target(s).
F. For each Policy Target which received Policy Data,
the Policy Consumer provides status information
back to the Policy Management Application via SNMP
Traps.
A mechanism for replicating data among Policy Management
Applications using only SNMP would need to be defined to
enable scaling of the solution for many thousands of
Policy Targets.
Figure 7 shows how an all SNMP solution would look while
still using an LDAP enabled Directory as an export mech-
anism to other Policy Management Applications. Undeter-
mined is any mechanism (or requirement) for notification
Mahon,Bernet,Herzog Expires March 2000 [Page 38]
Internet Draft Policy Requirements October 1999
to other Management Applications of new policy.
+-------------------+
|Policy Mmgt App. |
| - Policy UI |
| - Conflict detect | +-----------+
| - Notification | |Policy |
| - Mgmt repos. | LDAP |Repository |
| |<------->|(Directory |
| | | Server) |
+-------------------+ +-----------+
^ |
SNMP| |SNMP
| |
| |Policy
status | |Data
and config| |
info | v
+---------------+
| Policy |
| Consumer |
| |
+---------------+
^ ^
| \
| \
V V
+-----------+ +-----------+
| Policy | | Policy |
| Target A | | Target B |
| | | |
+-----------+ +-----------+
Figure 7. SNMP is used for all communication between Policy
Management Application and Policy Consumer.
With SNMPv3, features are introduced which provide
secure communications (privacy and integrity) between
the components of the Policy Management System.
4.9.3. COPS
Like SNMP, COPS provides asynchronous yet asymmetrical
communications between a client and server, and is based
on TCP.
An appropriate COPS client type could provide objects
for notification to a Policy Consumer, as well as allow
the Policy Consumer to send status information to the
Policy Management Application asynchronously. In addi-
tion, the COPS client type could define objects to
enable delivery of Policy Data for Policy Targets using
COPS decision messages.
Mahon,Bernet,Herzog Expires March 2000 [Page 39]
Internet Draft Policy Requirements October 1999
For COPS communications between the Policy Management
Application and the Policy Consumers a connection would
be established and maintained in order to allow messages
to be send quickly.
Taking the list of deployment steps, an all COPS solu-
tion could look like:
A. Administrator authors new policy (or edits existing
policy)
Aa. Policy UI retrieves existing policy from Policy
Repository using a COPS request message and Admin-
istrator views or edits policy.
B. Administrator associates policy with Policy Tar-
gets.
C. Policy and association with Policy Targets is
stored in Policy Repository via COPS request.
D. For each of the Policy Targets, the associated Pol-
icy Consumers are provided with new policy for the
Policy Targets using COPS decision messages.
E. The Policy Consumer processes the Policy Data and
configures the Policy Target(s) using the appropri-
ate mechanism(s) for the Target(s).
F. For each Policy Target which received Policy Data,
the Policy Consumer provides status information
back to the Policy Management Application via COPS
status response messages.
A mechanism for replicating data among Policy Management
Applications using only COPS would need to be defined to
enable scaling of the solution for many thousands of
Policy Targets.
For a COPS solution, Figure 7 could be altered to use
'COPS' instead of 'SNMP'.
COPS currently has no built-in mechanisms to provide
private communications between components, but [COPS]
now defines an integrity object to enable a client to
verify it received a valid message.
4.9.4. HTTP
HTTP is a protocol that is available on many devices and
host systems today. It does provide asynchronous capa-
bilities between client and server. Typical HTTP con-
nections are short-lived but that is not a requirement.
Mahon,Bernet,Herzog Expires March 2000 [Page 40]
Internet Draft Policy Requirements October 1999
The Policy Consumer or the Policy Management Application
could act as the server. Because the Policy Management
Application should be more stable than the Policy Con-
sumers, the Policy Management Application is more the
candidate for being an HTTP server. Regardless, all
that is necessary is for a connection to be established
before either end needs to send a message to the other.
Again using the list of deployment steps, an all HTTP
solution would look like:
A. Administrator authors new policy (or edits existing
policy)
Aa. Policy UI retrieves existing policy from Policy
Repository using an HTTP Get message and Adminis-
trator views or edits policy.
B. Administrator associates policy with Policy Tar-
gets.
C. Policy and association with Policy Targets is
stored in Policy Repository via Post request.
D. For each of the Policy Targets, the associated Pol-
icy Consumers are provided with new policy for the
Policy Targets via responses to Get messages from
Policy Consumer.
E. The Policy Consumer processes the Policy Data and
configures the Policy Target(s) using the appropri-
ate mechanism(s) for the Target(s).
F. For each Policy Target which received Policy Data,
the Policy Consumer provides status information
back to the Policy Management Application via HTTP
Post messages.
A mechanism for replicating data among Policy Management
Applications using only HTTP would need to be defined to
enable scaling of the solution for many thousands of
Policy Targets.
For an HTTP solution, Figure 7 could be altered to use
'HTTP' instead of 'SNMP'.
HTTP supports use of SSL to secure communications allow-
ing authentication and privacy during data transfer.
4.10. Policy Interpretation
One of the important ideas behind Policy Management is that
a Policy may be used across multiple devices (Policy
Mahon,Bernet,Herzog Expires March 2000 [Page 41]
Internet Draft Policy Requirements October 1999
Targets) which collectively provide a service. This use of
Policy would allow those devices to provide a consistent
level of service. This means that each of these Policy
Targets must interpret the Policy (and the Policy Rules
that make up the Policy) in the same way.
As noted in section 4.4.2 the current Policy Core Informa-
tion Model does not ensure that any two Policy Consumers
(or their Policy Targets) will interpret Policy because it
does not specify an unambiguous method for resolving con-
flict between multiple Policy Rules which may simultane-
ously evaluate true.
4.11. Policy Information
Policy used by a Policy Consumer MUST come from a single
source (i.e. a single Policy Repository). That Policy
MUST be in the form of a single grouping of Policy Rules.
Without this grouping, the administrator is not assured of
seeing all of the Policy Rules which may be associated with
a Policy Target. Without this ability to see all of the
Policy Rules associated with a Policy Target there is no
way for the Administrator to be assured that under a given
set of conditions (as specified by Policy Conditions) that
a Policy Target will act in accordance with the wishes of
the Administrator.
5. Usage Cases
A Policy Management System is not a solution unto itself. The
fact that it exists in a managed environment does not in and
of itself provide a solution. Administrators must understand
their networks, and how they are being used. In addition
Administrators should understand what their customers need in
order to do their jobs, and what their customers want to do
with the network (since needs and wants are not necessarily
the same).
Administrators can begin the process of Policy-based manage-
ment by monitoring the traffic on their networks and estab-
lishing baseline measures. Traffic and usage patterns vary,
but patterns can be determined which provide Administrators
with a valuable basis for later actions. Using tools which
provide information about the types of traffic, not just the
volume, can provide the Administrator with information about
the traffic related to critical business functions. In addi-
tion, if the collected information indicates sources and des-
tinations of the traffic, both inside the firewall and through
it, the Administrator can relate that to the type of traffic
and better understand particular uses. For example, Web traf-
fic can be work-related or recreational. Traffic within the
company network, such as to a Personnel server, is work-
related. Traffic to www.espn.com, though, is probably not
Mahon,Bernet,Herzog Expires March 2000 [Page 42]
Internet Draft Policy Requirements October 1999
work-related, unless the user is a sports reporter. This
kind of information, along with direct input from the users of
the network (the Administrator's customers) will be the basis
for the Policies managing the network.
Note that when using the term 'device' it is reasonable to
substitute firewall, host computer, software application,
operating system, network stack, Network Interface Card (NIC),
or any other 'thing' that can be managed. Somehow 'device'
just sounds better than 'thing'.
Below are some examples of how Policies can be used to address
Network Management needs.
5.1. An Accounting Department Example
Accounting departments can be large users of networked
resources. Sales orders, product inventory, shipping
information, payroll information, and more must be accumu-
lated and processed to provide monthly and quarterly
reports. Network traffic levels can be expected to (and
does) increase during such periods. This doesn't just
involve servers, but the end systems on the desks of the
individuals collecting and processing the information as
well. Thus the traffic is not isolated to a small portion
of the network.
It is not uncommon for Network Administrators to ask other
users of the network to limit usage of the network during
these times to give Accounting priority . This is at best
a hit or miss proposition, since it is difficult for a user
to understand what impact any given activity will have on
the network. A user can easily understand that transfer-
ring a large file via FTP can impact other users of the
same network, but what is the impact of Web browsing, read-
ing News, or e-mail? Asking all of the users of the net-
work to manage their traffic is asking everyone to manage
the network.
Policy Management is a way for the Network Administrator to
pro-actively manage the network, not simply react to how
users use the network. The intent is to ensure the value
of a shared resource, which is what the network is, not to
take anything away from the users.
For this example we'll use a fictional but realistic sce-
nario. The Accounting department must issue reports for
each month. The pace of sales orders typically increases
just before the close of the month. The company has opera-
tions dispersed geographically, including sales offices and
warehouses. The information for generating the end-of-
month reports must be obtained from these different loca-
tions by the Accounting department's systems. In addition,
Mahon,Bernet,Herzog Expires March 2000 [Page 43]
Internet Draft Policy Requirements October 1999
each of these different operations are generating their own
reports. Accounting traffic can take a significant portion
of the network's bandwidth, but Accounting isn't the only
user of the network. The reports are due on the first of
the month, so traffic gets heavier during the last 10 days
of the month. Quarterly reports are due on the 15th of
each month, and work on this begins as soon as the previous
monthly report is finished. The company in this example
has a fiscal year that matches the calendar year, so quar-
ters end at the end of March, June, September, and Decem-
ber. That means that work on quarterly reports occur in
April, July, October, and January. For the purposes of
keeping this example relatively simple, the Accounting
department's systems are on a separate subnet at the corpo-
rate offices.
A simple approach would be to give priority to traffic to
or from Accounting during these times. To do this the
Administrator could author a policy such as the following:
if (((trafficToOrFrom AccountingSubnet) &&
(dayOfMonth in last10days))
||
((trafficToOrFrom AccountingSubnet) &&
(monthIn [April, July, October, January]) &&
(dayOfMonth in [1-15])))
then
priority = high
endif
Expressions in the condition list such as 'trafficToOrFrom'
and AccountingSubnet are abstractions which maybe presented
by management implementations to provide understandable yet
accurate representations of management goals. Such repre-
sentations as 'AccountingSubnet' would be specified else-
where in the Policy Management Application or may be taken
from other established mappings that already exist in the
environment (e.g., directory entries, etc.). Such high
level representations may exist in an implementation but
are not required. The requirement is the information that
goes into the Policy Schema, which is discussed below.
In the above Policy Rule the traffic is being tested for
coming from or going to the subnet for the Accounting
department. If the traffic is coming from or going to the
AccountingSubnet, and it is the last 10 days of the month,
or is the first fifteen days of the month after the end of
a quarter, then the traffic is given high priority.
Instead of comparing against a subnet, the test could be
for a set of machines, or could be for a specific applica-
tion.
Mahon,Bernet,Herzog Expires March 2000 [Page 44]
Internet Draft Policy Requirements October 1999
The above Policy Rule would be translated into an actual
set of device independent information which conforms with
the Policy Schema.
Since this Policy Rule is likely not the only Policy infor-
mation that would be deployed to a set of devices in the
network, this example will add other Policy Rules in the
set to be deployed to a target (as described in section
2.1). First is the representation in Policy Schema terms
of what the above Policy Rule would translate into:
Rule 1: provide high QoS for traffic to or from the
AccountingSubnet during the last 10 days of the
month, or first 15 days after the end of a
fiscal quarter
if (((IPsubnet 192.168.12.0/255.255.248.0) &&
(dayOfMonth in last10days))
||
((IPsubnet 192.168.12.0/255.255.248.0) &&
(monthIn [April, July, October, January]) &&
(dayOfMonth in [1-15])))
then
priority = 6
endif
The abstraction 'trafficToOrFrom' has been translated into
IPsubnet, which will match traffic going to or from the
specified subnet. If, for example, instead of Accounting-
Subnet, the specification had been AccountingServers the
translation would have been IPaddress, which would have
compared the list of machines against the source or desti-
nation address on packets. What is stored in the Policy
Repository could still be labels (or names) for the condi-
tion values rather than fixed information such as IP
addresses and subnet values. When the information were
sent to the Policy Consumer, though, the information must
be resolved.
The Policy Condition types would be resolved before being
placed in the Policy Repository. The responsibility of
representation to the user is left to the Policy Management
Application and is outside of the scope of this document.
The following includes additional Policy Rules that are to
be deployed to multiple targets along with the above Policy
Rule. These are represented roughly according to Policy
Schema in appropriate boolean form. (Individual components
of the PolicyTimePeriodCondition are represented in the
interest of readability.)
Mahon,Bernet,Herzog Expires March 2000 [Page 45]
Internet Draft Policy Requirements October 1999
Rule 1: provide high QoS for traffic to or from the
AccountingSubnet during the last 10 days of the
month, or first 15 days after the end of a
fiscal quarter
if (((IPsubnet 192.168.12.0/255.255.248.0) &&
(dayOfMonth in last10days))
||
((IPsubnet 192.168.12.0/255.255.248.0) &&
(monthIn [April, July, October, January]) &&
(dayOfMonth in [1-15])))
then
priority = 6
endif
Rule 2: provide medium QoS for intra-company Web usage during
business hours from the accounting subnet
if (((srcIPsubnet == 192.168.12.0/255.255.248.0) &&
(destIPport == 80) &&
(destIPsubnet == 192.168.0.0/255.255.0.0) &&
(timeOfDay == 0800-1700) && (dayOfWeek == _MTWRF_))
||
((destIPsubnet == 192.168.12.0/255.255.248.0) &&
(srcIPport == 80) &&
(srcIPsubnet == 192.168.0.0/255.255.0.0) &&
(timeOfDay == 0800-1700) && (dayOfWeek == _MTWRF_)))
then
priority = 4
endif
Rule 3: provide medium QoS between two servers which share
database, directory, and other information
if (((srcIPaddress == 192.168.12.17) &&
(destIPaddress == 192.168.24.8))
||
((srcIPaddress == 192.168.24.8) &&
(destIPaddress == 192.168.12.17)))
then
priority = 4
endif
Mahon,Bernet,Herzog Expires March 2000 [Page 46]
Internet Draft Policy Requirements October 1999
Rule 4: provide high QoS to multicast traffic to the corporate
management subnet during business hours and all day
Sunday (for important business meetings)
if (((srcIPsubnet == 224.0.0.0/240.0.0.0) &&
(timeOfDay == 0800-1700) && (dayOfWeek == _MTWRF_))
||
((srcIPsubnet == 224.0.0.0/240.0.0.0) &&
(dayOfWeek == S______)))
then
priority = 6
endif
Rule 5: provide high QoS to nightly backup on server at IP
address 192.168.2.15 from 2 to 4 AM on weeknights
and Saturdays
if (((srcIPaddress == 192.168.2.15) ||
(destIPaddress == 192.168.2.15))
&&
(timeOfDay == 0200-0400)
&&
(dayOfWeek == _MTWRFS))
then
priority = 6
endif
Rule 6: provide lowest priority QoS for Quake traffic
if (IPport == 26000)
then
priority = 0
endif
Table 1. A Policy made up of Policy Rules.
The Administrator would author the policies as illustrated
in Table 1 to meet objectives for the portion of the net-
work for which the Administrator is responsible. The
Administrator may author other policies to address other
needs, and these policies may be of other types. Priority
policies are necessary for some needs, while Committed Rate
policies address other kinds of needs. RSVP policies
address yet another set of needs on the network. And so
on.
Once the administrator has authored these rules they would
be committed to a repository. How the Policy Management
Mahon,Bernet,Herzog Expires March 2000 [Page 47]
Internet Draft Policy Requirements October 1999
Application chooses to order operations is implementation
dependent, but the Policy Rules must be grouped together to
form a Policy Group. Once grouped the Policy can option-
ally be run through tools to determine if there are con-
flicts between Policy Rules within the Policy.
The Policy also needs to be associated with Policy Targets.
Once this association is created the Policy may be tested
for any conflicts with other Policies.
The Policy may now (or already have been) stored in the
Policy Repository. The Policy can now be deployed to Pol-
icy Consumers. The Policy Management Application would
send a notification to the Policy Consumers that there is
New Policy for them. A good notification message would
include references to the Policy Targets affected (individ-
ualized for each Policy Consumer) as well as information
about where to find the Policy in the directory.
If the Policy data is replicated across multiple Policy
Repositories, the Policy Management Application should ver-
ify replication has occurred before sending out the above
notification.
The Policy Consumers would now retrieve the Policy and
notify the Policy Management Application of receipt. The
Policy Consumer may also verify validity of the Policy at
this point.
The Policy Consumers would perform the appropriate actions
for each Policy Target to instantiate the Policy on each
Policy Target associated with the Policy and for which that
Policy Consumer is responsible. The Policy Consumer would
then provide status information to the Policy Management
Repository regarding the success of the deployment opera-
tion.
5.1.1. Policy Consumer For an Existing (Legacy) Device
In order to allow an existing device, which has no con-
cept of the Policy Schema, to use Policy a Policy Con-
sumer can be implemented which can receive Policy data
and provide the appropriated mapping from Policy Data to
device configuration actions. This may involve opera-
tions not directly mapping to device capabilities, for
example handling time and date related conditions, which
are not supported by many devices today.
Such a Policy Consumer may be appropriate for future
devices after Policy Management is well established.
Reasons for this could include vendors may decide not to
place such functionality on the device itself for cost
or other factors. The device itself would then be
Mahon,Bernet,Herzog Expires March 2000 [Page 48]
Internet Draft Policy Requirements October 1999
'Policy unaware', while the addition of a Policy Con-
sumer for such a device would allow it to work with a
Policy Management System.
Some of the Policy Rules in Table 1 contain time and
date conditions, which are shorthand for the components
of the policyTimePeriodCondition class. The Policy Tar-
get in this example is the Priority Queuing feature of
an interface on a router.
The Policy Consumer would receive the Policy Data in a
form conformant with the structure described in [INFO-
MODEL], including the time conditions. The Policy Con-
sumer would validate the Policy Data, then filter the
Policy Data based on the time information. For
instance, Rule 2 would be translated and sent to the
Policy Target (along with other rules in effect) only
Monday through Friday, during the hours of 8 AM to 5 PM.
At 5 PM Monday through Friday, for example, the Policy
Consumer would understand that a time period within a
rule has expired which would cause the Policy Consumer
to re-evaluate what information should be configured on
the Policy Target. In this example, the Policy Consumer
would cause the configuration related to Rule 2 to be
removed from the Policy Target (because the Rule con-
tains one condition list and that condition list con-
tains a time condition). At 8AM on Monday through Fri-
day the Policy Consumer would again re-evaluate the Pol-
icy Data and would add the configuration information
relative to Rule 2 to the configuration of the Policy
Targets associated with the Policy. The non-time por-
tions of the condition list would be converted into an
Access Control List (ACL) on the router with the source
subnet, destination subnet, and destination IP Port num-
ber when the time condition is true.
To continue the example, configuration relating to Rule
3 would always be on the Policy Target since it does not
have a time component. The two condition lists would be
converted into ACLs for the router, each ACL specifying
a source and destination pair.
Rule 4 again is subject to time conditions. When one of
the time conditions evaluates true an ACL will be con-
figured on the router to match traffic with a source
subnet matching a multicast address.
Rule 5 also contains a time condition and when the time
conditions evaluate true, the Policy Target will be con-
figured with two ACLs, one matching the address for the
backup server as the source address and the other match-
ing the destination address to allow traffic going to
and coming from the backup server to have better QoS.
Mahon,Bernet,Herzog Expires March 2000 [Page 49]
Internet Draft Policy Requirements October 1999
Rule 6 contains no time conditions, so would be con-
verted into an ACL matching port 26000 (the registered
port for Quake, a multi-user game) as the source or des-
tination port on a packet, and provide it with the low-
est priority. If a device has a feature which provides
less than best effort priority, this value may be mapped
to such a capability on that device.
Since Rule 1 has date based conditions, it would be con-
verted to an ACL matching the specified subnet as the
source or destination subnet during the last 10 days of
the month or the first 15 days of a month after the end
of the quarter. The ACL would not be configured for
Target (for this Rule) during other time periods.
(Note, the schema allows PolicyTimePeriodCondition to be
attached to the PolicyRule itself rather than be
expressed within the Condition List. For simplicity it
was represented in the Condition List.)
Prior to deploying the Policy configuration to the
device hosting the Policy Target, the Policy Consumer
will determine the current configuration. If there is a
configuration such that a feature which conflicts with
the operation of this Target exists, the Policy Consumer
will provide feedback to the Policy Management Reposi-
tory about the condition and will not deploy the Policy.
If there is configuration for the Policy Target which
relates to the Policy configuration to be deployed, the
Policy Consumer will issue commands (e.g., SNMP set com-
mands, Telnet CLI, etc., as appropriate for the device)
to delete the configuration or free resources which will
no longer be used.
At this point the Policy Consumer will actually send the
configuration commands to the device in order to cause
the Policy Target to act in accordance with the Policy
(as appropriate based on time and date conditions,
etc.).
Once the Policy Rules based configuration has been sent
to the Policy Target(s) the Policy Consumer will deter-
mine the success of the deployment and provide feedback
to the Policy Management Application. In order to
determine the success, for this example, the Policy Con-
sumer will query the device and examine the information
relating to the configuration of the Policy Target(s) to
determine if the configuration now matches what the Pol-
icy Consumer expects based on the Policy Data. If no
errors were encountered during the deployment and the
configuration is correct, the Policy Consumer will
report success. This status information would be stored
as an attribute of the Policy Target in the Policy Man-
agement Repository.
Mahon,Bernet,Herzog Expires March 2000 [Page 50]
Internet Draft Policy Requirements October 1999
As described above, at the start or end of a time/date
period expressed in a condition the Policy Consumer
would re-evaluate the Policy Rules for the Policy Target
and perform the necessary translations, check existing
configuration, perform any necessary clean-up, deploy
the corresponding configuration, and report status.
(Alternatively the Policy Consumer could generate the
appropriate information for any given time period speci-
fied in the Policy Rules and simply download them at the
appropriate times rather than filter at each time bound-
ary.)
5.1.2. Policy Consumer for a Policy Aware Device
A Policy Aware device is a device which is has the abil-
ity to handle Policy in the form specified by the Policy
Schema. In other words, a Policy Aware device is one
which has a Policy Consumer capability implemented on
the device itself.
Without dictating the actual implementation, there are
reasonable expectations of the functions that would be
implemented on a Policy Aware device. Along with the
Policy Consumer, which is the interface for receiving
Policy, there needs to be local storage of Policy or
derived information, interpretation of the Policy which
may include translation to configuration, time-keeping
to support time and date conditions, and features to
provide feedback to the Policy Management Application of
the status of Policy deployment as well as any other
attributes of the Policy Target(s) related to Policy
management.
If the Policy Consumer is implemented on the same device
as the Policy Target, how the behaviors dictated by Pol-
icy Rules are put in force is implementation specific.
5.1.3. Other Policy Consumer Uses
It is possible that a device may be implemented that can
handle Policy Information but does not interact directly
with the Policy Management Application or Policy Reposi-
tory. In this case a simple Policy Consumer may be used
to act as a simple proxy between the device and the Pol-
icy Management System. Such a Policy Consumer would
simply forward Policy Data to the device.
The important thing to note is that the only requirement
for a Policy Consumer is to act as an interface for Pol-
icy Targets with the Policy Management System. How the
functionality that needs to occur between the interface
to the Policy Consumer and the Policy Target is depen-
dent on the implementation. As long as the Policy
Mahon,Bernet,Herzog Expires March 2000 [Page 51]
Internet Draft Policy Requirements October 1999
Consumer can interact with the Policy Management Appli-
cation (receiving Policy, notifications, provide status
and other feedback, etc.) and the Policy Target can
implement the Actions specified in Policy Rules they are
compliant with requirements of the Policy Management
System.
The function of Policy evaluation can reside in the Pol-
icy Consumer, the Policy Target, in both, or somewhere
in between. The act of Policy evaluation may even occur
in stages within the implementation; for example the
time conditions may be evaluated separately from other
conditions within Policy Rules.
5.2. New Traffic in the Net
A few years ago a new application became available. This
application allowed users to have their system display news
items when their systems were otherwise idle. It became
very popular and became widely used in a very short period
of time. About the same time users discovered that their
network performance was not what they had come to expect,
especially connections from their corporate networks to the
Internet. After a few months, Network Administrators
learned that the firewalls were being overwhelmed by the
requests from internal systems to the servers for this new
application on the Internet. (The eventual solution was
for the companies to set up servers inside the firewall and
have internal users connect to these servers instead of
going through the firewall.) The initial reaction of the
IT staff in these companies was to tell users that use of
this application was not allowed until a solution was
found, but many users continued to use the application any-
way.
With Policy Management the IT staff could have immediately
limited or even shut down this kind of traffic by applying
some simple Policy Rules. For example:
if (traffic == NewsApp)
then
priority = Lowest
endif
In the above example 'Lowest' may be even lower than best
effort. Even with the internal servers for NewsApp, this
may be an appropriate policy since it is not a business
critical function.
The internal servers still need to get the news articles
(and advertising) to provide to internal users, so they
Mahon,Bernet,Herzog Expires March 2000 [Page 52]
Internet Draft Policy Requirements October 1999
need to go through the routers and firewalls connecting
with the Internet. For these Policy Targets there may be
Policy Rules in place to allow higher priority for internal
servers to access the NewsApp servers on the Internet. So
an Administrator may author and deploy the following on
Targets representing priority queuing on the routers send-
ing traffic to connections to the Internet, and on internal
interfaces on those routers which can receive traffic from
the Internet:
if (((traffic == NewsApp) &&
(trafficFrom InternalNewsAppServers) &&
(trafficTo !CorporateSubnet))
||
((trafficTo InternalNewsAppServers) &&
(TrafficFrom !CorporateSubnet)))
then
priority = Medium
endif
if (traffic == NewsApp)
then
priority = Lowest
endif
In this example the Policy will give NewsApp traffic
'Medium' priority if it is coming from or going to internal
servers. If the NewsApp traffic is not coming from the
internal NewsApp servers, it will go to the next rule which
gives the traffic 'Lowest' priority.
5.3. Traffic Classification With Packet Conditions
When determining how traffic should be treated conditions
such as what kind of traffic and who is generating (or
receiving) it are important factors. As discussed above,
some traffic will be more important than others as far as
why the network exists. In a company, traffic generated by
ERP (Enterprise Resource Planning) tools will be valuable,
while traffic generated by games will be less valuable.
Also illustrated above is the importance of knowing who is
causing the traffic. Combining these pieces of information
can enable the Administrator to further refine allocation
of shared network resources.
The use of IP Port values in the IP packet header allows
understanding what kind of traffic the packet represents
(as long as one of the Port values is a well-known or reg-
istered port). If traffic is going to a well-known port it
is going to a server for that type of application. If it
is going from a well-known port it is going to a client of
that application. Use of the srcIPport, destIPport, and
Mahon,Bernet,Herzog Expires March 2000 [Page 53]
Internet Draft Policy Requirements October 1999
IPport conditions as described earlier allow an Administra-
tor to classify traffic by type. (Other ways are described
in section 4.8.2.)
Use of addresses (or names) allows designation of individ-
ual machines, or groups of individual machines. Use of
subnet identifiers allows a shorter designation of groups
of people or systems involved in specific types of work
(e.g., Accounting, R&D, etc.).
To use the example from above of giving some (Medium) pri-
ority to Web traffic going to and from a Web server for the
Personnel department, we could express it as:
if ((IPport == 80) && (IPaddress == PersWebSrv))
then
priority = Medium
endif
Where the condition IPport matches the srcPort or destPort
field in the packet header, and IPaddress matches the
srcAddress or destAddress field in the packet header. The
administrator could author the same rule as follows
instead:
if (((destIPport == 80) && (destIPaddress == PersWebSrv))
||
(srcIPport == 80) && (srcIPaddress == PersWebSrv)))
then
priority = Medium
endif
The difference between the single matching statement and
two matching statements ORed together is that some Policy
Targets may not have a 'match either source or dest' fea-
ture, and could only match one (usually the Policy Consumer
would provide a mapping, though). Or an Administrator may
know that writing the Rule one way may be more efficient on
a particular type of device than the other way. This,
again, goes back to the need to understand some character-
istics of what is being managed, but not quite to the same
level of detail as currently required (e.g., the analogy
between high-level programming vs. assembler level pro-
gramming).
Similarly, traffic for a set of users can be identified, as
well as the application they are using. So an R&D group
using an NFS server on another LAN could use significant
network resources. Allowing them high quality of service
Mahon,Bernet,Herzog Expires March 2000 [Page 54]
Internet Draft Policy Requirements October 1999
limited to the NFS server could be done with the following:
if (((destIPport == sunrpc) &&
(srcIPsubnet == RandDsubnet) &&
(destIPaddr == NFSserver))
||
((srcIPport == sunrpc) &&
(srcIPaddr == NFSserver) &&
(destIPsubnet == RandDsubnet)))
then
priority = High
endif
In the first part of the Rule, the conditions are testing
for the destination Port for sunrpc (NFS), a source being
the R&D subnet, and the destination being the specified NFS
server. The second portion of the Rule checks for traffic
going the other way. Actually this Rule could be split
into two Rules, with each being assigned to different Pol-
icy Targets (as described in section 4.2).
+-------+--------+
| Int3 |
| | +----------+
|Router | |NFS Server|
R&D subnet | TargetB| | |
+----------+Int1 Int2+-----------+ |
| |TargetA | | |
+--+-----+ | | | |
|User PC | | | +----------+
| | | Int4 |
+--------+ +-------+--------+
Figure 8. A router with Policy Targets.
The Rule:
if ((destIPport == sunrpc) &&
(srcIPsubnet == RandDsubnet) &&
(destIPaddr == NFSserver))
then
priority = High
endif
only needs to be associated with TargetB (representing pri-
ority queuing on Interface2) since that is where traffic
Mahon,Bernet,Herzog Expires March 2000 [Page 55]
Internet Draft Policy Requirements October 1999
going to the subnet with the NFS server is controlled. The
other Rule:
if ((srcIPport == sunrpc) &&
(srcIPaddr == NFSserver) &&
(destIPsubnet == RandDsubnet))
then
priority = High
endif
would be associated with TargetA (representing priority
queuing on Interface1), which is where traffic entering the
R&D subnet is controlled.
By carefully authoring Policy Rules to contain the condi-
tions specific to the function(s) of a specific Policy Tar-
get, the Administrator can reduce the amount of processing
for each packet going through the the device. Some devices
have fewer resources than others. It can be easy to write
a Policy that can tax (or even overflow) a device's capa-
bilities. A well implemented Policy Consumer will detect
any problems with a Policy before deploying it on a Target
(if the problem wasn't detected in an automated way ear-
lier). If a Policy Consumer does detect such a problem it
will provide feedback to the Administrator through the Pol-
icy Management Repository.
The above Rules assume IP traffic. Traffic could also be
classified by EtherType, allowing other kinds of traffic
sharing the network to share the benefits of Policy.
At the edges of a network, it may be desirable to test for
the existing value of the IP Precedence bits in the IP TOS
byte and re-mark it if the necessary. A Rule performing
this check will also look at who the traffic is for (or
from) in order to determine what should be the correct
mark. For example:
if ((IPprecedence == 3) && (trafficTo CustomerX))
then
mark = 5
endif
5.4. Other Uses of Policy
Policy is not just used to give some traffic higher prior-
ity than others. As noted earlier, the network is a shared
resource. There will always be some traffic that is more
Mahon,Bernet,Herzog Expires March 2000 [Page 56]
Internet Draft Policy Requirements October 1999
important than other traffic, but even the most critical
traffic must still let other users use the network (other-
wise their should be a business need to separate that crit-
ical traffic onto a separate network).
Policy, therefore, can be used not just to assure that a
critical use has sufficient bandwidth, but can be used to
ensure that the critical traffic doesn't squeeze out the
rest of the traffic.
There are multiple methods of implementing this, but a com-
mon term is Rate Control.
The idea is to ensure the important traffic has enough
bandwidth to fulfill user needs, and if there is sufficient
extra bandwidth the traffic can also use that. But if
other traffic exists, the important traffic does have a
limit.
This concept may also be used to keep the less important
traffic from using too much bandwidth on the network. This
traffic could be allowed some space, but a limit is set to
keep it from interfering with other traffic.
5.5. Network Failure
This section discusses methods for dealing with a network
element failure which would require a different set of
policies to ensure the same (or at least a known) QoS dur-
ing the time the unusual situation exists.
The case of Policy handling a network failure requires fea-
tures for Policy Management not discussed earlier in this
draft. To address this scenario additional work on the
Policy Framework Core Information Model will be required.
An Administrator will establish Policies in the networked
environment (on routers, trafficshapers, switches, NICs, in
network stacks, on applications, etc.) in order to ensure
QoS according to the needs of the users of the networked
environment. If a failure of a network element (e.g.,
router) occurs traffic will need to follow other routes
through the network. If there were more than one path
through the network which were also provisioned to provide
the desired QoS that the failed route were configured to
route (i.e., more than one route were identically config-
ured relative to QoS and had sufficient bandwidth to take
up the slack from another path) there would be no need to
change the QoS configuration during the outage.
Unfortunately not all networks will be so adequately con-
figured, so a way to account for such failures is desir-
able. There are at least two ways to address this:
Mahon,Bernet,Herzog Expires March 2000 [Page 57]
Internet Draft Policy Requirements October 1999
1. Create condition types which deal with state
2. At the level of association between Policy and Policy
Target provide the ability to associate multiple Poli-
cies, and the association contains conditions which
cause deployment of the Policy to the Policy Tar-
get(s).
Scenario 1 allows for minimal change to the Core Informa-
tion Model. It would, however, cause Policies to be clut-
tered with Policy Rules (or condition lists within Policy
Rules) which only exist to handle contingencies. Such con-
ditions which deal with state likely would not be evaluated
on the Policy Targets (using existing devices as the
model), rather they would be evaluated on the Policy Con-
sumer.
An example of such a state condition could be:
condition type name: deviceDown
attributes: device address: 192.168.14.12
considered down if no contact after: 30
seconds
To enable such a condition, either the Policy Consumer
would need to poll each of the devices named in each such
condition, or would need to be notified by some third party
monitoring the condition of each device named in each pol-
icy condition.
Following Scenario 1 could cause Policies to contain more
Policy Rules (or more condition lists within Policy Rules)
to handle contingencies. This could also lead to more con-
ditions within the non-contingency portions since those
descriptions may not be applicable during periods requiring
contingency Policy information. Take or example, a Service
Provider with agreements with two customers A and B. Cus-
tomer A contracted for premium service under all circum-
stances. Customer B chose a lower cost service plan, which
contained a provision that under certain circumstances may
allow outage of service. Customer A's traffic usually
flows through one path on the network, while Customer B's
traffic flows through a portion with lower capacity. If
the path used for Customer A experiences a failure, the
contingency would be to route the traffic through the path
used for Customer B.
Because Customer B's contract allowed for outages, the Pol-
icy on that path allowed for only best effort for Customer
B during unusual circumstances. To handle this, using Sce-
nario 1 as the model, all of the condition lists relating
to Policy for QoS for Customer B would contain the state
condition(s) for unusual circumstances, but logically NOT'd
Mahon,Bernet,Herzog Expires March 2000 [Page 58]
Internet Draft Policy Requirements October 1999
so that if the unusual circumstances did not exist the rest
of the condition list would be evaluated:
Rule 1
if (((srcIPsubnet == CustomerB) ||
(destIPsubnet == CustomerB))
&&
( NOT deviceDown(routerX, 30 sec.) )
&&
( NOT deviceDown(routerY, 30 sec.) )
then
Priority=5
endif
Rule 2
if (((srcIPsubnet == CustomerA) ||
(destIPsubnet == CustomerA))
&&
(deviceDown(routerX, 30 sec.) ||
deviceDown(routerY, 30 sec.)))
then
Priority=5
endif
Such policy would work, but would be cumbersome to manage.
It also could reduce the ability to use the same Policy (or
individual Policy Rules) across multiple Policy Targets
since the 'deviceDown' conditions would be specific to cer-
tain portions of the network.
This scenario allows minimal change to the existing Core
Information Model definition, but changes operational char-
acteristics of components of the Policy Management System.
Scenario 2 would require a change to the Core Information
Model. On the association between a Policy and Policy Tar-
get, there would be conditional associations to other Poli-
cies. In the association would be conditions similar to
those described in Scenario 1, which describe conditions
under which the Policies for unusual circumstances would be
deployed. If the current indirect model for distribution
is followed, all of the policies would be placed in the
directory and the Policy Consumer would obtain all of the
policies, then change which Policy is deployed to the Pol-
icy Target on a status change as described in Scenario 1.
If a more direct model for Policy distribution were used,
then the Policy Management Application could be enabled to
change Policy distribution based on state not related to
traffic based conditions.
Mahon,Bernet,Herzog Expires March 2000 [Page 59]
Internet Draft Policy Requirements October 1999
Whether the Policy Management Application or the Policy
Consumer is involved, Scenario 2 allows for smaller and
more reusable 'non-contingency' Policies, while allowing an
easy mechanism for specifying Policies for unusual circum-
stances.
If the Policy Consumers were to be made responsible for
this contingency management, the Policy Consumers will nec-
essarily have greater requirements than have previously
been discussed. It would also introduce more policy that
would need to be deployed at all times. Having the Policy
Management Application handle the contingency deployment
centralizes the operations but may be less reliable in the
face of a network failure (e.g., if the link between the
Policy Management Application and a Policy Consumer were
unavailable).
5.6. The Role of Signaling in Policy Management
The usage cases described thus far are based on a top-down
provisioning approach. In this approach, policies are
applied by 'pushing' information from a PDP, to PEP. The
top-down approach can be combined with a signaling based
approach in which hosts signal information from the edges
of the network, to components of the policy management sys-
tem. This approach offers significant gains in manageabil-
ity of certain traffic. In this section, we discuss the
signaling approach and its benefits.
Note that for the purpose of this discussion, we assume
that RSVP signaling is used. However, much of the discus-
sion applies to any signaling protocol that carries policy
related information from hosts, along the data path to peer
hosts and that can be parsed by PEPs (and the asociated
PDPs) on the path. For example, IPSec can benefit from a
similar approach to policy.
5.6.1. Classification Assumptions Implicit in Top-Down
Provisioning
Top-down provisioning assumes that the policy management
system is endowed with certain knowledge about network
traffic. This includes knowledge of the following clas-
sification information:
1. Correlation of IP addresses to users - the account-
ing department example assumes that the policy man-
agement system knows a set of IP addresses (or an
IP subnet) that identifies all accounting users.
Mahon,Bernet,Herzog Expires March 2000 [Page 60]
Internet Draft Policy Requirements October 1999
2. Correlation of IP ports to applications - the Sun-
Rpc and NewsApp examples assume that the policy
management system knows a set of IP ports that
identifies these specific applications.
The classification information described may be hard to
come by. It is rarely the case that a specific group of
users can be identified by a single IP subnet. Account-
ing users may be distributed across multiple subnets.
Applications often use volatile ports. In the case of
IPSec, ports are encrypted and cannot be used at all to
identify applications. For these reasons, it is desir-
able to enable the policy management system to automati-
cally learn classification information that can be used
to correlate traffic from certain users and applications
with specific classification criteria.
5.6.2. Snooping Signaling Messages to Glean Classification
Information
Certain sending hosts will generate RSVP signaling mes-
sages describing the traffic that they are sending to
the network. These messages flow along the data path in
the network, carrying information such as:
1. Sending user ID
2. Sending application ID and sub-ID (e.g. print job
vs. time-critical transaction [APPID])
3. Classification criteria (in the form of source and
destination IP addresses and ports)
4. Volume of traffic sent (in the case of quantifiable
applications only)
This information (with the exception of the volume of
traffic sent) may be generated both for multimedia
applications (such as telephony and video applications)
as well as for less quantifiable applications such as
ERP applications.
In the case of IPSec encrypted traffic, hosts will pro-
vide an SPI [RFC2207] in the signaling messages, to be
used as classification criteria in lieu of IP ports.
Certain PEPs in the data path would be configured to
pass the relevant information from RSVP messages to
their PDPs. In this manner, policy management systems
Mahon,Bernet,Herzog Expires March 2000 [Page 61]
Internet Draft Policy Requirements October 1999
may passively snoop RSVP messages to automatically and
dynamically populate tables correlating classification
information to users and applications. This functional-
ity can significantly improve the reliability of classi-
fication information while reducing the administrative
burden associated with manually maintaining this infor-
mation. Of course, for many applications, hosts will not
generate signaling messages. For these applications it
will still be necessary to maintain classification
information using alternate approaches.
5.6.3. Offering High Quality Guarantees
The qualities of guarantees that can be made by a
strictly top-down provisioned system are limited by the
extent to which the system understands network traffic
patterns and traffic volumes. For example, assume that
an enterprise is interested in enabling IP teleconfer-
encing over an enterprise WAN. The top-down provisioned
approach to this would push the following rules to a
PEP:
if
(destIPport == IPtelephony)
then
(mark == 5)
endif
if
(mark == 5)
then
(priority = high)
endif
Assume that this rule is implemented on a PEP that
drives a T-1 WAN link. Assume further that, on the aver-
age, ten telephony sessions are in effect on the link at
any time, with an average per-session data rate of 64
Kbps. In this case, roughly 40% of the link's capacity
is yielded to telephony. Since the telephony traffic
gets high priority, it is assured relatively low latency
and a high quality service can be expected. However,
assume that on a particular day, there is high demand
for the telephony application and one-hundred sessions
are in progress. Since all telephony traffic is marked
for high priority by the policy management system, the
T-1 link will be significantly oversubscribed. In the
worse case, all other traffic traversing the link will
be starved and the telephony quality guarantees will be
worthless. In the best case, other traffic will be
Mahon,Bernet,Herzog Expires March 2000 [Page 62]
Internet Draft Policy Requirements October 1999
spared starvation, but the telephony guarantees will
still be worthless.
In this example, it would be preferable to mark traffic
associated with ninety of the one-hundred telephony ses-
sions as best-effort or low priority traffic, in so at
least assuring the quality of guarantees available to
the first ten sessions. The strict top-down approach
falls short in this regard. It is unable to distinguish
one telephony session's traffic from another.
Consider now that some of the telephony clients are not
directly on the remote end of the T-1 link. Instead,
these clients are served by a 64 Kbps link, which is in
turn served by the T-1 link. In this case, it would be
desirable to mark even fewer than ten sessions worth of
traffic for high priority, if those sessions traverse
the 64 Kbps link. As such, implementation of the marking
rule should depend on the path that potentially marked
traffic will take through the network.
The same considerations apply to any application requir-
ing high quality guarantees, such as most multi-media
applications. In short, high quality guarantees require
either considerable over-provisioning of the network or
the ability to apply some degree of topology aware
admission control as part of the policy management sys-
tem.
Applications that do not require high quality guarantees
do not strictly require topology awareness and admission
control from the policy management system. Nonetheless,
network management systems can use resources more effi-
ciently if they are more aware of traffic patterns and
are able to apply some form of granular admission con-
trol. Consider the following usage cases. The first
applies to quantitative applications requiring very high
quality guarantees. The second applies to qualitative
applications that benefit from some degree of topology
aware admission control, but do not require strict guar-
antees.
5.6.4. Signaled QoS Usage Case I - IP Telephony
Consider the following network topology:
Mahon,Bernet,Herzog Expires March 2000 [Page 63]
Internet Draft Policy Requirements October 1999
+-------+ +-------+ +-------+
| | | | | |
|host 1 | |host 2 | |host 3 |
| | | | | |
+-------+ +-------+ +-------+
| | |
| | |
+-----------+-----------+
|
|
|
+-----+------+
| |
| PEP 1 +---------+
| | |
| | | +---------+
+-----+------+ | | |
| | | |
| +----+ PDP |
| 1544kbps link | | |
| | | |
| | +---------+
+-----+------+ |
| | |
| PEP 2 | |
| +---------+
| |
+------------+
|
| 64kbps linl
|
+-----------+-----------+
| | |
| | |
+--+----+ +--+----+ +--+----+
| | | | | |
|host 4 | |host 5 | |host 6 |
| | | | | |
+-------+ +-------+ +-------+
Figure 9.
This is a simplified depiction of a corporate network.
PEP 1 is a router at the main corporate office. It
serves some large number of hosts via LAN interfaces
(represented on the top side of the router). It con-
nects the main corporate office to an overseas hub, rep-
resented by PEP 2. In turn, PEP 2 serves a number of
smaller remote offices, each of which serve some number
of clients. In the diagram, both PEPs are shown as
Mahon,Bernet,Herzog Expires March 2000 [Page 64]
Internet Draft Policy Requirements October 1999
connected to a single PDP, for simplicity's sake. How-
ever, the example could be just as well illustrated with
two separate PDPs. There is no direct communication
between the process in the PDP that serves PEP 1 and the
process that serves PEP 2.
Assume that the corporate network manager wishes to use
policy to enable the network for IP telephony service
using the diffserv EF codepoint. The PDP would then be
configured with the following rules:
allow .1 * LinkSpeed for signaled EF
allow .0 * LinkSpeed for non-signaled EF
if signaled
((ServiceType == GuaranteedService) &&
(LatencyBound <= 100 msec))
then
DSCP = EF
endif
There are two types of rules here. The first rule speci-
fies that only ten percent of the traffic traversing a
link can be marked for the EF PHB and that only signaled
traffic can be marked with the EF codepoint. This rule
is required in order to assure the integrity of the ser-
vice provided with the EF codepoint.
The second rule states that signaled traffic should be
marked EF iff it the signaling messages request the
Guaranteed Service and a latency bound less or equal to
100 msec.
These rules would operate as follows:
1. Hosts would generate signaling messages for IP
telephony sessions. These messages would carry the
following information:
a. Guaranteed Service
b. Latency <= 100 msec
c. Bandwidth = 6.4 Kbps
d. Source IP address/Destination IP
address = 1.2.3.4/5.6.7.8
e. Source IP port/Destination IP port = 5000/6000
f. user ID
g. application ID/sub application ID
Mahon,Bernet,Herzog Expires March 2000 [Page 65]
Internet Draft Policy Requirements October 1999
2. These signaling messages would flow from sender
towards receiver. Consider initially, a flow
transmitted by a host attached to PEP 1. The sig-
naling message arrives at PEP 1 and is forwarded to
the PDP.
3. The PDP notes that the request is for Guaranteed
Service and is for a latency bound less than 100
msec. Based on these parameters, and using the sec-
ond rule, it maps the request to the EF PHB.
4. The PDP then compares the requested bandwidth
against the maximum allowed EF bandwidth from the
first rule. Since the requested bandwidth does not
exceed the allowable EF commitment on the link, the
PDP can admit the request.
5. The PDP reduces the remaining allowable EF band-
width on the link by 6.4 Kbps.
6. The PDP then pushes the following rule to the PEP:
if((SrcAddr == 1.2.3.4) && (DestAddr == 5.6.7.8)
&& (SrcPort == 5000) && (DestPort == 6000))
then
mark = EF
endif
7. PEP 1 then forwards the signaling message on
towards PEP 2.
8. A similar process is repeated at PEP 2.
Note the following:
1. An additional request for a similar telephony ses-
sion from a host attached to PEP 1 would pass
admission control at PEP 1, but would fail at PEP 2
(since the required EF capacity would exceed the
ten percent limit on the 64 Kbps link from PEP 2).
In this case, the PDP would reject the request via
PEP 2. The EF marking rule would not be installed
for the second session and a signaling message
would be sent back towards PEP 1, indicating that
the admission control request failed. This message
would be directed to the PDP. The PDP would respond
by removing the marking rule for the second
Mahon,Bernet,Herzog Expires March 2000 [Page 66]
Internet Draft Policy Requirements October 1999
session.
2. The policy described is based purely on the
requested service type and the quantitative parame-
ters of the request. This policy does not actually
restrict the EF service to telephony but rather to
any application requiring low latency and Guaran-
teed Service. The network administrator could
expand the second policy rule to include user ID
and application IDs as qualifiers for EF marking.
3. It is implied that the signaling messages are RSVP
messages. RSVP policies can be applied to PATH mes-
sages (which transit from sender to receiver), RESV
messages (which result in the opposite direction)
or both. The choice of which messages policy should
be applied to is, in itself a policy decision. In
this example, policies are applied to PATH mes-
sages.
5.6.5. Signaled QoS Usage Case II - SAP
Consider the same network topology per the previous
example. Now assume that the network administrator
wishes to provide preferential service to mission criti-
cal SAP traffic traversing the corporate WAN links. The
administrator is assured (based on the rules installed
for the EF PHB) that at least ninety percent of each
link capacity will be available for best-effort traffic.
From experience, the administrator knows that 100 SAP
accounting sessions can be supported with the remaining
link capacity in PEP 1 and that 5 sessions can be sup-
ported with the remaining link capacity in PEP 2. With a
greater number of sessions, performance for all users
tends to degrade rapidly. The PDP would then be config-
ured with the following additional rules:
if (PEP == 1)
if ((APPID == SAP) &&
(SUB_APPID == ACCOUNTING))
allow 100 sessions for DSCP AF11
else
mark DSCP = 0
else if (PEP == 2)
if ((APPID == SAP) &&
(SUB_APPID == ACCOUNTING))
allow 5 sessions for DSCP AF11
else
mark DSCP = 0
Mahon,Bernet,Herzog Expires March 2000 [Page 67]
Internet Draft Policy Requirements October 1999
endif
These rules would operate as follows:
1. Hosts would generate signaling messages for SAP
sessions. These messages would carry the following
information:
a. Null Service (see [NULLSERVICE])
b. Latency <= XXX
c. Bandwidth = XXX
d. Source IP address/Destination IP
address = 2.2.2.2/3.3.3.3
e. Source IP port/Destination IP port = 4000/9000
f. user ID
g. application ID/sub application ID
2. These signaling messages would flow from sender
towards receiver. Consider initially, a flow
transmitted by a host attached to PEP 1. The sig-
naling message arrives at PEP 1 and is forwarded to
the PDP.
3. The PDP notes that the request is for the Null Ser-
vice. Therefore it uses the application ID and sub
application ID to identify the appropriate PHB, per
the policy rule.
4. The PDP then compares the number of currently
admitted SAP sessions against the limit of 100 ses-
sions. If 99 or fewer sessions have been admitted
so far, the PDP is able to admit the request.
5. The PDP decrements the number of remaining allow-
able sessions.
6. The PDP then pushes the following rule to the PEP:
if((SrcAddr == 2.2.2.2) &&
(DestAddr == 3.3.3.3) &&
(SrcPort == 4000) && (DestPort == 9000))
then
mark = AF11
endif
Mahon,Bernet,Herzog Expires March 2000 [Page 68]
Internet Draft Policy Requirements October 1999
7. The PDP then forwards the signaling message on
towards PEP 2.
8. A similar process is repeated at PEP 2.
Note the following:
1. Admission control, in this usage case, amounts to
deciding whether the signaled traffic is entitled
to a DSCP other than for best-effort. PDPs may
cause a DCLASS object to be appended to RSVP RESV
signaling messages [DCLASS] specifying the DSCP
allowed by the PDP. In this manner, it is possible
to coordinate the marking function among multiple
potential marking PEPs, along a flow's data path.
2. PDPs may also consider user ID in determining which
flows are entitled to which DSCP marks. In this
manner, a policy could reserve high priority usage
of a certain application for specific users of the
application.
5.7. Policy in an Engineered Network
Using marks on IP packets (using the DS field, IPv4 TOS
field, or 802.1p) allows a network element (e.g., router)
to quickly classify a packet and give it a particular
treatment. Such a usage will require two related but pos-
sibly different actions: configuration of the marking mech-
anism and provisioning of the network to support the mean-
ing of the marks. Both of these actions can be performed
via Policy Based Management.
An IT administrator would configure (or provision) network
elements to support desired behaviors by authoring configu-
ration policies. The actions would be the desired behav-
iors, and the conditions may only include time and date
information (specifying when the behaviors are to be sup-
ported, or even what the behaviors mean at a given time).
For example, if traffic with DSCP AF11 were only to be sup-
ported during the last 10 days of the month, then a config-
uration policy rule could be constructed as follows:
if (dayOfMonth in last10days) && (DSCP == AF11)
then
specify queuing behavior 1
endif
Mahon,Bernet,Herzog Expires March 2000 [Page 69]
Internet Draft Policy Requirements October 1999
and for other times of the month the behavior for DSCP AF11
could be specified differently with the following rule:
if (dayOfMonth not in last10days) && (DSCP == AF11)
then
specify queuing behavior 2
endif
It should be noted that each policy rule is self contained,
so that when it is combined with other policy rules to form
a policy the appropriate actions are taken based on how
well the event (e.g., a packet waiting to be queued)
matches the conditions of the rule, and the rule's place-
ment in the policy. In other words, unless the conditions
of a rule are satisfied the rule has no effect, and will
not affecte the ability of other rules in the same policy
to be acted on. A default behavior for a given action type
must be defined such that if the none of the rules within a
policy match the event, a known behavior is acted on. In
the case of QoS usage policies, the default action will be
best effort.
These configuration policies will be distributed to the
appropriate interfaces to support desired behaviors on the
network.
Configuring what marks are placed on what traffic is also
specified via policy. The IT administrator will author
policy rules which identify the type of traffic in the con-
ditions and the mark that should be placed on matching
packets in the action portion of the policy rule. For
example, on an end node that will mark outbound traffic,
the following rules may be used to mark traffic to achieve
desired behavior in a network that is already appropriately
configured to recognize the marks in the packet:
if (Application == HTTP) &&
(destIPaddress in AccountingGroup)
DSCP=AF31
endif
if (Application == telnet) &&
(destIPaddress in AccountingGroup)
DSCP=AF11
endif
if (Application == accountingtool)
DSCP=AF12
endif
Mahon,Bernet,Herzog Expires March 2000 [Page 70]
Internet Draft Policy Requirements October 1999
The default would be not to mark the packet, thus resulting
in best effort, unless network elements were provided with
policies which identified the traffic through means other
than through its mark (e.g., IP address or port informa-
tion).
A key aspect of such marking is that if end-node marking is
to be used, it must be controlled by a centralized manage-
ment tool, otherwise a clever (or malicious) user could
modify the packet markings to always specify the best
behavior, thus bypassing the manager's efforts.
5.8. Combination of Policies
Combining policy primitives creates a complete policy set.
For example, an enterprise network may include multiple
types of applications (VoIP, FTP, HTTP, ERP, Sales and
"other"). VoIP and Video are quantitative application that
can quantify their traffic as well as the QoS requirements.
FTP is a bulk application (cares only about the total
start-to-finish transfer time) . and ERP and Sales are
qualitative applications (mission critical).
This enterprise has three types of employees: executive,
sales and administrative.
The IT manager of the enterprise has a general goal to pro-
vide all these applications and users with their required
QoS, except for "other" which get the leftovers, but with a
certain minimum:
Rule 1: Other is basically best effort
If
Application=Other
Then
Priority = 0
Rule 2: Executive get better service for their
"other" traffic
If
Application=Other and User = Executive
Then
Priority = 1
Rule 3: VoIP
If
Application = VoIP and
(User = executive or User = Sales)
Mahon,Bernet,Herzog Expires March 2000 [Page 71]
Internet Draft Policy Requirements October 1999
Then
One-Way-Delay < 400ms
MAX_BW < 64Kbps ; per call
MAX_AGGR_BW < 512Kbps ; for all calls
Rule 4:
If
Application = FTP and User=Administrative
Then
Priority = (0..3) based on the gap of reaching
transfer time goal.
(Some exponential function ;-)
Rule 5:
If
Application = HTTP and User = Executive
Then
Up to 256Kbps: Priority = 3
Up to 0.5Mbps: Priority = 2
Else : Priority = 1
Rule 6:
If
Application = ERP or Application = Sales
Then
Priority = 3
Rule 7:
If
Application = ERP or Application = Sales
ToD = 9am-12pm
Then
Priority = 5
Rule 8: Provisioning for classes
If
Role = CoreRouter+DiffServ+T1
Then
Provision Classes using CBQ or
Equivalent (Using DiffServ AF?)
Priority 5: 15%
Priority 4: 20%
Priority 3: 20%
Priority 2: 35%
Priority 1: 5% ;(Anti-Starvation)
Priority 0: 5% ;(Anti-Starvation)
Rule 9: Marking for classes
Mahon,Bernet,Herzog Expires March 2000 [Page 72]
Internet Draft Policy Requirements October 1999
If
Role = EdgeRouter+EdgeInteface+DiffServ
Then
Mark DCSP as:
Priority 5: AF11
Priority 4: AF12
Priority 3: AF13
Priority 2: AF21
Priority 1: 1
Priority 0: 0
This policy indicates several requirements:
Resolution of User and Application into IP/Ports (Abstraction)
2. Ability to handle conflicts:
- Rule 6 and 7 conflict
3. Ability to perform admission control (rule 3) on both
individual instances as well as their aggregate.
4. Topology awareness. Rules 3 and 8 have per link decisions
to make (guaranteeing voice-RSVP style, and guaranteeing
classes with at least xx% of any network link).
5. Ability to respond to outsourcing (rule 3) and
provisioning (other rules) in a timely manner
6. Interpreting instructions for multiple devices (policy
doesn't mention individual devices).
7. Support Roles (rules 8,9)
6. Security Considerations
For QoS related Policy, the security needs of a Policy Manage-
ment System require authentication at a minimum.
The Policy Management System contains components which send
messages and read and write data.
The interactions which involve writing of data MUST ensure
authentication of both parties. In other words, when a Policy
Consumer connects to a Policy Management Repository, in which
the Policy Consumer writes status and configuration informa-
tion to the Policy Management Repository, the Policy Consumer
must authenticate itself to the Policy Management Repository,
and vice-versa. The reason for this is that either end of the
communication could be false. If a true Policy Consumer wrote
data to a false Policy Management Repository, the Administra-
tor will not see the true data. If a false Policy Consumer
wrote data to a true Policy Management Repository, the Admin-
istrator will see false data. Either situation means that the
Administrator does not know the true state of Policy configu-
ration in the networked environment. Similar requirements
exist for the connection of the Policy UI to the Policy Repos-
itory and Policy Management Repository.
Mahon,Bernet,Herzog Expires March 2000 [Page 73]
Internet Draft Policy Requirements October 1999
When Policy is used for security purposes, it MUST be
encrypted when being transported over the network.
Repositories must be as secure as reasonably possible. If a
Repository resides on a general purpose host, access to the
Repository data should be controlled and monitored. If the
data cannot be so secured, other means, such as encryption of
data in the repository, or other methods ensuring integrity
should be employed.
7. Summary
Policy Based Management is not just a buzz word, or a solution
looking for a problem. There is a genuine need for allowing
network Administrators to be more effective by managing the
network as a collective, not as a collection of individual
devices each requiring a separate set of knowledge.
Today's tools allow Administrators to configure the devices
which enable traffic, but the view they present to Administra-
tors is limited, and the management of a device is the focus
of the activities with those tools.
Policy information, as described in [INFOMODEL] allows that
abstraction, but additional information is needed to make Pol-
icy useful. Information such as the targets of Policy,
attributes about those targets, and the association between
Policy and the targets must be further defined.
Additionally, the actual architecture of a Policy Management
System must be further defined in order to allow multiple ven-
dors to have interoperable implementations. The details of
such an architecture include making the Policy information
available in a timely manner, and providing the Administrator
(and, in the future, tools) with information about the charac-
teristics of Policy Targets in order to allow validation of
Policy and conflict detection. Additionally, Administrators
need to know if Policy deployment was successful in order to
know if the network will work as expected so they don't have
to wait for users of the network to tell them there's a prob-
lem.
Key questions have now been discussed in a document. Such
questions as "What protocols should be used?" and the role of
the Policy Consumer and Policy Consumer are covered in detail
in this document.
New requirements not already documented elsewhere are also
documented here, such as security, versioning of Policy Data,
and timely delivery of Policy Data.
To finish the summation of this document, below are bullet
lists of the requirements of a Policy Management System. The
Mahon,Bernet,Herzog Expires March 2000 [Page 74]
Internet Draft Policy Requirements October 1999
items marked with an asterisk are yet to be fully defined.
Policy Data
- Policy, contains one or more Rules
- Rule, contains one or more Actions and one or more condi-
tion lists
- Action, schema definition exists, but few proposals for
types *
- Condition list, contains one or more conditions
- Condition, schema definition exists, but few proposals
for types *
- Policy Target *, contains attributes:
- name
- properties relative to policies supported
- status
- Policy Consumer *
- Association between Policy and Policy Target * (currently
called 'Jurisdiction' or 'Role', but not well defined)
Policy Architecture Features
- Policy repository communication (e.g., LDAP)
- Policy repository (may be settled by above question,
e.g., if communication is LDAP)
- Notification to Policy Consumer of new/changed policy *
- Versioning of Policy Data *
- Status reporting mechanism from Policy Consumer *
8. Intellectual Property
The IETF takes no position regarding the validity or scope of
any intellectual property or other rights that might be
claimed to pertain to the implementation or use of the tech-
nology described in this document or the extent to which any
license under such rights might or might not be available;
neither does it represent that it has made any effort to iden-
tify any such rights. Information on the IETF's procedures
Mahon,Bernet,Herzog Expires March 2000 [Page 75]
Internet Draft Policy Requirements October 1999
with respect to rights in standards-track and standards-
related documentation can be found in BCP-11.
Copies of claims of rights made available for publication and
any assurances of licenses to be made available, or the result
of an attempt made to obtain a general license or permission
for the use of such proprietary rights by implementers or
users of this specification can be obtained from the IETF Sec-
retariat.
The IETF invites any interested party to bring to its atten-
tion any copyrights, patents or patent applications, or other
proprietary rights which may cover technology that may be
required to practice this standard. Please address the infor-
mation to the IETF Executive Director.
9. References
[TERMS] S. Bradner, "Key words for use in RFCs to
Indicate Requirement Levels", Internet RFC
2119, March 1997.
[TERMINOLOGY] J. Strassner, E. Ellesson, "Terminology for
describing network policy and services",
Internet Draft draft-strassner-policy-
terms-01.txt, February 1999.
[INFOMODEL] B. Moore, E. Ellesson, J. Strassner, "Policy
Framework Core Information Model", Internet
Draft draft-ietf-policy-core-info-
model-00.txt, June 1999.
[POLFRAME] M. Stevens, W. Weiss, H. Mahon, B. Moore, J.
Strassner, G. Waters, A. Westerinen, J.
Wheeler, "Policy Framework", Internet Draft
draft-ietf-policy-framework-00.txt, September
1999.
[COPSFRAME] R. Yavatkar, D. Pendarakis, R. Guerin, "A
Framework for Policy-based Admission Control",
Internet Draft draft-ietf-rap-
framework-03.txt, April 1999.
[COPS] J. Boyle, R. Cohen, D. Durham, S. Herzog, R.
Rajan, A. Sastry, "The COPS (Common Open Pol-
icy Service) Protocol", Internet Draft draft-
Mahon,Bernet,Herzog Expires March 2000 [Page 76]
Internet Draft Policy Requirements October 1999
ietf-rap-cops-07.txt, August 16, 1999.
[APPID] Y. Bernet, R. Pabbati, "Application and Sub
Application Identity Policy Element for Use
with RSVP", Internet Draft draft-ietf-rap-
appid-00.txt, February, 1999.
[NULLSERVICE] Y. Bernet, A. Smith, B. Davie, "Specification
of the Null Service Type", Internet Draft
draft-ietf-issll-nullservice-00.txt, September
1999.
10. Acknowledgements
Special thanks to Mark Stevens, Bob Moore, Andrea Westerinen,
Avri Doria, Cheh Goh, Rick Roeling, and Brian O'Keefe for
input and feedback during the development of this draft.
Thanks also go to Ed Ellesson and Bert Wijnan for their guid-
ance on what should be discussed in this document.
11. Author Information
Hugh Mahon
Hewlett-Packard Co.
3404 East Harmony Road, MS A2
Fort Collins, CO 80528-9599
Phone: +1 970 898 2487
EMail: hugh_mahon@hp.com
Yoram Bernet
Microsoft
1 Microsoft Way
Redmond, WA 98052
USA
phone: +1 206 936 9568
email: yoramb@microsoft.com
Shai Herzog
IPHighwayw
Parker Plaza, 16th Floor
400 Kelby St. Fort-Lee NJ 07024
201.585.0800
herzog@iphighway.com
Mahon,Bernet,Herzog Expires March 2000 [Page 77]
Internet Draft Policy Requirements October 1999
12. Full Copyright Statement
Copyright (C) The Internet Society (date). All Rights
Reserved.
This document and translations of it may be copied and fur-
nished to others, and derivative works that comment on or oth-
erwise explain it or assist in its implementation may be pre-
pared, copied, published and distributed, in whole or in part,
without restriction of any kind, provided that the above copy-
right notice and this paragraph are included on all such
copies and derivative works. However, this document itself
may not be modified in any way, such as by removing the copy-
right notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other
than English.
The limited permissions granted above are perpetual and will
not be revoked by the Internet Society or its successors or
assigns.
This document and the information contained herein is provided
on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE
USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE."
Mahon,Bernet,Herzog Expires March 2000 [Page 78]
Internet Draft Policy Requirements October 1999
1. Introduction ......................................... 3
2. A Simple Policy Management System .................... 6
2.1 The Policy Consumer and Policy Target ............... 8
3. Policy Management in Action .......................... 10
3.1 Information Visible to the Administrator ............ 11
3.2 Policy Deployment Actions ........................... 12
3.2.1 Policy Configuration Usage ........................ 12
3.2.2 Results of Policy Configuration ................... 14
3.3 Alternate Architectures ............................. 14
3.3.1 Policy Status and Configuration Information ....... 14
3.3.2 Policy Notification ............................... 16
4. General Policy Management Issues ..................... 18
4.1 Provisioned vs. Signaled QoS Mechanisms ............. 18
4.2 Policy assignment ................................... 20
4.2.1 Policy applicability .............................. 22
4.3 Policy Operation .................................... 22
4.3.1 Policy Size ....................................... 23
4.3.2 Policy Capability ................................. 24
4.4 Policy Conflicts .................................... 25
4.4.1 Conflict Between Two Rules Within a Policy ........ 25
4.4.2 Conflicts Between Actions Within a Rule ........... 26
4.5 Time aspects of policy .............................. 26
4.6 Scalability ......................................... 27
4.6.1 Scalability and Policy Targets .................... 27
4.6.2 Scalability and Policy Consumers .................. 28
4.6.3 Scalability and the Repositories .................. 28
4.6.4 Scalability and the Policy Management Applica-
tion
............................................... 29
4.7 Administration of the Policy Management System ...... 29
4.7.1 Policy UI ......................................... 31
4.7.2 Policy Conflict Detection ......................... 31
4.7.3 Policy Repository ................................. 31
4.7.4 Policy Management Repository ...................... 32
4.7.5 Policy Consumers .................................. 32
4.7.6 Policy Targets .................................... 32
4.8 Policy Conditions ................................... 32
4.8.1 Time/Date Conditions .............................. 32
4.8.2 Packet Conditions ................................. 33
4.9 Implementation examples ............................. 34
4.9.1 LDAP .............................................. 34
4.9.2 SNMP .............................................. 37
4.9.3 COPS .............................................. 39
4.9.4 HTTP .............................................. 40
4.10 Policy Interpretation .............................. 41
4.11 Policy information ................................. 42
5. Usage Cases .......................................... 42
5.1 An Accounting Department Example .................... 43
5.1.1 Policy Consumer For an Existing (Legacy) Device
.................................................... 48
5.1.2 Policy Consumer for a Policy Aware Device ......... 51
5.1.3 Other Policy Consumer Uses ........................ 51
5.2 New Traffic in the Net .............................. 52
Mahon,Bernet,Herzog Expires March 2000 [Page 79]
Internet Draft Policy Requirements October 1999
5.3 Traffic Classification With Packet Conditions ....... 53
5.4 Other Uses of Policy ................................ 56
5.5 Network Failure ..................................... 57
5.6 The Role of Signaling in Policy Management .......... 60
5.6.1 Classification Assumptions Implicit in Top-Down
Provisioning ....................................... 60
5.6.2 Snooping Signaling Messages to Glean Classifica-
tion Information ................................... 61
5.6.3 Offering High Quality Guarantees .................. 62
5.6.4 Signaled QoS Usage Case I - IP Telephony .......... 63
5.6.5 Signaled QoS Usage Case II - SAP .................. 67
5.7 Policy in an Engineered Network ..................... 69
5.8 Combination of Policies ............................. 71
6. Security Considerations .............................. 73
7. Summary .............................................. 74
8. Intellectual Property ................................ 75
9. References ........................................... 76
10 Acknowledgements ..................................... 77
11. Author Information .................................. 77
12. Full Copyright Statement ............................ 78
Mahon,Bernet,Herzog Expires March 2000 [Page 80]
| PAFTECH AB 2003-2026 | 2026-04-23 20:01:48 |