rfc3198.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,180 行 · 第 1/4 页

      See "Differentiated Services".

   $ filter
      (T) A set of terms and/or criteria used for the purpose of
          separating or categorizing.  This is accomplished via single-
          or multi-field matching of traffic header and/or payload data.
          "Filters" are often manipulated and used in network operation
          and policy.  For example, packet filters specify the criteria
          for matching a pattern (for example, IP or 802 criteria) to
          distinguish separable classes of traffic.

   $ goal
      See "policy goal".

   $ information model
      (T) An abstraction and representation of the entities in a managed
          environment, their properties, attributes and operations, and
          the way that they relate to each other.  It is independent of
          any specific repository, software usage, protocol, or
          platform.

   $ Management Information Base (MIB)
      (T) A collection of information that can be accessed via the
          Simple Network Management Protocol.  Management information is
          defined in MIB modules using the rules contained in SNMP's
          Structure of Management Information (SMI) specifications
          [RFC2570].  Management information is an abstract concept, and
          definitions can be created for high level policy
          specifications, low level policy, as well as technology and
          vendor specific configurations, status and statistics.  (See
          also "Simple Network Management Protocol" and "Structure of
          Management Information".)

   $ MIB
      See "Management Information Base".







Westerinen, et al.           Informational                      [Page 6]

RFC 3198        Terminology for Policy-Based Management    November 2001


   $ MPLS
      See "Multiprotocol Label Switching".  (Also, MPLS may refer to
      Multi-Protocol Lambda Switching in optical networks.  But, this is
      unrelated to policy and not discussed further in this document.)

   $ Multiprotocol Label Switching (MPLS)
      (T) Integrates a label swapping and switching framework with
          network layer routing [RFC2702].  The basic idea involves
          assigning short fixed length labels to packets at the ingress
          to an MPLS cloud.  Throughout the interior of the MPLS domain,
          the labels attached to packets are used to make forwarding
          decisions (usually without recourse to the original packet
          headers).

   $ outsourced policy
      (P) An execution model where a policy enforcement device issues a
          query to delegate a decision for a specific policy event to
          another component, external to it.  For example, in RSVP, the
          arrival of a new RSVP message to a PEP requires a fast policy
          decision (not to delay the end-to-end setup). The PEP may use
          COPS-RSVP to send a query to the PDP, asking for a policy
          decision [RFC2205, RFC2748].  "Outsourced policy" is
          contrasted with "provisioned policy", but they are not
          mutually exclusive and operational systems may combine the
          two.

   $ PCIM
      See "Policy Core Information Model".

   $ PDP
      See "Policy Decision Point".

   $ PEP
      See "Policy Enforcement Point".

   $ PIB
      See "Policy Information Base".

   $ policy
      (P) "Policy" can be defined from two perspectives:
          -  A definite goal, course or method of action to guide and
             determine present and future decisions.  "Policies" are
             implemented or executed within a particular context (such
             as policies defined within a business unit).
          -  Policies as a set of rules to administer, manage, and
             control access to network resources [RFC3060].





Westerinen, et al.           Informational                      [Page 7]

RFC 3198        Terminology for Policy-Based Management    November 2001


          Note that these two views are not contradictory since
          individual rules may be defined in support of business goals.
          (See also "policy goal", "policy abstraction" and "policy
          rule".)

   $ policy abstraction
      (P) Policy can be represented at different levels, ranging from
          business goals to device-specific configuration parameters.
          Translation between different levels of "abstraction" may
          require information other than policy, such as network and
          host parameter configuration and capabilities.  Various
          documents and implementations may specify explicit levels of
          abstraction.  However, these do not necessarily correspond to
          distinct processing entities or the complete set of levels in
          all environments.  (See also "configuration" and "policy
          translation".)

   $ policy action
      (P) Definition of what is to be done to enforce a policy rule,
          when the conditions of the rule are met.  Policy actions may
          result in the execution of one or more operations to affect
          and/or configure network traffic and network resources.
          -  In [RFC3060], a rule's actions may be ordered.

   $ policy condition
      (P) A representation of the necessary state and/or prerequisites
          that define whether a policy rule's actions should be
          performed.  This representation need not be completely
          specified, but may be implicitly provided in an implementation
          or protocol.  When the policy condition(s) associated with a
          policy rule evaluate to TRUE, then (subject to other
          considerations such as rule priorities and decision
          strategies) the rule should be enforced.
      (T) In [RFC3060], a rule's conditions can be expressed as either
          an ORed set of ANDed sets of statements (disjunctive normal
          form), or an ANDed set of ORed sets of statements (conjunctive
          normal form).  Individual condition statements can also be
          negated.

   $ policy conflict
      (P) Occurs when the actions of two rules (that are both satisfied
          simultaneously) contradict each other.  The entity
          implementing the policy would not be able to determine which
          action to perform.  The implementers of policy systems must
          provide conflict detection and avoidance or resolution
          mechanisms to prevent this situation.  "Policy conflict" is
          contrasted with "policy error".




Westerinen, et al.           Informational                      [Page 8]

RFC 3198        Terminology for Policy-Based Management    November 2001


   $ policy conversion
      See "policy translation".

   $ Policy Core Information Model (PCIM) [RFC3060]
      (T) An information model describing the basic concepts of policy
          groups, rules, conditions, actions, repositories and their
          relationships.  This model is described as a "core" model
          since it cannot be applied without domain-specific extensions
          (for example, extensions for QoS or IPsec).  PCIM is "core"
          with respect to the area of policy.  However, it is a "Common
          Model," with respect to CIM - in that it extends the basic CIM
          concepts for policy.  (See also "Common Information Model".)

   $ policy decision
      (P) Two perspectives of "policy decision" exist:
          -  A "process" perspective that deals with the evaluation of a
             policy rule's conditions
          -  A "result" perspective that deals with the actions for
             enforcement, when the conditions of a policy rule are TRUE

   $ Policy Decision Point (PDP)
      (P) A logical entity that makes policy decisions for itself or for
          other network elements that request such decisions [RFC2753].
          (See also "policy decision".)

   $ policy domain
      (P) A collection of elements and services, and/or a portion of an
          Internet over which a common and consistent set of policies
          are administered in a coordinated fashion [RFC2474]. This
          definition of a policy domain does not preclude multiple
          sources of policy creation within an organization, but does
          require that the resultant policies be coordinated.
          -  Policies defined in the context of one domain may need to
             be communicated or negotiated outside of that domain. (See
             also "policy negotiation".)

   $ policy enforcement
      (P) The execution of a policy decision.

   $ Policy Enforcement Point (PEP)
      (P) A logical entity that enforces policy decisions [RFC2753].
          (See also "policy enforcement".)

   $ policy error
      (P) "Policy errors" occur when attempts to enforce policy actions
          fail, whether due to temporary state or permanent mismatch
          between the policy actions and the device enforcement
          capabilities.  This is contrasted with "policy conflict".



Westerinen, et al.           Informational                      [Page 9]

RFC 3198        Terminology for Policy-Based Management    November 2001


   $ policy goal
      (P) Goals are the business objectives or desired state intended to
          be maintained by a policy system.  As the highest level of
          abstraction of policy, these goals are most directly described
          in business rather than technical terms.  For example, a goal
          might state that a particular application operate on a network
          as though it had its own dedicated network, despite using a
          shared infrastructure. 'Policy goals' can include the
          objectives of a service level agreement, as well as the
          assignment of resources to applications or individuals.  A
          policy system may be created that automatically strives to
          achieve a goal through feedback regarding whether the goal
          (such as a service level) is being met.

   $ Policy Information Base (PIB)
      (T) Collections of related PRovisioning Classes (PRCs), defined as
          a module.  (See also "PRovisioning Class".)

   $ policy mapping
      See "policy translation".

   $ policy negotiation
      (P) Exposing the desired or appropriate part of a policy to
          another domain.  This is necessary to support partial
          interconnection between domains, which are operating with
          different sets of policies.

   $ policy repository
      (P) "Policy repository" can be defined from three perspectives:
          -  A specific data store that holds policy rules, their
             conditions and actions, and related policy data.  A
             database or directory would be an example of such a store.
          -  A logical container representing the administrative scope
             and naming of policy rules, their conditions and actions,
             and related policy data.  A "QoS policy" domain would be an
             example of such a container.
          -  In [RFC3060], a more restrictive definition than the prior
             one exists.  A PolicyRepository is a model abstraction
             representing an administratively defined, logical container
             for reusable policy elements.

   $ policy request
      (P) A message requesting a policy-related service.  This may refer
          to a request to retrieve a specific set of policy rules, to
          determine the actions to enforce, or other policy requests.
          When sent by a PEP to a PDP, it is more accurately qualified
          as a "policy decision request" [RFC2753].  (See also "policy
          decision".)



Westerinen, et al.           Informational                     [Page 10]

RFC 3198        Terminology for Policy-Based Management    November 2001


   $ policy rule
      (P) A basic building block of a policy-based system.  It is the
          binding of a set of actions to a set of conditions - where the
          conditions are evaluated to determine whether the actions are
          performed [RFC3060].

   $ policy server
      (P) A marketing term whose definition is imprecise. Originally,
          [RFC2753] referenced a "policy server".  As the RFC evolved,
          this term became more precise and known as the Policy Decision
          Point (PDP).  Today, the term is used in marketing and other
          literature to refer specifically to a PDP, or for any entity
          that uses/services policy.

   $ policy translation
      (P) The transformation of a policy from a representation and/or
          level of abstraction, to another representation or level of
          abstraction.  For example, it may be necessary to convert PIB
          data to a command line format.  In this "conversion," the
          translation to the new representation is likely to require a
          change in the level of abstraction (becoming more or less
          specific).  Although these are logically distinct tasks, they
          are (in most cases) blurred in the act of
          translating/converting/mapping.  Therefore, this is also known