rfc3060.txt

最新的RFC

   to make the access permissions for a rule-specific condition or
   action identical to those for the rule itself.  It's also natural for
   a rule-specific condition or action to be removed from the policy
   repository at the same time the rule is.  With reusable conditions
   and actions, on the other hand, access permissions and existence
   criteria must be expressible without reference to a policy rule.

   The preceding paragraph does not contain an exhaustive list of the
   ways in which reusable and rule-specific conditions should be treated
   differently.  Its purpose is merely to justify making a semantic
   distinction between rule-specific and reusable, and then reflecting
   this distinction in the policy model itself.

   An issue is highlighted by reusable and rule-specific policy
   conditions and policy actions:  the lack of a programmatic capability
   for expressing complex constraints involving multiple associations.
   Taking PolicyCondition as an example, there are two aggregations to
   look at.  PolicyConditionInPolicyRule has the cardinality * at both
   ends, and PolicyConditionInPolicyRepository has the cardinality * at
   the PolicyCondition end, and [0..1] at the PolicyRepository end.

   Globally, these cardinalities are correct.  However, there's more to
   the story, which only becomes clear if we examine the cardinalities
   separately for the two cases of a rule-specific PolicyCondition and a
   reusable one.

   For a rule-specific PolicyCondition, the cardinality of
   PolicyConditionInPolicyRule at the PolicyRule end is [1..1], rather
   than [0..n] (recall that * is an abbreviation for [0..n]), since the
   condition is unique to one policy rule.  And the cardinality of
   PolicyConditionInPolicyRepository at the PolicyRepository end is
   [0..0], since the condition is not in the "re-usable" repository.
   This is OK, since these are both subsets of the specified
   cardinalities.





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


   For a reusable PolicyCondition, however, the cardinality of
   PolicyConditionInPolicyRepository at the PolicyRepository end is
   [1..1], since the condition must be in the repository.  And, the
   cardinality of PolicyConditionInPolicyRule at the PolicyRule end is
   [0..n].  This last point is important:  a reusable PolicyCondition
   may be associated with 0, 1, or more than 1 PolicyRules, via exactly
   the same association PolicyConditionInPolicyRule that binds a rule-
   specific condition to its PolicyRule.

   Currently the only way to document constraints of this type is
   textually.  More formal methods for documenting complex constraints
   are needed.

5.2. Roles

5.2.1. Roles and Role Combinations

   The concept of role is central to the design of the entire Policy
   Framework.  The idea behind roles is a simple one.  Rather than
   configuring, and then later having to update the configuration of,
   hundreds or thousands (or more) of resources in a network, a policy
   administrator assigns each resource to one or more roles, and then
   specifies the policies for each of these roles.  The Policy Framework
   is then responsible for configuring each of the resources associated
   with a role in such a way that it behaves according to the policies
   specified for that role.  When network behavior must be changed, the
   policy administrator can perform a single update to the policy for a
   role, and the Policy Framework will ensure that the necessary
   configuration updates are performed on all the resources playing that
   role.

   A more formal definition of a role is as follows:

      A role is a type of attribute that is used to select one or more
      policies for a set of entities and/or components from among a much
      larger set of available policies.

   Roles can be combined together.  Here is a formal definition of a
   "role- combination":

      A role-combination is a set of attributes that are used to select
      one or more policies for a set of entities and/or components from
      among a much larger set of available policies.  As the examples
      below illustrate, the selection process for a role combination
      chooses policies associated with the combination itself, policies
      associated with each of its sub-combinations, and policies
      associated with each of the individual roles in the role-
      combination.



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


   It is important to note that a role is more than an attribute.  A
   role defines a particular function of an entity or component that can
   be used to identify particular behavior associated with that entity
   or component.  This difference is critical, and is most easily
   understood by thinking of a role as a selector.  When used in this
   manner, one role (or role-combination) selects a different set of
   policies than a different role (or role-combination) does.

   Roles and role-combinations are especially useful in selecting which
   policies are applicable to a particular set of entities or components
   when the policy repository can store thousands or hundreds of
   thousands of policies.  This use emphasizes the ability of the role
   (or role- combination) to select the small subset of policies that
   are applicable from a huge set of policies that are available.

   An example will illustrate how role-combinations actually work.
   Suppose an installation has three roles defined for interfaces:
   "Ethernet", "Campus", and "WAN".  In the Policy Repository, some
   policy rules could be associated with the role "Ethernet"; these
   rules would apply to all Ethernet interfaces, regardless of whether
   they were on the campus side or the WAN side.  Other rules could be
   associated with the role-combination "Campus"+"Ethernet"; these rules
   would apply to the campus-side Ethernet interfaces, but not to those
   on the WAN side.  Finally, a third set of rules could be associated
   with the role-combination "Ethernet"+"WAN"; these rules would apply
   to the WAN-side Ethernet interfaces, but not to those on the campus
   side.  (The roles in a role-combination appear in alphabetical order
   in these examples, because that is how they appear in the information
   model.)

   If we have a specific interface A that's associated with the role-
   combination "Ethernet"+"WAN", we see that it should have three
   categories of policy rules applied to it:  those for the "Ethernet"
   role, those for the "WAN" role, and those for the role-combination
   "Ethernet"+"WAN".  Going one step further, if interface B is
   associated with the role- combination "branch-
   office"+"Ethernet"+"WAN", then B should have seven categories of
   policy rules applied to it - those associated with the following
   role-combinations:

      o "branch-office"
      o "Ethernet"
      o "WAN"
      o "branch-office"+"Ethernet"
      o "branch-office"+"WAN"
      o "Ethernet"+"WAN"
      o "branch-office"+"Ethernet"+"WAN".




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


   In order to get all of the right policy rules for a resource like
   interface B, a PDP must expand the single role-combination it
   receives for B into this list of seven role-combinations, and then
   retrieve from the Policy Repository the corresponding seven sets of
   policy rules.  Of course this example is unusually complicated:  the
   normal case will involve expanding a two-role combination into three
   values identifying three sets of policy rules.

   Role-combinations also help to simplify somewhat the problem of
   identifying conflicts between policy rules.  With role-combinations,
   it is possible for a policy administrator to specify one set of
   policy rules for campus-side Ethernet interfaces, and a second set of
   policy rules for WAN-side Ethernet interfaces, without having to
   worry about conflicts between the two sets of rules.  The policy
   administrator simply "turns off" conflict detection for these two
   sets of rules, by telling the policy management system that the roles
   "Campus" and "WAN" are incompatible with each other.  This indicates
   that the role combination will never occur, and therefore conflicts
   will never occur.  In some cases the technology itself might identify
   incompatible roles:  "Ethernet" and "FrameRelay", for example.  But
   for less precise terms like "Campus" and "WAN", the policy
   administrator must say whether they identify incompatible roles.

   When the policy administrator does this, there are three effects:

   1. If an interface has assigned to it a role-combination involving
      both "Campus" and "WAN", then the policy management system can
      flag it as an error.

   2. If a policy rule is associated with a role-combination involving
      both "Campus" and "WAN", then the policy management system can
      flag it as an error.

   3. If the policy management system sees two policy rules, where one
      is tied to the role "Campus" (or to a role-combination that
      includes the role "Campus") and the other is tied to the role
      "WAN" (or to a role- combination that includes the role "WAN"),
      then the system does not need to look for conflicts between the
      two policy rules:  because of the incompatible roles, the two
      rules cannot possibly conflict.











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


                        +-------------------+
                        | Policy Repository |
                        +-------------------+
                                  V
                                  V retrieval of policy
                                  V
                             +---------+
                             | PDP/PEP |
                             +---------+
                                  v
                                  v application of policy
                                  v
                          +----------------+
                          | Network Entity |
                          +----------------+

             Figure 4.    Retrieval and Application of a Policy

      Figure 4, which is introduced only as an example of how the Policy
      Framework might be implemented by a collection of network
      components, illustrates how roles operate within the Policy
      Framework.  Because the distinction between them is not important
      to this discussion, the PDP and the PEP are combined in one box.
      The points illustrated here apply equally well, though, to an
      environment where the PDP and the PEP are implemented separately.

      A role represents a functional characteristic or capability of a
      resource to which policies are applied.  Examples of roles include
      Backbone interface, Frame Relay interface, BGP-capable router, web
      server, firewall, etc.  The multiple roles assigned to a single
      resource are combined to form that resource's role combination.
      Role combinations are represented in the PCIM by values of the
      PolicyRoles property in the PolicyRule class.  A PDP uses policy
      roles as follows to identify the policies it needs to be aware of:

      1. The PDP learns in some way the list of roles that its PEPs
         play.  This information might be configured at the PDP, the
         PEPs might supply it to the PDP, or the PDP might retrieve it
         from a repository.

      2. Using repository-specific means, the PDP determines where to
         look for policy rules that might apply to it.

      3. Using the roles and role-combinations it received from its PEPs
         as indicated in the examples above, the PDP is able to locate
         and retrieve the policy rules that are relevant to it.





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


5.2.2. The PolicyRoles Property

   As indicated earlier, PolicyRoles is a property associated with a
   policy rule.  It is an array holding "role combinations" for the
   policy rule, and correlates with the roles defined for a network
   resource.  Using the PolicyRoles property, it is possible to mark a
   policy rule as applying, for example, to a Frame Relay interface or
   to a backbone ATM interface.  The PolicyRoles property take strings
   of the form:

      <RoleName>[&&<RoleName>]*

   Each value of this property represents a role combination, including
   the special case of a "combination" containing only one role.  As the
   format indicates, the role names in a role combination are ANDed
   together to form a single selector.  The multiple values of the
   PolicyRoles property are logically ORed, to make it possible for a
   policy rule to have multiple selectors.