2.2.2 Policy Framework (policy)

NOTE: This charter is a snapshot of the 45th IETF Meeting in Oslo, Norway. It may now be out-of-date. Last Modified: 06-Jul-99

Chair(s):

Ed Ellesson <ellesson@raleigh.ibm.com>
John Strassner <johns@cisco.com>

General Area Director(s):

Fred Baker <fred@cisco.com>

General Area Advisor:

Fred Baker <fred@cisco.com>

Mailing Lists:

General Discussion:policy@raleigh.ibm.com
To Subscribe: policy-request@raleigh.ibm.com
In Body: subscribe
Archive: http://www.raleigh.ibm.com/maillists/policy

Description of Working Group:

Problem Statement:

There is a need to represent, manage, share, and reuse policies and policy information in a vendor-independent, interoperable, and scalable manner. This working group has three main goals. First, to provide a framework that will meet these needs. Second, to define an extensible information model and specific schemata compliant with that framework that can be used for general policy representation (called the core information model and schema). For now, only a directory schema will be defined. Third, to extend the core information model and schema to address the needs of QoS traffic management (called the QoS information model and schemata).

The viability of the framework will be proven by demonstrating that high-level policy information can be translated into device configuration information for network QoS applications. This requires the coordination of the core and QoS schemata, the PIB and MIB being developed in DiffServ, and possibly extensions to COPS provisioning, which is being developed in RAP. A secondary goal of this framework is to show that this general development process can be extended to other application domains.

Objectives:

The objectives of this working group are to:

1. Identify a set of representative use cases to guide us in defining a policy framework, information model, and schemata to store, retrieve, distribute and process policies. These use cases should map to a set of policy rules, and aid us in defining the composition of policies.

2. Define a framework for intra-domain policy definition and administration for a heterogeneous set of Policy Decision and Enforcement Points. Here, "intra-domain" refers to policy components that are all under the same (and exclusive) administrative control. The framework will be shown to be able to be used to represent, distribute, and manage policies and policy information in an unambiguous, interoperable manner in a single administrative domain. This framework will be applied to network QoS.

3. A general information model, derived from the CIM/DEN policy model, will be produced. This is intended to serve as a generic means for representing policies and policy information. In addition, a mapping of this information model to a form that can be implemented in a directory that uses LDAPv3 as its access protocol will also be done.

4. Refinements to the above, for representing signaled and provisioned QoS, will be done. That is, both the information model as well as the schema will be extended to focus on network QoS. This will also be used to prove the general extensibility of the model.

5. A key part of demonstrating that this model can provide end-to-end translation of high-level policy specifications to device configurations is to ensure that the information model and schemata are compatible with and can use the information contained in the PIB(s) and MIB(s) being developed in the Differentiated Services WG. To this end, the Policy Framework WG will supply input to the development of the PIBs, and include all applicable PIBs and MIBs in its development considerations for the framework, information model, and schemata.

6. Policy information may be communicated using several protocols. The COPS protocol, being developed in the RAP WG, is an example of one such protocol. The Policy Framework WG will work with the RAP WG to define usage directives for use of the COPS base protocol to support policy information exchange transactions within the framework being standardized in the Policy Framework WG.

7. The Policy Framework WG will work closely with the IPSP WG to ensure that the IPsec data model fits and can be supported within the general framework defined by the Policy Framework WG.

8. The Policy Framework WG will work with other WGs as needed to ensure that the framework, information model, and specific schemata produced meet the needs of these WGs.

9. The charter specifically excludes:

-protocol definition

-schema attributes or classes that are vendor-specific (although the schema defined in this group will be defined in a way that is extensible by specific vendors)

Goals and Milestones:

Mar 99

  

WG Last Call for FYI RFC

Aug 99

  

WG last call on Policy terminology draft (Informational Track)

Aug 99

  

Submit Internet Draft on Use case definition (Informational Track)

Sep 99

  

WG last call on Core information model draft (Standards Track)

Oct 99

  

WG Last Call on Use case definition (Informational Track)

Dec 99

  

WG Last Call on Framework draft (Informational Track)

Mar 00

  

WG Last Call on QoS Schema draft(s) (Standards Track)

Internet-Drafts:

No Request For Comments

Current Meeting Report

Minutes, day 1, recorded by John Strassner

Charter Changes and Update - John Strassner

John described the changes to the charter. They are summarized below:
- Information model and LDAP schema were separated into 2 drafts:
- draft-ietf-policy-core-info-model-00.txt
- draft-ietf-policy-core-schema-04.txt
- Both were explicitly linked to the CIM and DEN models
- The charter was updated to call for explicit coordination between the core and QoS policy information model and schemata and:
- PIB(s) and MIB(s) developed in DiffServ
- COPS-PR developed in RAP
- working with IPSP
- A document combining requirements and use cases will be added
- A new set of milestones were added

Core Information Model and LDAP Schema Drafts - Bob Moore

The Core Information Model and Core LDAP Schema were presented by Bob Moore. Bob first presented the design for splitting the classes that were in the ...-core-schema-03 document into classes that are in .-core-info-model-00 and classes that are in ...-core-schema-04. This also gave insight into why certain new classes that appeared in the LDAP core schema only were necessary.There are no fewer and no more classes than there were before, they are just organized better and have had more detail added.

The information model specifies the semantics of policy independently of any implementation (including directories that use LDAP as their access protocol). It does this by using generalized object classes, and associations and aggregations to relate the different object classes to each other. It is an enhancement of DEN. Its purpose is to enable other organizations to map a single model to multiple storage technologies, making cross-technology interoperability possible.

The purpose of the LDAP core schema is to map the data and relationships represented in the core information model to a form that is implementable in a directory that uses LDAP as its access protocol. Therefore, the basic semantics of these classes are referenced, not repeated. Modeling constructs, such as associations and aggregations, are usually represented as DN pointers and "structured DN pointers" (this latter is used to represent a CIM association (or aggregation). >From the directory server's point of view, this is NOT a DN pointer, but rather is an LDAP attribute of syntax DirectoryString that has embedded within it multiple semantic elements, including a DN-valued pointer and at least one other element.

Sometimes, auxiliary classes are also used. Specific optimizations to simplify identification of classes in the DIT that should be under policy control, DIT navigation and bulk retrieval of policy-related information were introduced. These are all required to help mitigate performance problems when using LDAP, and therefore have no corresponding classes in the Core Information Model.

Ryan Moats offered to help describe the format of the core LDAP schema classes in ABNF.

In addition, the concept of versioning was discussed, but no decisions were made as to its incorporation.

Going to last call was discussed. The basic problem is that the core information model (and to a lesser extent, the core LDAP schema mapping) is needed by other working groups. This argues for moving these documents to last call, once changes have been incorporated (see end of the minutes for more info on this). On the other hand, some people expressed concern that related work, such as the architecture document and the PIB(s), should be progressed first, and then have the core documents moved to last call.

One possibility is to move the document through working group Last Call to ensure that there is consensus, but then wait to submit it to the IESG until the architecture document (and maybe others) have had a round of comments. The chairs and the ADs will work out a strategy and propose this to the working group.

Raju Rajan - QoS Schema

Raju gave an overview of the draft that he has co-authored. It describes a schema for modeling provisioned and signaled QoS. The goals of the provisioned QoS section are:
- Identify flow aggregates
- Ensure resource allocation for flow aggregates using PHBs
- Ensure support for AF and EF
- Support packet (re)marking

The goals of the Signaled QoS section are:
- Accept or reject reservation requests
- Per-flow, per-user, per-domain, per-application
- Assign priorities for preemption
- Support RSVP policy objects

The draft attempts to support range of client types, including end hosts/servers as well as networking devices such as routers and firewalls. For each device category, there are different actions that are applicable. These include the following:
- Applications and Hosts
- User and application needs
- Packet marking

Edge routers and firewalls
- Traffic verification
- Shaping
- Aggregation
- Resource allocation

Backbone routers
- Aggregation
- Resource allocation

The DiffServ actions are provided through three classes - diffServAction (subclass of policyAction), and diffServResourceGroup and RSVPResourceGroup, the latter two of which are both subclasses of Top. Traffic profile descriptors and packet marking descriptors are embedded in the diffServAction class. The traffic profile descriptor is used to classify traffic as being in- or out-of-profile. The packet marking descriptor provides the ability to mark the DS byte for enabling simpler QoS classification at downstream network devices. The resource group descriptor describes the treatment expected by packets within a common service group. The descriptor does NOT aim to describe how the service is to be provided, as this is device-specific. Instead, it describes the semantics of the traffic conditioning that is to be performed.

The class RSVPAction, which is a subclass of policyAction, contains policies to be applied to RSVP PATH messages and RESV messages. The draft supports simple forms of policy based control, enabling administrative restrictions to be placed on the amount of resources that a single RSVP flow, or group of flows, may consume. Support is also provided for an RSVP reservation to be mapped into a DiffServ service category.

Raju presented three approaches to the following problem: if 3 descriptors are dumped into a single action class, then if there are two domains that require separate policing that share a common resource, this can't be accommodated. His recommended solution was to combine traffic descriptor and marking in two different DiffServ action classes, and use a pointer to a resource descriptor. You can further expand on this by cascading diffuser action classes, that each have their own mark and resource descriptor objects. Problem is that there are too many objects (Editor note: if the objects are reusable, then their quantity doesn't matter. However, there are still concerns related to transactions, loose consistency in replication scenarios, etc. that remain if there are multiple objects at all.

There were a number of questions on the draft.

Shai: No higher-level above RSVP or DS
Raju: take rate. It's defined differently in ATM, DS, etc.

Raj: we need a separate conceptual model

Shai: Why is there no such thing as Gold Service. How do I map between AF11 and AF31?
Raju: embedded in the condition, and the PDP does this.

Shai: See a higher-level being mapped into RSVP and DS. This is too low-level.

Raju: What about concurrent work going on in the DMTF? Those of us that aren't members can't see this.
John: The latest version of CIM is publicly accessible

Andrew: needs alignment with terminology draft
John: agreed, but we need to reconcile this draft with other QoS drafts to be presented and then align the terminology

David: conditions draft enables you to build an MF classifier; what is lacking is network state ToS marking needs alignment with DiffServ. AutoStart should be optional

Yoram Bernet/Andrew: is this draft at the right level? Similar to the conceptual model in DiffServ, but why is the draft so close to the device

QoS Device Information Model - Walter Weiss/John Strassner

Best Effort was a Good Thing. Everything was straightforward and easy. You pushed out the bandwidth, and whatever happened . Congestion wasn't bad - it told you how much you had to cut back, and how much you had to add.

Then came QoS. Things got a LOT more complicated, especially management. This took the form of increasing complexity required to manage individual devices to support network services.

What is a QoS Service? There are two different elements of this service configuration and management. Policy comes more into play in the maintenance of a service. Policies apply to services, and also help implement services.

Need for low-level policies. Device has a set of capabilities, and we can talk about sets of devices that share sets of capabilities. This is especially true of DS, when we are talking about behaviors and how services like AF and EF are managed and maintained. We're advocating support attributes and classes in the schema that enable us to manage such services, and to facilitate the mapping of information in schemata to MIBs, PIBs, etc.

Slide # 6 shows the inherent sub-ordinate relationship of policies. This is why examples such as "Gold Service" are fraught with trouble, since "Gold Service" consists of a set of sub-services that, together, provide the higher-level service referred to as "Gold".

There are 2 components of a policy: grammatical semantics and attributes. Is User = George, or is this IP Address part of the Sales Force. Variables and constants represent the things that you want to manipulate and check (e.g., device and service state). When you combine these 2 concepts, you can construct policies to manage services and business objectives. This is why low-level policies are so important - Gold Service is meaningless unless it can be related to what the device is capable of providing.

Shai: 2 statements in first group - is this procedural.
John: No, this defines the enabling of a new class. The point is that some policies may need to be executed in a device, whereas others should be executed in a PDP. It depends on the component of the policy (e.g., are you testing a group of counters)

Attributes are stored in classes, and the policy core model defines the class structure and grammatical semantics to do this. However, we worry about attributes being subclassed out of the policy core schema. Problem is that if all policy attributes are subclassed from the core schema, this leads to massive duplication of attributes, not just between different IETF wgs, but also between DMTF models and IETF wgs. This draft makes a clear differentiation between state and configuration attributes, something that has been heretofore lacking. There are really two different types of attributes - state vs. configuration attributes. State attributes are attributes that represent the currently active state of the device or service, e.g.., counters. Configuration attributes specify what the desired value that you want the device or service to have. E.g., if average queue depth was 10K bytes, and if we want to change that for a certain set of devices, then we can decouple state from configuration.

You can also represent a group of devices, or interfaces, or services, or other objects, as the object of the configuration.

Contexts and roles. Roles need to be formally added to the grammatical syntax of policies. These are used to define what policies are applied to what devices.

Raju: Why can't we use the policyGroup container for roles?
John: Because a role is simply a string attribute that defines the name of the object in question. It is not a container. Furthermore, a container has the limited semantics of being able to hold objects. A role points to an object that has much more powerful semantics, describing how it is used in the system.

Question: Where does this fit in w.r.t. the bigger picture?
Walter: We want people to think about policies in respect to low-level and high-level function. We also want to differentiate between configuration and state.

Question: how does this scale? Suppose you had a relatively large network. How many objects would be required?
John: Impossible to answer, since policies are inherently different in nature, and it depends on what it is that you are trying to do. For example, controlling a single device will generally take less objects than controlling a set of devices. But, as we'll see in the next presentation, being able to reuse objects mitigates their sheer number.
Question: But isn't this a lot of objects?
John: Again, impossible to define in the general sense. But it is generally greater that 1 and less than 50.

Day 2, minutes recorded by John Strassner

Yoram Snir - QoS Information Model

This draft is complementary to the previous draft presented. This draft subclasses the policy core information model, whereas the previous draft subclasses the network model of CIM.

This draft is an extension to the core schema draft, in spirit and structure. Aimed to help interoperability. Schema is made up of 3 parts: Scoping, Repository, and Definitions.

Reusable-objects. This is a notion currently missing from the core schema. We feel that it is essential to building highly scalable and reusable schemata. The repository classes are subclassed from the core schema. This enables us to add semantics to the policyGroup class defined in the core schema.

The repository structure is described. Note that it is extensible by nature, what is presented in the draft is meant to be a foundation.

Reusable objects are placed in the repository. This lets you abstract key concepts (e.g., an HTTP port can be referred to by HTTP, and you don't care what the exact port number is). It also helps protect against some of the deficiencies of LDAP - if classes reference reusable objects from one repository class, then changes can be simplified - always get them from one place.

An extensible containment hierarchy is defined in the draft. This divides objects into multiple domains, each of which can have a set of named containers that contain groups of policyRules to be applied for a common set of applications, or to a subnet, or to the employees of an organizationalUnit, etc.

Simple conditions are built out of variables and constants. Variables have a name and a type, and represent constraints. Constants have a name and a type, and represent values. We've defined some simple value classes; more can be added as required.

With this structure, we are able to model provisioned and signaled QoS conditions and actions in an extensible way. We also have the ability to model simple and complex conditions, as defined in the core schema draft.

Something that we're working on is how to abstract the PHB. We're also working on general definition for PATH and RESV admission control.

Simple condition example - attachment This shows a simple condition built out of the attachment of a variable and a constant class. Note that the constant class has a qosPolicyNumberValue class attached to it. This is in the spirit of the core schema, and enables you to retrieve this in a single access

Simple condition example - reference.
- Gives you more flexibility at the expense of more accesses. But more accesses aren't bad if the objects that they are referring to are reusable. Same caution with respect to other deficiencies of using LDAP in this scenario apply here too.

Complex condition
- This is also accommodated by our approach. Consists of a set of references to separate objects

Simple QoS Policy Rule
- Example consists of a SimpleCondition and a single action. Each of these can be attached directly to the qosPolicyRule, which is a structural class.

QoS Policy Rule example
- Now we have a qosPolicyRule with a condition List and an actionList. Each of the lists point to other objects. The objects themselves can be simple objects or objects that have other objects attached to them.

Namespace example
- This reflects the translation of different administrative domains. Within a given domain you have a set of policy rules that can be simple or complex.

David Black: good that someone tried to put this together, likes it in general

Glenn Waters - Status of the Policy Framework draft

There is a new set of authors (Hugh Mahon, Mark Stevens, John Strassner, Lee Rafalow, and Glenn Waters). Next revision to be submitted to the draft editor by 31 August, will have an interim copy available for wg review by 15 August.

The general architecture was described. Focus was on the partitioning of the framework into four components (Policy Management Tool, Policy Repository, PDP, and PEP), and their interconnection.

The purpose of the policy management tool is to serve as an interface between policy definition, editing, and management functions external to the Policy Server (e.g., the repository, PDP, and PEP, NOT just
the PDP!) and the components of the Policy Server. It consists at least of an editor, a means to translate policy rules entered in human-readable form to a format compatible with the type of the repository being
used, and the ability to validate policy rules. This includes syntax and semantics (to as much an extent as possible) checking, as well as simple static conflict detection.

The repository is used to store policy information and rules. Note that any technology can be used, but particular attention is paid to a directory that uses LDAP as its access protocol.

The PDP performs three main functions. First, it responds to policy events and locates the appropriate rules that are of interest to this event. Second, it performs state and resource validation (for example, bandwidth broker using policies to control bandwidth allocation). Finally, it converts the policy rules as stored in the repository to device-specific mechanisms.

The PEP is responsible for executing the appropriate actions. Note that the PEP may in fact evaluate the policy instead of the PDP, if the conditions of the policy are (for example) traffic conditions that PDP doesn't understand.

Other important parts of the document discuss conflict detection and interoperability (e.g., how the data in the repository is used and accessed).

Talk more about Cisco additions, but note that there is no existing standard to pass notifications. Note also that we don't talk about protocols in this wg, and so we can specify its functional requirements in the architecture, and we can specify what happens, but we can't specify the protocol itself.

Document sections left to write:
- Roles: John
- PIBs: Hugh/Mark
- Conflict detection additions: John
- Relationship to other WGs: Hugh
- Procedural vs. declarative: Glenn

Keith: clarify that you will have multiple of each component (e.g., the PDP)
Glenn: OK

Fran: the device adapter never disappears
Glenn: meant a translation of format.
Fran: Doesn't this change how things are stored in the repository?
Glenn: No, it just means that the PEP is very smart and knows how to deal with information in a raw format

Yoram Bernet: Need to beef up sections on RSVP (e.g., COPS for RSVP) and generalize things like filters for both DiffServ and RSVP usage

Keith/Nitsan: worried about distribution of policy information

Raj: not trying to solve LDAP problems, right?
Glenn: right

Yoram: use of directory - just for static info, right?
Glenn: right

Walter: variable manipulation can be part of the info model, but do
NOT have to be pushed up all the way to the directory

John Strassner - Update on the Terminology draft

The purpose of this draft is to define a standard set of terms that describe policy. It should be compatible with formal modeling terminology.

Motivation was to reconcile differences in terminology between the DiffServ, RAP, and Policy groups. Intent is not to redefine terminology of other groups (e.g., what is a PDP) but rather to help drive a common agreement between the working groups.

This was recently reissued as a working group draft. Final edits are being incorporated, and then the next step is to do a thorough review of it with the updated DiffServ and RAP documents. Will then reissue by end of August.

Hugh Mahon - Policy Usage and Requirements

This will turn into a working group draft.

The focus in on how one will use a policy system. It emphasizes the separation of policy delivery from the definition, editing, and management of policies. It covers issues such as:
- accommodating those particular policies that need to be delivered in a timely manner. Note that this is separate from how often the policy changes, or who changes it.
- providing feedback to the administrator describing what happened to the policy (e.g., was it delivered? were there any installation problems? etc.)
- how does the administrator know that the authored policy is what was received?
- how to deal with the lack of transactional and referential integrity in LDAP
- role management

Nitsan: reporting policy server errors. This has a usability problem - we need to be able to tell the user that a particular policy was successfully downloaded, installed, and deployed.

Scott Hahn - Description of the PIB

Important point is that PIB lives not in the schema but is passed down to the device. Scott views schema as high-level and abstract, not at the level that the device needs to implement policy. PIB is responsible for configuration. It enables the same configuration to be pushed down to a set of devices.

So, the PIB is not a protocol, nor is it a schema. It is a data definition that exposes the capabilities of a PEP to the PDP. The PEP uses the PIB to report device capabilities to its PDP. The PDP uses the PIB to provide configuration information and updates to the PEP.

Policy server and PDP developers need to be aware of both the PIB and the schema, because they need to map information contained in one to the other, and vice-versa. Referring to slide #3, PIB information is carried on the wire between the PDP and a PEP.

The flow of data is simple - the device expresses its capabilities to the PDP, and then the PDP matches policy rules to those capabilities and sends down configuration information. The PEP can then report status and/or errors to the PDP. Note that the PDP can asynchronously update policies as required.

The PIB is protocol-agnostic, but one specific implementation was written with COPS-PR in mind as the transport protocol. The PIB could easily be carried over SNMP, for example.

The initial draft focuses on a QoS PIB, though the concept is extensible to other policy domains. Now part of the DiffServ WG. Focused on DiffServ policies. QoS PIB consists of 3 modules: general info, IP module, and 802.1p module.

The PIB uses the concept of roles and role-combinations.

More integration needed with DiffServ conceptual model and the DiffServ MIB. Metering currently is not addressed.

Kathy Dally - How is violation of Policy handled? (we need to take this to the working group)

Walter - we need a practical example of how to use a PIB. In particular, we need to substantiate the claim that it contains lower-level information than the schema contains. (again, we need to take this to the working group)

Policy Conditions (Raju)

PolicyGroup groups policyRules. PolicyRules talks about policyConditions and policyActions.

What should be the content of policyConditions, and how should it be structured. PolicyConditions need packet header and PEP information, administrative categories, and network state/event categories. This should be represented in the schema, but we must consider data and query costs, extensibility, structural vs. aux classes. These considerations affect the overall object model.

Administrative categories - user, user groups; hosts and host groups; apps; roles

Network state/event information. Wide range of events that are relevant to QoS. But you get into trouble when you try to put this into the directory. Examples of this are network congestion, routing information, or RSVP path message arrival. How will we achieve interoperability, and how can we ensure that multiple devices from multiple vendors will use the same definitions.

Policy condition - if you embed an expression directly as an attribute in the condition object, then it isn't extensible and you need another schema to interpret it.

One way to do this is with one structural class with all may attributes. Not extensible, and doesn't allow one user to extend attributes of the class of one type without affecting the entire class. Preferred way is to use multiple aux classes.

Jamie Jason - Working with IPSP

There are currently 3 drafts in IPSP - ASN1 draft for VPNs, another, plus UML draft. We've unified the 3 drafts in order to design policy to control IPSEC in the abstract. After we get agreement from the IPSEC wg, we want to get agreement with the PFWG. This will enable us to ensure that their draft is properly derived from PF core classes, as well as enable them to provide direct feedback to this wg. Want to be able to represent the 5-tuple somewhere, maybe not in core, but certainly not repeatedly in IPSP and DiffServ.

Final Action Items (Ed Ellesson)

General consensus that some concepts in the Snir-Ramberg-Strassner QoS draft (e.g., repositories) need to be moved into the core policy document. Authors of both documents to get together and plan this out. Then, both documents will be re-issued.

Policy terminology draft to be updated, and a new revision sent to the list. It is hoped that the next revision of this (and the policy core information model draft) will be ready for working group last call.

Core LDAP draft proceeding well, but needs another revision before we can start considering Last Call.

The authors of the framework draft will produce an updated draft on or before 31 August. Hugh will try to produce his new draft by 31 August too.

It seems like we should have an interim meeting, possibly one day of design team from Policy, DiffServ and RAP, and another day of the Policy Framework working group. Target date will be early September.

Slides

Agenda
Charter Discussion
Status of the Policy Framework Draft
Policy Information Base (PIB)
QoS Policy Schema
Usage Scenarios
Terminology Draft Status