Internet DRAFT - draft-blight-gen-poli-arch
draft-blight-gen-poli-arch
HTTP/1.1 200 OK
Date: Mon, 08 Apr 2002 22:54:07 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Thu, 04 Mar 1999 21:35:08 GMT
ETag: "2e6fba-9ed3-36defc8c"
Accept-Ranges: bytes
Content-Length: 40659
Connection: close
Content-Type: text/plain
Internet Engineering Task Force David C Blight
INTERNET DRAFT Charley Liu
17 February 1999 Fujitsu Labs of America
Generalized Policy Framework Architecture
draft-blight-gen-poli-arch-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with all provi-
sions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task Force
(IETF), its areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months and may
be updated, replaced, or obsoleted by other documents at any time. It is in-
appropriate 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
Out goal is describe a simple policy framework (or architecture) which is both
practical to implement, and easy to extend. Our framework is driven by the
information which needs to be exchanged, and the communication system required
to implement it.
We view policies as a specification for network management systems, and have
constructed our framework based on that assumption. We forces us to consider
a more general architecture, than one based on QoS assumptions alone.
1. Introduction
Policy Based Networking has received a lot of attention recently (most of it
has been hype). The basic idea is simple, specify a set of rules which govern
the operation of network. What a policy is, has never been consistently de-
fined, mostly because everyone has preconceived ideas about what the policies
are. This framework is general enough to handle almost all kinds of policies,
independent of their schema.
Almost every company that makes (or announces it is making) an internet device,
appliance, network management system has at some point publicly announced their
Policy strategy, and promised that it will solve all the InternetÆs problems.
Despite the promises, policies are a very powerful tools, if used in a con-
sistent manner.
The Internet (and Internet Protocol based networks) have lots of problems. Se-
curity, reliability, performance, and Quality of service are just of few of
them. We envision a policy based framework which will serve as a consistent
framework for developing solutions to all these problems. This internet draft
is intended to show one possible solution to the implementing Policy based
management.
2. Assumptions
The internet (and IP based networks) are complex, and everyone wants something
different from them. Lets assume that a policy is the specification for some
aspect of a network. Multiple policies will be specified covering many of the
goals for the network. These policies will potentially come from different
sources (network managers, other management systems, synthesized from other
policies). The policies may also be applied to the network in different manners
(simultaneously, sequentially, to specific devices, or at specific times). Our
framework must be robust enough to meet these different requirements.
Our basic assumption is that policies are specifications for network management
systems. Policies within a network can take two forms, those that are specific
for one or more devices, and directly implementable (A policy that specifies
router configuration), or they may be network centric (web applications should
receive a specified QoS guarantee). In either case, the policies are specifi-
cations, and are interpreted by network management system, service management
systems, or device management systems. In order for policies to be more useful
the current techniques for network or device configuration, we must standardize
policy specifications to that they are vendor independent. This implies that
they must assume a generalized view of common network devices, services, or
components.
No single network management system can manage all aspects of a typical IP
based networks, including layers lower than IP (ATM, Ethernet, SONET, POTS,
etc.), and layers above IP (TCP, applications, services, business). It would
be too complex to construct a general purpose network manager that knows about
all applications, protocols, networking technologies. A more reasonable ap-
proach is to allow specialized network management systems to control appropri-
ate portions of the network, and allow communications between network
management systems to achieve consistent management for all aspects of a net-
work.
In order to allow network management system to communicate, we must do the
following:
1) Common information model.
2) Simple communication system.
2.1 Common Information Model
If everyone models information consistently, life becomes easier. Fortunately
we have the Common Information Model (from the DMTF), which has standardized
a good, flexible, information model. As a bonus, most commercial network man-
agement systems are supporting this model.
With this in mind we should view our policy framework supporting a CIM based
schema.An LDAP based schema is strictly a mapping into data structures con-
sistent with LDAP. This is consistent with the schema currently being developed
by Policy Working Group.
2.2 Simple communication system
The required communication system must do the following
1) Reliably send messages from one component to another
2) Support component interaction models (e.g. client/server, publish sub-
scribe)
Most often we implement such a communication system by developing a layered
set of protocols, usually like applications protocol/TCP/IP. The most impor-
tant feature is that the protocols should not be more constrictive than the
data model being communicated.
LDAP sucks. or maybe a better way to phrase it is, LDAP was designed for one
specific purpose, and is not suited for all purposes. Its weak in security,
data modelling, and many other things. While there are many attempts to make
it better, this will likely take a long time, and the result will likely be
very kludgy. Reality is that LDAP is standardized, and implementations exist.
Lets view it as the lowest common denominator in a system. We use it for in-
teroperability, when its suitable, but lets not go overboard with it.
Everything must be kept simple. Simple is implementable, extendable, reusable,
and consistent. Simple if good.
3. Architecture
Our architecture consists of four entities:
Management Consoles(MS): this is where policies are entered into the system.
Policy Management System(PMS): this is the part of the system which does
all the work. The PMS is responsible for interpreting the policies that are
entered, and issuing instructions for network components.This unit will re-
ceive policies (in standardized encoding/schemas) and interpret the semantics
of the policies, and issue commands for network components (these commands are
also policies, just more specific)
Policy Interpreter: The average internet device today does not know about
policies (since we have not standardized them yet). The policy interpreter
(similar to the one in PMS) interprets the policies, and issues machine spe-
cific instructions (via COPS, SNMP, or any other protocol).
Policy Enabled Device: Any internet device, application, service, or appli-
ance which has a built in Policy Interpreter.
Policy Enabled Virtual Component: Not all components in a network are real,
some are actually multiple components acting a single component. For example:
a leased line between two routers is actually a large network belonging to a
carrier/ISP. By allowing details of network to be abstracted by a single com-
ponent, we allow ourselves to construct networks which can be managed by mul-
tiple management systems. When we send a policy to a Virtual component, we are
actually sending a policy to the PMS of a network.Normally the internals of a
virtual components would be beyond the management capabilities of the external
PMS.
+---------------+ +---------------+ +-----------------+
| | | | | |
| Mgmt Console | | Mgmt Console | | Policy Mgmt Sys |
| | | | | |
+---------------+ +---------------+ +-----------------+
\ | /
\ | /
+-----------------+
| |
| Policy Mgmt Sys |
| |
+-----------------+
/ | \
/ | \
/ | \ +------------------+
+----------------+ +----------------+ \ +------------------+ |
+---------------+ | +---------------+ | +-----------------+ | |
| | | | | | | | | |
| Policy | | |Policy Enabled | | | Policy Enabled | | |
| Interpretor(s)| | | Device(s) | | | Virtual Devices | |-+
| |--+ | |-+ | |--+
+---------------+ +---------------+ +-----------------+
| | |
| | |
| | |
\/ \/ \/
Legacy Devices
Figure 1 : PBN Architecture
A Policy Enabled Device, is simply a Device which can communicate with the
Policy management System, and contains an interpreter
+-----------------------+
| +---------------+ |
| | | |
| | Policy | |
| | Interpreter | |
| | | |
| +---------------+ |
| | |
| | |
| | |
| \/ |
| Device |
+-----------------------+
Figure 2 - policy enabled device
A Virtual Policy Enabled Component (or Device), is an abstract component which
represents part of a network under the control of a different management sys-
tem. To the policy management system, this portion of the network looks like
a single device.
+-----------------------+
| +---------------+ |
| | | |
| | Policy | |
| | mgmt sys | |
| | | |
| +---------------+ |
| | |
| | |
| | |
| \/ |
| Devices |
+-----------------------+
Figure 3 : Virtual policy Enabled Device
A multi-layer managed network could look something like
+---------------+ +---------------+ +-----------------+
| | | | | |
| Mgmt Console | | Mgmt Console | | Mgmt Console |
| | | | | |
+---------------+ +---------------+ +-----------------+
\ | /
\ | /
+-----------------+
| |
| Policy Mgmt Sys |
/ | | \
/ +-----------------+ \
/ / | | \ \
/ / | | \ \
+---------------+ +---------------+ +-----------------+
+---------------+ | +---------------+ | +-----------------+|
| | | | | | | ||
| Policy Enabled| | |Policy Mgmt | | | Policy Enabled ||
| Devices |-+ | Sys |-+ | Devices |+
| | | | | |
+---------------+ +---------------+ +-----------------+
/ | \
/ | \
+---------------+ +---------------+ +-----------------+
+---------------+ | +---------------+ | +-----------------+|
| | | | | | | ||
| Policy Enabled| | |Policy Mgmt | | | Policy Enabled ||
| Devices |-+ | Sys |-+ | Devices |+
| | | | | |
+---------------+ +---------------+ +-----------------+
Figure 4 : MultiLayer Architecture
4. Policy Management System
Lets examine what is needed of the policy management system.
4.1 Multiple console support
Each management system is logically centralized, but supports multiple manage-
ment consoles to accommodate multiple managers on a network and/or to present
different views of the network. Each user should have an associated set of
access permissions to different information. WBEM is the likely protocol to be
used for access.Inputs from users managers) should be specified in terms of
policies (although through a graphics front end).
An important part of this framework is that management systems may be tied
together through the same interface. Any other management system should appear
to the management system as a management console. Instructions from other man-
agement systems should be in the form of policies, and information can be re-
trieved by WBEM.
4.2 Multiple network Views
An important extension to supporting multiple consoles is to support multiple
network views. There is always more than one way to look at a network. We may
be interested in topology, physical assets, network traffic, or network state.
Each console can potential show a different view of the network. Each network
view will also be subjected to access control. Not all users/management systems
will have the same permission to view all levels of details.
One important network view is the virtual device view, in which the network
(or subset of) is make to look like a single device to the management console
(or other management system). This is critical in making the management systems
scalable and interoperable.
For example, consider an ATM based carrier network which is providing a VPN
for an enterprise. The external view of this network that the carrier network
management system will export to the enterprise is one of a single link, with
associated properties corresponding to its SLA or measured characteristics.
Policies from the enterprise network PMS to the carrier PMS may include
Security policies
QoS Policies
Reliability Policies
Likewise the enterprise could request network information from the carrier.
The carrier does not want to inform the enterprise of any other VPNs than its
own, and of the internals of the carrier network. For this purpose, the carrier
will create a special CIM model of the single link view of the VPN, and make
it available to the enterprise PMS (through the communication system).
5. Communication requirements
We desire a simple communication system. Before describing some basic messages
which may be sent, we will first discuss the basic needs. Messages will be
grouped into three categories:
1) Identification
2) Request/Response
3) Notifications
Identification is used to authenticate all parties in a communications.
Request/Response messages are used to query information or submit policies. A
Management console (or Management system), needs to be able request available
views of the network, and to submit policies. This communication follows the
client/server model. We could conceivably get by with two commands, get overall
view and set policy, but additional messages are included for efficiency (to
get more specific information, and reduce receiver filtering/processing).
Notifications are asynchronous messages used to notify a management console or
PMS of a policy violation. Submission of a policy is viewed as a subscription
to events associated with the policy.
5.1 Register
The register message is used to identify a network component to the policy
management system. A Register message is returned to the requester, with an
attribute indicating error conditions. This message should also contain or in-
itiate a sequence of messages to authenticate both parties. The register com-
mand leaves an open connection through which further commands may be sent.
5.2 Get View Capability
The message requests a list of network views which the originator is allowed
to request.
5.3 View List
This message is generated in response to a Get_View_Capability message. This
message will contain a list of views that the PMS supports, and is authorized
to reveal to the requester.
5.4 Get Policy Capability
This message will request a list of policies types that the policy management
system supports. This information will be used by network management consoles
and other network management system to identify what types of policies are
appropriate for the PMS.
5.5 Policy List
This message is generated in response to a Get_Policy_Capability message. This
message will contain a list of policy schemas that the PMS supports.
5.6 Get View
This message requests a network information model view be made available to
the requester. It most specify one of the available view types.
5.7 Return View
This message is generated in response to a get_View message. It will contain
a information model/schema view of the network.
5.6 Apply policy
This message contains a policy, which should be administered by the PMS.it will
contain a policy ID, which may be used to identify this policy in future trans-
actions.
5.7 Modify Policy
This message is used to change the parameters of a policy. It must contain an
ID of a valid policy. This command can be used to rescind policies.
5.8 Policy Status
This message is generated in response to a Apply_policy or Modify_policy mes-
sage. It will contain sufficient information to identify whether the policy
(or modification) was accepted by the PMS.
5.9 Events
This message is used to single network components of policy violations.
5.10 Multicast Communication
Multicast technology could be used to improve the efficiency of the this frame-
work, although it is not strictly required. The multicast model is none the
less useful for showing the conceptual communication model. if multicast is
not available, the same functionality may be provided by the PMS (with mul-
tiple point to point connections).
Our communication architecture adopts IP multicast and
the concept of self-organization. IP multicast is used to improve the effi-
ciency
of one-to-many communication; and the self-organization concept is used to
improve system robustness in the presence of network dynamics.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. +---------+ .
. | Console | Bootstrap Group .
. +---------+ .
. x x x x x x x x x|x x x x x x x x x x x x x x x x x x x x x x x x x .
. x | x .
. x | All-PMS Group x .
. x | x .
. x # # # # # # # | # # # # # # # x .
. x # V # # # # # # # # # # # # # # # # x .
. x # +-------------+ # # +-------------+ # x .
. x # | MPS A | < ----------- > | PMS B | # x .
. x # | Directory | # # | Directory | # x .
. x # +-------------+ # # +-------------+ # x .
. x # ^ # # ^ # x .
. x x#x x x x x x x|x x x x x x x#x x#x x x x x x x|x x x x x x x#x x .
. # V # # V # .
. # +-----------------+ # # +-----------------+ # .
. # +-----------------+ | # # +-----------------+ | # .
. # +-----------------+ |-+ # # +-----------------+ |--+ # .
. # +-----------------+ |-+ # # | Network Devices |--+ # .
. # | Network Devices |-+ # # +-----------------+ # .
. # +-----------------+ # # # .
. # # # Designated Group B # .
. # Designated Group A # # # .
. # # # # # # # # # # # # # # # # # .
. # # # # # # # # # # # # # # # .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Figure 5-2: Multicast Group Model
As shown in Figure 2, there are 3 types of multicast groups: the bootstrap
group, the all-directory group and the designated groups. The bootstrap group
is
used for the policy-aware devices to discover available policy directories;
the
all-directory group is used to exchange characteristics and request for
missing
policies among directories; and the designated group is associated with
individual directories, which is used to disseminate policies to a set of
network devices.
5.10.1 Bootstrap Group
Initially, the membership of the bootstrap group consists of all policy
directories. Each policy directory periodically multicasts solicitation
messages. These messages contain information for policy-aware network devices
to
determine their designated directories. When a new network device is brought
on-
line, it joins the bootstrap group and receives solicitation messages from
directories. It then selects a directory as it designated directory and joins
the corresponding designated group. The device can leave the bootstrap group
or
optionally stays in the group to discover better suitable directory.
There are several ways to select a designated group. A device can choose a
directory based on the distance. On the other hand, if directories store
different policies based on device types, a device should select the directory
of its type. The selection criteria should be carried in the solicitation
messages.
5.10.2 All-Directory Group
All policy directories join the all-directory group. A period session messages
are sent by individual directories to exchange directory characteristics, such
as database synchronization, distance measurement, etc. The information in the
session messages can be used to synthesize solicitation messages for the
bootstrap group.
This group is also used to distribute new policies and to request missing
policies among directories. When a new policies is installed in a directory,
this directory multicasts the policies to other directories. When a directory
discovers a missing policy, it multicasts a request to the group to recover the
missing policy.
5.10.3 Designated Group
Each policy directory is associated with a multicast group. This group is used
to distribute policies to policy-aware network devices. When a policy-aware
network device selects a policy directory as its designated directory, it also
joins the corresponding designated-directory group as a member. This device
receives new policies from its designated group. When the device discovers a
missing policy, it also requests its designated directory for recovery.
Therefore, once a designated directory is selected, a device only deals with
its
designated directory and designated group.
5.10.4 Mechanism Description
This section describes the operational mechanism of our communication
architecture. We discuss the bootstrap mechanism, policy dissemination and
policy retrieval.
5.10.5 Bootstrap Mechanism
When a policy directory is brought on-line, it joins 2 well-known multicast
groups, the bootstrap group and all-directory group. It starts exchanging
session messages with other directories in the all-directory group, and
sending
solicitation messages to the bootstrap group. Directory synchronization and
fault-tolerance can be achieved within the all-directory group. Since there
are
available mechanisms in the area of distributed database, we do not discuss
those mechanisms here.
When a policy-aware network device is brought on-line or it does not select a
designated directory, it joins the bootstrap group. The devices include
management consoles, policy servers and other policy-manageable devices. After
receiving solicitation messages from some directories, a device selects its
designated directory based on some criteria, for example, distance, device
type,
etc. The device also joins the corresponding designated group. From then on,
the
device can leave the bootstrap group. However, it can stay in the group if it
wishes to adapt to a better suitable directory.
5.10.6 Policy Dissemination
Policy dissemination is a 3-step process. The management console first
installs
the policy to a directory, the directory distributes it to all other
directories, and then directories multicast the policy to their designated
groups.
Each management console has one designated policy directory. When a management
console is brought on-line, the console learns of other existing directories
by
joining the bootstrap group. When the console installs a policy, it either
multicasts to its designated group or unicasts to its designated directory.
The
communication between the console and its designated directory should be
reliable, that is, an ACK should be received from the designated directory to
ensure the reception of the new policy.
When the designated directory receives a new policy, it informs other
directories by multicasting a copy of the policy to the all-directory group. A
reliable multicast mechanism, for example, SRM, is used to ensure the correct
reception of the new policy.
When a directory receives the new policies from the all-directory group or
receives a unicast policy from a device (i.e., management console), it
multicasts a copy to its designated group. However, if the designated group is
created based on device type, only devices affected by the policy should be
informed. The communication should be reliable among a directory and devices.
5.10.7 Policy Retrieval
In some cases, a device may request for missing policies. For example, when a
device is brought on-line, it should request for the past policies from it
designated directory.
Policy retrieval is a 2-step process. A policy-aware network device requests
its
designated group to retrieve a missing policy. If the designated directory has
the policy, it replies to the device. Otherwise, it requests the all-directory
group for the missing policy. The mechanism used in each step is exactly the
same as the reliable multicast mechanism in the policy dissemination.
6. LDAP compliance
This policy framework is more sophisticated than that allowed by a strictly
LDAP only protocols. One requirement is that this system should be interoper-
able with devices that are LDAP only capable.
If an LDAP based device, or network management system needs to interact with
the PMS, if may retrieve and set values using LDAP access to directories, which
may store all information required. Essentially each management view can be
stored in a virtual directory (or real directory). When an LDAP message is
received, the appropriate information is sent (via LDAP), or action performed.
Security, registration, and event notification are beyond LDAPÆs current ca-
pabilities, but future extensions to LDAP may address these weaknesses.
7. Security Considerations
We all know security is important, and most of us know how to implement it.
This architecture is modular based on databases, protocols, devices, and users.
We obviously need to encrypt everything, and authenticate all users. Ideally
a security policy should be used to set ACL for permissions on access to man-
agement system functionality.
8. Conflict Detection and Resolution
The other internet draft (qos-poli-rev-3.3.txt) does a good job of discussing
conflict issues. Only two issues need to be addresses further.
1) An alternative to identifying and resolving conflicts is to avoid them.
Ideally we should start with a small number of policies, and synthesize a large
number policies from them using proven techniques which will not produce con-
flicts in lower layers. As long as the original policies are conflict free,
and conflict safe algorithms are used by the management systems, conflicts need
not be detected, except at highest level.We are not saying that conflicts will
not occur, just that not all system will require conflict detection/resolution.
2) The policy management system must have sufficient knowledge of lower layers
to ensure it is not creating unimplementable policies. It would be very slow
to have a top level management system create policies which are unimplementable
at the lowest level. Without knowledge of the underlying network, it is point-
less to try to synthesis policies. Simply having a management system or device
reject a policy (with reasons) is not sufficient, since the system may next
try to synthesis policies with the new knowledge, but they may or may not work
(since the management system does not have all available information). The so-
lution is to retrieve required information first, and then synthesis policies.
This is not fundamentally different than internet draft (qos-poli-rev-
3.3.txt), as it also requires information to propagate up (in form of error
signals).
9. Example
Examples are the best way to show how this system works.
9.1 Example Configuration Policies
Policies:
30 % bandwidth reserved for Web traffic
10 % bandwidth reserved for control traffic (Router protocols, etc)
20 % bandwidth reserved for email
Step 1: Devices on network register themselves with PMS. Bootstrapping or SLP
is used to identify appropriate PMS.
Step 2: PMS queries devices (real or virtual) to determine their capabilities.
Information should include number of queues, buffer sizes, etc (for routers
only..obliviously)
Step 3: Network Administrator opens Network management console, authenticates
userid/password.
Step 4: Management console queries PMS (with Network administrators creden-
tials) for available network views, and allowed policies to be specified. PMS
responds with list of network views, and policy schemas (QoS only in this ex-
ample).
Step 5: The above policies are specified on management console, using a GUI.
The GUI interface produces a set of policies (compliant with Policy Schema,
QoS Schema). The management console would not allow security policies to be
entered, as they were not reported in step 2). The policies are sent to the PMS.
Step 6: The PMS sends policies to routers (or any other appropriate devices).
Step 7: The PMS configures (via policies again), network monitoring equipment
to verify policy enforcement. If the measured performance does not match spec-
ified performance, an event is sent to the management console. If an event
related to these policies is received from a network device (real or virtual),
it is also sent to the management console.
9.2 Example: Network Centric Policies
Policies:
Web Sessions should receive 100 Kbps and 50ms delay
Email sessions should receive 30 Kbps
Voice over IP should receive 32 Kbps
Step 1: Network Administrator opens Network management console, authenticates
userid/password.
Step 2: Management console queries PMS (with Network administrators creden-
tials) for available network views, and allowed policies to be specified. PMS
responds with list of network views, and policy schemas (QoS only in this ex-
ample).
Step 3: The above policies are specified on management console, using a GUI.
The GUI interface produces a set of policies (compliant with Policy Schema,
QoS Schema). The management console would not allow security policies to be
entered, as they were not reported in step 2). The policies are sent to the PMS.
Step 4: The Policy Management System receives the set of policies from the
management console. It verifies permission to set these policies.
Step 5: PMS needs to configure the network so that the policies specified are
being met. Since the policies specified do not directly translate into device
configurations, the PMS uses its knowledge of the current network state, and
configuration, and allowable configurations, to determine a set of configura-
tions that will achieve these policies (as well as other specified by other
managers). IMPORTANT NOTE: How this is done is not part of the standard, this
is where network management vendors will make products that differentiate them-
selves by how well they accomplish this. To realistically implement these pol-
icies however, the PMS would need to know about network traffic profiles. This
could be entered by user, or measured from network. The former method would
require the management console to supply traffic profiles. This could be ac-
complished in this framework by having the management console appear as both
as console and a device (network measurement device with traffic profile
views).
Step 6: PMS converts new configuration into policies for each device (real or
virtual in network), and sends them to the devices.
Step 7: The PMS configures (via policies again), network monitoring equipment
to verify policy enforcement. If the measured performance does not match spec-
ified performance, an event is sent to the management console. If an event
related to these policies is received from a network device (real or virtual),
it is also sent to the management console.
9.3 Example: Multi Layer Networks
Policies:
SLAÆs between ISP Customers and ISP
Step 1: Policies received from ISPÆs customers. These policies reflect service
requirements and QoS.
Step 2: ATM network is queried for its connectivity view. View shows possible
connectivity that ATM network may be configured for.
Step 3: Policies are used to configure network (IP Layer) through synthesized
policies. MPLS LSP are established.
Step 4: Policies are sent to ATM PMS, which configures PVCs in ATM network.
Step 5: A single link network view is return from ATM network.
Step 6: Single link views are produced for each VPN provided by ISP, and made
available to ISP Customers.
Step 7: General connectivity views are made for internet customers.
Step 8: Failure in ATM network event received. ATM PVC reconfigured to new
path.Cell loss occurred. The information in event states that data was lost
(technology independent). Details include bytes lost and duration. No details
of ATM network sent or required.
Step 9: If SLA performance not met, an event sent to customer.
9.4 LDAP Example
A LDAP only device, uses SLP (or appropriate directory location service) to
find PMS (which acts as a directory). It can use LDAP to query appropriate
policies. The PMS will restrict information supplied to LDAP device so that
only relevant information is sent.
The PMS acts as a smart LDAP directory.
If device asked for all router policies, the PMS would return DN of policies
appropriate for that device, assuming the PMS recognises the device. (A dif-
ferent device would get different list of policies back). An unrecognized de-
vice would receive the entire list of policies. The PMS must remember the DNs
given out, so that it can be consistent in responding to future queries. Note
that the PMS could actually use a real directory (LDAP based) if it wished,
but it
is not restricted to that.
10. 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 technology 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 identify any such rights. Information
on the IETFÆs procedures with respect to rights in standards-track and stand-
ards-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 im-
plementers or users of this specification can be obtained from the IETF Sec-
retariat.
The IETF invites any interested party to bring to its attention 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
information to the IETF Executive Director.
9. Acknowledgments
We would thank everyone who has or will criticize this document.
10. References
[COPS] Jim Boyle, Ron Cohen, David Durham, Shai Herzog, Raju Rajan, Arun Sas-
try, ôThe COPS (Common Open Policy Service) Protocol,ö draft-ietf-rap-cops-
02.txt, March 12, 1998.
[DSFIELD] K. Nichols, S. Blake, F. Baker, and D. Black, ôDefinition of the
Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headersö, Inter-
net Draft, <draft-ietf- diffserv-header-02.txt>, August 1998.
[LDAP] Yeong, W., Howes, T., and S. Kille, ôLightweight Directory Access Pro-
tocol,ö RFC 1777, Performance Systems International, University of Michigan,
ISODE Consortium, March 1995.
[SCHEMA] J. Strassner, E. Ellesson, _Policy Framework Core Information Model_,
draft <draft-ietf-policy-core-schema-01.txt>
[TERMS] J. Strassner and E. Ellesson, _Terminology for describing network pol-
icy and services_, draft <draft-strassner-policy-terms-01.txt>
11. AuthorÆs Addresses:
David C Blight
Fujitsu Labs of America
595 Lawrence Expressway
Sunnyvale, California
94086-3922
dblight@fla.fujitsu.com
408-530-4567
Charley Liu
Fujitsu Labs of America
595 Lawrence Expressway
Sunnyvale, California
94086-3922
charley@fla.fujitsu.com
12.0 Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to others,
and derivative works that comment on or otherwise explain it or assist in its
implementation may be prepared, copied, published and distributed, in whole or
in part, without restriction of any kind, provided that the above copyright
notice and this paragraph are included on all such copies and derivative works.
However, this document itself may not be modified in any way, such as by re-
moving the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of developing
Internet standards in which case the procedures for copyrights defined in the
Internet Standards process must be followed, or as required to translate it
into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by
the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an ôAS ISö
basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DIS-
CLAIMS 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 PUR-
POSE.
