Subject: Yet another architecture draft

From: David Blight <[email-masked]>
Date: Fri, 26 Feb 1999 17:50:12 -0800 (PST)

Here is another policy architecture, with more
of a network management perspective..

comments and critisms are welcome

dave
-------------------------------------------------------------------------------
Internet Engineering Task Force                 David C Blight

INTERNET DRAFT                                  Charley Liu 

17 February 1999                                Fujitsu Labs of America

                Generalized Policy Framework Architecture                      

                            gen-poli-rev-0.1.txt

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 dis-
tribute 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 inap-
propriate 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 in-
formation 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.

 Terminology

 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 defined, 
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 consistent 
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 sourc-
es (network managers, other management systems, synthesized from other poli-
cies). 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 specifica-
tions, and are interpreted by network management system, service management sys-
tems, or device management systems. In order for policies to be more useful the 
current techniques for network or device configuration, we must standardize pol-
icy specifications to that they are vendor independent. This implies that they 
must assume a generalized view of common network devices, services, or compo-
nents.

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 approach is to allow spe-
cialized network management systems to control appropriate portions of the net-
work, and allow communications between network management systems to achieve 
consistent management for all aspects of a network.

In order to allow network management system to communicate, we must do the fol-
lowing:

   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 manage-
ment 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 consistent 
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 important fea-
ture 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 bet-
ter, 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 interoperability, 
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 receive 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 (sim-
ilar to the one in PMS) interprets the policies, and issues machine specific 
instructions (via COPS, SNMP, or any other protocol).

   Policy Enabled Device: Any internet device, application, service, or appliance 
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 car-
rier/ISP. By allowing details of network to be abstracted by a single component, 
we allow ourselves to construct networks which can be managed by multiple man-
agement 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 system. 
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 (al-
though through a graphics front end).

An important part of this framework is that management systems may be tied to-
gether through the same interface. Any other management system should appear to 
the management system as a management console. Instructions from other manage-
ment systems should be in the form of policies, and information can be retrieved 
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 scal-
able 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 man-
agement system will export to the enterprise is one of a single link, with as-
sociated 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 avail-
able 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 man-
agement system. A Register message is returned to the requester, with an at-
tribute indicating error conditions. This message should also contain or 
initiate 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 ap-
propriate 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 message. 
It will contain sufficient information to identify whether the policy (or mod-
ification) 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 avail-
able,  the same functionality may be provided by the PMS (with multiple point 
to point connections). 

Our communication architecture adopts IP multicast and

the concept of self-organization. IP multicast is used to improve the efficiency

of one-to-many communication; and the self-organization concept is used to 

improve system robustness in the presence of network dynamics.

     . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .