rfc3060.txt

最新的RFC

   For the set of actions associated with a policy rule, it is possible
   to specify an order of execution, as well as an indication of whether
   the order is required or merely recommended.  It is also possible to
   indicate that the order in which the actions are executed does not
   matter.

   Policy rules themselves can be prioritized.  One common reason for
   doing this is to express an overall policy that has a general case
   with a few specific exceptions.

   For example, a general QoS policy rule might specify that traffic
   originating from members of the engineering group is to get Bronze
   Service.  A second policy rule might express an exception: traffic
   originating from John, a specific member of the engineering group, is
   to get Gold Service.  Since traffic originating from John satisfies
   the conditions of both policy rules, and since the actions associated
   with the two rules are incompatible, a priority needs to be
   established.  By giving the second rule (the exception) a higher
   priority than the first rule (the general case), a policy
   administrator can get the desired effect: traffic originating from
   John gets Gold Service, and traffic originating from all the other
   members of the engineering group gets Bronze Service.

   Policies can either be used in a stand-alone fashion or aggregated
   into policy groups to perform more elaborate functions.  Stand-alone
   policies are called policy rules.  Policy groups are aggregations of
   policy rules, or aggregations of policy groups, but not both.  Policy
   groups can model intricate interactions between objects that have
   complex interdependencies.  Examples of this include a sophisticated
   user logon policy that sets up application access, security, and
   reconfigures network connections based on a combination of user
   identity, network location, logon method and time of day.  A policy
   group represents a unit of reusability and manageability in that its
   management is handled by an identifiable group of administrators and
   its policy rules would be consistently applied

   Stand-alone policies are those that can be expressed in a simple
   statement.  They can be represented effectively in schemata or MIBs.
   Examples of this are VLAN assignments, simple YES/NO QoS requests,
   and IP address allocations.  A specific design goal of this model is
   to support both stand-alone and aggregated policies.

   Policy groups and rules can be classified by their purpose and
   intent.  This classification is useful in querying or grouping policy
   rules.  It indicates whether the policy is used to motivate when or
   how an action occurs, or to characterize services (that can then be
   used, for example, to bind clients to network services).  Describing
   each of these concepts in more detail,



Moore, et al.               Standards Track                     [Page 6]

RFC 3060             Policy Core Information Model         February 2001


   o  Motivational Policies are solely targeted at whether or how a
      policy's goal is accomplished.  Configuration and Usage Policies
      are specific kinds of Motivational Policies.  Another example is
      the scheduling of file backup based on disk write activity from
      8am to 3pm, M-F.

   o  Configuration Policies define the default (or generic) setup of a
      managed entity (for example, a network service).  Examples of
      Configuration Policies are the setup of a network forwarding
      service or a network-hosted print queue.

   o  Installation Policies define what can and cannot be put on a
      system or component, as well as the configuration of the
      mechanisms that perform the install.  Installation policies
      typically represent specific administrative permissions, and can
      also represent dependencies between different components (e.g., to
      complete the installation of component A, components B and C must
      be previously successfully installed or uninstalled).

   o  Error and Event Policies.  For example, if a device fails between
      8am and 9pm, call the system administrator, otherwise call the
      Help Desk.

   o  Usage Policies control the selection and configuration of entities
      based on specific "usage" data.  Configuration Policies can be
      modified or simply re-applied by Usage Policies.  Examples of
      Usage Policies include upgrading network forwarding services after
      a user is verified to be a member of a "gold" service group, or
      reconfiguring a printer to be able to handle the next job in its
      queue.

   o  Security Policies deal with verifying that the client is actually
      who the client purports to be, permitting or denying access to
      resources, selecting and applying appropriate authentication
      mechanisms, and performing accounting and auditing of resources.

   o  Service Policies characterize network and other services (not use
      them).  For example, all wide-area backbone interfaces shall use a
      specific type of queuing.

      Service policies describe services available in the network.
      Usage policies describe the particular binding of a client of the
      network to services available in the network.

   These categories are represented in the Policy Core Information Model
   by special values defined for the PolicyKeywords property of the
   abstract class Policy.




Moore, et al.               Standards Track                     [Page 7]

RFC 3060             Policy Core Information Model         February 2001


2.1. Policy Scope

   Policies represent business goals and objectives.  A translation must
   be made between these goals and objectives and their realization in
   the network.  An example of this could be a Service Level Agreement
   (SLA), and its objectives and metrics (Service Level Objectives, or
   SLOs), that are used to specify services that the network will
   provide for a given client.  The SLA will usually be written in
   high-level business terminology.  SLOs address more specific metrics
   in support of the SLA.  These high-level descriptions of network
   services and metrics must be translated into lower-level, but also
   vendor-and device-independent specifications.  The Policy Core
   Information Model classes are intended to serve as the foundation for
   these lower-level, vendor- and device-independent specifications.

   It is envisioned that the definition of the Policy Core Informational
   Model in this document is generic in nature and is applicable to
   Quality of Service (QoS), to non-QoS networking applications (e.g.,
   DHCP and IPSec), and to non-networking applications (e.g., backup
   policies, auditing access, etc.).

2.2. Declarative versus Procedural Model

   The design of the Policy Core Information Model is influenced by a
   declarative, not procedural, approach.  More formally, a declarative
   language is used to describe relational and functional languages.
   Declarative languages describe relationships between variables in
   terms of functions or inference rules, to which the interpreter or
   compiler can apply a fixed algorithm in order to produce a result.
   An imperative (or procedural) language specifies an explicit sequence
   of steps to follow in order to produce a result.

   It is important to note that this information model does not rule out
   the use of procedural languages.  Rather, it recognizes that both
   declarative as well as procedural languages can be used to implement
   policy.  This information model is better viewed as being declarative
   because the sequence of steps for doing the processing of declarative
   statements tends to be left to the implementer.  However, we have
   provided the option of expressing the desired order of action
   execution in this policy information model, and for expressing
   whether the order is mandatory or not.  In addition, rather than
   trying to define algorithms or sets of instructions or steps that
   must be followed by a policy rule, we instead define a set of modular
   building blocks and relationships that can be used in a declarative
   or procedural fashion to define policies.






Moore, et al.               Standards Track                     [Page 8]

RFC 3060             Policy Core Information Model         February 2001


   Compare this to a strictly procedural model.  Taking such an approach
   would require that we specify the condition testing sequence, and the
   action execution sequence, in the policy repository itself.  This
   would, indeed, constrain the implementer.  This is why the policy
   model is characterized as a declarative one.  That is, the
   information model defines a set of attributes, and a set of entities
   that contain these attributes.  However, it does NOT define either
   the algorithm to produce a result using the attributes or an explicit
   sequence of steps to produce a result.

   There are several design considerations and trade-offs to make in
   this respect.

   1. On the one hand, we would like a policy definition language to be
      reasonably human-friendly for ease of definitions and diagnostics.
      On the other hand, given the diversity of devices (in terms of
      their processing capabilities) which could act as policy decision
      points, we would like to keep the language somewhat machine-
      friendly.  That is, it should be relatively simple to automate the
      parsing and processing of the language in network elements.  The
      approach taken is to provide a set of classes and attributes that
      can be combined in either a declarative or procedural approach to
      express policies that manage network elements and services.  The
      key point is to avoid trying to standardize rules or sets of steps
      to be followed in defining a policy.  These must be left up to an
      implementation.  Interoperability is achieved by standardizing the
      building blocks that are used to represent policy data and
      information.

   2. An important decision to make is the semantic style of the
      representation of the information.

      The declarative approach that we are describing falls short of
      being a "true" declarative model.  Such a model would also specify
      the algorithms used to combine the information and policy rules to
      achieve particular behavior.  We avoid specifying algorithms for
      the same reason that we avoid specifying sets of steps to be
      followed in a policy rule.  However, the design of the information
      model more closely follows that of a declarative language, and may
      be easier to understand if such a conceptual model is used.  This
      leads to our third point, acknowledging a lack of "completeness"
      and instead relying on presenting information that the policy
      processing entity will work with.

   3. It is important to control the complexity of the specification,
      trading off richness of expression of data in the core information
      model for ease of implementation and use.  It is important to
      acknowledge the collective lack of experience in the field



Moore, et al.               Standards Track                     [Page 9]

RFC 3060             Policy Core Information Model         February 2001


      regarding policies to control and manage network services and
      hence avoid the temptation of aiming for "completeness".  We
      should instead strive to facilitate definition of a set of common
      policies that customers require today (e.g., VPN and QoS) and
      allow migration paths towards supporting complex policies as
      customer needs and our understanding of these policies evolve with
      experience.  Specifically, in the context of the declarative style
      language discussed above, it is important to avoid having full
      blown predicate calculus as the language, as it would render many
      important problems such as consistency checking and policy
      decision point algorithms intractable.  It is useful to consider a
      reasonably constrained language from these perspectives.

   The Policy Core Information Model strikes a balance between
   complexity and lack of power by using the well understood logical
   concepts of Disjunctive Normal Form and Conjunctive Normal Form for
   combining simple policy conditions into more complex ones.

3. Overview of the Policy Core Information Model

   The following diagram provides an overview of the five central
   classes comprising the Policy Core Information Model, their
   associations to each other, and their associations to other classes
   in the overall CIM model.  Note that the abstract class Policy and
   the two extension classes VendorPolicyCondition and
   VendorPolicyAction are not shown.

   NOTE:  For cardinalities, "*" is an abbreviation for "0..n".























Moore, et al.               Standards Track                    [Page 10]

RFC 3060             Policy Core Information Model         February 2001


                               +-----------+
                               |  System   |
            .....              +--^-----^--+       .....
            .   .                1.    1.          .   .
           *.(a).*                .(b)  .(c)      *.(d).*
         +--v---v---------+       .     .        +-v---v------------+