Subject: The very last time I promise you will have to read this -

From: "Ken Roberts" <[email-masked]>
Date: Mon, 26 Apr 1999 14:35:06 -0700

My very sincere apologies to all folks who have been able to read this mail previously, it seems as though technology has progressed only far enough that text files are the universal denominator and here I thought that when the ITU-T got their minds around WORD everyone must be able, Wrong again.

OK OK OK enough already you will have to imagine what the diagrams look like - the important bits are the words but as they say a picture is .... etc. Oh well some times its best to stay in bed.

Regards,

Ken

Group,

Been watching the thread/ discussion on policy and state and its time to wade in again. For this discussion I need to define some terms:

  1.. Management domain (MD): a set of entities grouped for some [management] purpose,
  2.. Management policy (MP): a set of zero, or more, rules that when computed yield a result.
  3.. Management jurisdiction (MJ): a relationship between a management policy and a set of managed entities.
A few more contentious statements:

  1.. MP rules are not cast in the context of entities that may be affected by the rule.
  2.. MD are grouped without regard to the rules that may/ may not affect them.
Now lets get to the fun part. The discussion has centered on how a rule should determine the current state of an entity. I submit it shouldn't! Not only it is irrelevant t it violates the "separation of function" concept. Let me illustrate if we consider the problem in another context, I reside in Santa Clara, CA, USA. I'm therefore subject to the "rules" of Santa Clara county, the state of California and the country of the USA (possibly those of the World Court as well but you get the idea). Now each of those "rule" are crafted without regard to me as an individual and indeed I would be surprised (and horrified) if they identified me by name. The rules specify what is expected by ANY resident within their jurisdiction and cascade from the "higher" authority to the lower becoming more specific as the go, an (unfortunate) example of this is taxes.

The above illustrates the "separation of function" regarding specification and execution and reflects the inherent properties of the data types specified. All this really means is the information is normalized in the model. When this is done correctly it results in among other things in re-usable specification.

Lets return to the problem - how to understand whether "John" is logged on or not for the application of a rule.

  1.. We define a MD for all entities that are "logged on".
  2.. We define an MP for "security violation" with actions for "logged on" Vs unauthorized entities.
  3.. When John logs on a notification is sent to the MD as a result of his authentication.
  4.. The MD "enroll" John as a logged on entity. This allows John to log-on from anywhere in the network with the same result.
  5.. John executes a security violation by trying to access sensitive information.
  6.. The above step triggers the MP for security violation.
  7.. The "rule" is crafted: "If entity is logged on THEN action1 ELSE action2."
  8.. To evaluate whether the entity is logged-on a membership query is sent to the MD.
  9.. The MD responds either TRUE or FALSE and the appropriate action is executed. 
What has been specified above allows the rule to be reused in different contexts, by altering the MD the MP is related to the context within which the MP applies is altered without changing either the MP or he MD. For example, if the MD that is related to the MP specifies "logged on" entities then the rule applies to those entities that are logged on; if the MD specifies entities that are red in colour then the rule applies to those entities and so forth. The separation of function (the application of rules, the specification of a community of interest and relationships between them) forms an extremely powerful capability.

State information is therefore NOT intrinsic within a rule it is indirectly linked to a rule via a MJ. The problem of currency therefore shifts to MD membership accuracy. Since we are discussing a "scaleable" solution whatever mechanism clearly cannot access a NE in real-time (in a large network environment) a "window of exposure" must be accepted - this window is minimized by standardizing the behaviour of entities (example the emission of a log-on notification above). Alternative schemes (polling based) may be practical for small environments but don't scale, the suggested method may be "overkill" in small environments but does scale.

The above mechanism is described in the International Standard on policy and domains, ISO/IEC 10164 - part 19 or the twinned technically aligned recommendation ITU-T X.749. These documents are written in normal "standard-eze" and I have attached a brief English translation for your convenience below.

Thanks for your patience in reading so far,

Ken

=========================================================================

Management by Business Objective

Application of Policy to the Domain of Management 

Abstract: 

It has become fashionable today to discuss the application of "policy" to the management of computer networks. This paper discusses this notion and comments on how it may be implemented and some of the challenges this paradigm poses to solution providers.

Table of Content

Introduction *

Management Policy *

Management Domain *

Management Jurisdiction *

Putting it all together *

Conclusion *

Management by Business Objective

Application of Policy to the Domain of Management 

Introduction

Many network administrators desire the ability to manage their environments from a "business" perspective using tools that allow this perspective to be implemented.

Historically management has been accomplished using tools that allow "device" management. The correlation of information from a device to a business aspect being done by humans, examples of this correlation are; a hardware technician wants to perform maintenance on a disc drive, is it consistent with overriding corporate objectives to take the drive down for maintenance now? This type of question is answered by humans who must weigh the advantages of performing the maintenance against the loss of a drive for a period of time, the impact on the business is evaluated and a decision is made. 

Why can’t the management system do this? On the surface it is simple enough we know how long it takes for maintenance, we know the time of day/ day of month, we know the business objectives for the aforementioned time/ day can we not simply reduce these "known" values and compute an answer? The issue is do "we" know the full import of the above, usually not. In the majority of organizations the folks who drive the network are not the folks who make policy, this leads to an interpretation exposure where the translation of policy into machine evaluation form may be flawed. Thus incorrect results are obtained.

To reduce the above "window of exposure" it is required to directly input policy into a machine-readable form. Herein is the difficulty! Senior executives those, who make policy, usually have little time, or inclination, to program a computer. What is needed is a mechanism where discrete programming is not required, the information transfer being accomplished using a lexicon defined by the user (in this case the senior executive).

What we have is a problem requiring a solution enabling policy statements to be successively decomposed from an abstract root to a machine computable leaf that is internally consistent and provides a user defined lexicon. Mechanisms that can take the requisite level of policy decomposition and apply the management policy to an arbitrary set of objects.

Why arbitrary set of objects? How many corporations exist that all policies apply equally to all employees? In the same sense within a network can all policies apply equally to all components? I think not, therefore we require a mechanism to group components into some arbitrary set so the management policy can be applied to them.

This paper discusses Management policy, the grouping of components/ objects (Management domains), and, the application of one to the other (Management jurisdiction).

Management Policy

What is a management policy statement? It can be a number of things ranging from an abstract construct, for example "the objective of this organization is to be profitable" to the specific, for example "class one traffic will have precedence over all other class of traffic".

The more obvious are the statements that can produce a Boolean result. This is typically predicated on some visible property, in the above example it is the class of traffic attribute. The more abstract the statement the more generic are the results, thus negating to an extent the value of the statement, however the intrinsic value remains. For example, the above statement on profitability, whilst not directly computable does have consequences. If the causal effect of an action can be related to profitability, e.g. the effect of enrolling a disc drive into an off-line maintenance management domain is to reduce the order taking ability of the enterprise by 20% within the prime order taking period, then the action is clearly counter to the management policy.

To accommodate the, possibly, many levels of management policy statement a vector or directed structure is required.

The diagram at left shows a directed structure for management policy, we see a root statement (labeled "P1") from which successive statement are derived. In effect what we have is an inheritance structure with a common root. 

This structure supports the capability to verify statement conformance whenever a "new" statement is registered into the structure. This capability is referred to as "static conflict detection" since it will not allow a statement to be registered if it conflicts with a statement already registered higher in the structure. For example if P2 states "all telephones must be black" and P5 states "telephones may be black, white or pastel colored". It is obvious that this type of conflict can be detected during management policy statement (or rule) enrollment and resolved prior to registration. 

Structure within the management policy space is optional Management policy may be ordered as in the example using the properties of inheritance, or they may be "disjoint". Disjoint policies are management policy statements, or structures, that do not share a common root.

Complementing static conflict detection is dynamic conflict detection. In this instance when the management policy rule was registered the conflict was not detectable, for example "response time shall be less than two seconds". Conflicts may arise during operation of the system and must be presented to a "resolution" entity to adjudicate on the anomaly, examples of this type are best discussed after the following discussion on Management domains please refer to following sections for this discussion.

A Management policy Statement can be thought of as a simple or complex "rule". Rules are computational and when executed must halt, producing a binary result; either the rule is TRUE or it is FALSE. Hierarchies of policies may be used to build complex sets of rules, with each management policy "determination level" being a simple or complex rule in itself. 

What is a determination level? Using the above diagram we see the sets {P1}, {P2, P3, P4}, {P5, P6, P7}, {P8, P9}, {P10, P11, P12} and {P13} each are at a determinate level within the hierarchy and we can arbitrarily assign level numbers of 1, 2, 3, 4, 5,and 6 to those levels. If we need to encode a Management policy Statement " Voice traffic has priority over all other traffic during the hours 9-5 locally Monday to Friday except when traffic of any class originates from a director level and above origin". We have options on how to encode this style of management policy; we can encode it as a complex rule with many "IF…THEN…. ELSE" constructs or as a series of simple rules linked together to provide the required statement.

Option 1: The encoded rule would look something like;

Pn = (IF ((traffic_type = voice) AND

(time_of_day >= 9 AND

time_of_day <= 5) AND

(day_of_week >= monday AND

day_of_week <= friday)) 

THEN

TRUE

ELSE

FALSE

ENDIF

Option 2: Using the above management policy structure the encoded rule would look something like;

P1=(IF traffic_type = voice

TRUE

ELSE

FALSE

ENDIF

P2=(IF time_of_day >= 0900 AND

time_of_day <= 1700)

TRUE

ELSE

FALSE

ENDIF

P5=(IF day_of_week >= monday AND

day_of_week <= friday)

TRUE

ELSE

FALSE

ENDIF

The evaluation sequence for the above management policy requires the processing of three determination levels (1, 2 and 3). The benefit of encoding simple rules and then combining them to form complex management policy is that individual rules may be re-used in many policies. For example the rule statement at determination level 1 (i.e., P1) is re-used in the management policy streams P2, P3 and P4 this characteristic may reduce the overall size of the management policy space. However, as depicted above, the decision as to how simple or complex rules are is the prerogative of the user.

If the processing returns a TRUE then the combined rule processing is TRUE, obviously if the return is FALSE then the management policy has failed at one or other determination level. The consequence of a TRUE return is that the action that caused the management policy processing may proceed, as it does not contravene any management policy that may be in force for the object. If a FALSE return is given then the action may not proceed, as it would cause a Management policy Conflict for the object.

Management Domain

What is a management domain? Simply put a management domain is a grouping of things that occurs for some purpose. This is very loose and within the management context the only reason to group things is to apply some management operation to them. The characteristics of management operations on management domains have several properties; they may apply to the group in general (e.g. management policy operations), or they may describe a common characteristic (e.g. on-line printers).

Management domains may have structure. Structure may represent the concepts of Super Management domains, Sub Management domains and Disjoint Management domains.

The diagram, at left, illustrates the above concepts. Shown in the top segment is examples of a Super Management domain (D1) that consists of the Sub Management domains (D2 and D3). Entities may be members of Management domains D1, D1 and D2 or D1 and D3 for the purposes of application of management policy entities may be subject to governing policies at either D1, D1 and D2 or D1 and D3 depending on the enrollment associated with specific entity. Shown in the left segment is an example a Disjoint Management domain, it can be seen the major difference is the governing policies. In this example entities enrolled in D2 are only subject to policies linked to D2 as distinct to the first example. Shown in the right segment is an example of an Overlapping Management domain. Overlapping management domains exist whenever entities may satisfy the enrollment management policy for two, or more, separately defined management domains.

Super management domains provide the capability to group, and apply management policy to, entities that are members of other fully contained management domains.

D1 (members) € (å (D2 (members), D3 (members), D1 (members)))

Sub management domains provide the capability to apply individual management policy to entities that satisfy membership criteria for overarching management domains.

Overlapping management domains provide the capability to apply disjoint management policy to entities that satisfy membership criteria for one, or more separate management domains.

Disjoint management domains provide the capability to apply management policy to entities that are not members of any other management domain.

Entities are enrolled in management domains either statically or dynamically. Static enrollment is quite straightforward an administrator decides to create a grouping of entities, for example all network printers. Populating this grouping with a specific set of known objects (i.e. representations of the corporation’s printers) completes the specification of the management domain. Note in this instance it would be sensible to also create the sub management domains, printers online and printers’ off-line as well.

The latter specification is an example of dynamic management domain enrollment. A specific printer is either online or off-line and will move from one management domain to the other throughout an online day. Note listings of all printers may be obtained by accessing the super management domain, listings of printers either online or off-line may be obtained by accessing the appropriate sub management domain.

Management Jurisdiction

What is a Management Jurisdiction? Simply it is a joint between a [set of] management policy statements and a [set of] objects / entities governed by those management policy(s).

We have discussed the properties of management policy. Throughout the discussion the concept of "shaping" has been introduced, this shaping or behavior "control" is independent of the actual object the control is being exerted over. This is an important concept as it states that objects are unaware of any overt control over them, thus maintaining the properties of an object oriented paradigm. Objects, especially generic re-useable objects, must be free to implement all aspects of their defined behavior. If behavior "modification" is to be done to allow the generic object to function within a specific environment the "modification" must be independent of the object itself. It follows that objects must be unaware of any governing management policy, however objects must be "connected" in a object transparent manner to the governing agency.

Objects exist within the groupings discussed as management Domains. Therefore management domains must be "linked" to management policy via a transparent mechanism. This mechanism is a Management Jurisdiction.

The concept of "linking’ management policy to management domains is illustrated at left. We see an arbitrary management policy structure (P1 through P8) with a management jurisdiction linking management domain (D1) to management policy structure {P4, P3, P1}, a management jurisdiction linking management domain (D2) to management policy structure {P6, P4, P3, P1}, and a final management jurisdiction linking management domain (D3) to management policy structure {P7, P4, P3, P1}.

This example is also illustrates the concepts of Super/ Sub Management domains and how they could be used. For example, the management domain (D1) could represent all networked printers in an enterprise, the management policy structure {P4, P3, P1} being generic statement covering printers in general. The Sub Management domains (D2) and (D3) respectively could represent printers on-line and printers off-line respectively, the subservient policies P6 and P7 providing specific statements concerning on-line and off-line printers respectively. Typical specification could be the rules governing when and how printers could move from one sub management domain to the other.

The three management jurisdictions perform the join and answer the question. "What rules apply to which objects?" In this manner neither the rule nor the object is overtly aware of the other, objects are free to implement whatever behavior their designers see fit and rules are free to govern or shape this behavior as their designers see fit. 

Putting it all together

How does this actually work? Consider the case of a generic object having an attribute supporting three attribute values, red, yellow and green. From the object’s perspective valid transitions from one value to another are as shown. The object therefore would have no problem with accepting a SET operation to alter the value of the attribute from any state to any other state.

Consider an enterprise makes a management policy decision that "no entity within the organization may have a state other than GREEN or RED". Can we no longer use the generic object defined above even though it performs all the requisite functions?

The answer is in creating a management policy rule that reflects the desire of the organization, namely only RED and GREEN states are to be supported, enroll the object in a management domain and connect the management domain to the governing management policy.

What happens is that the object remains perfectly capable of entering the YELLOW state and therefore behaves in accordance with its programming. It just never sees an operation that would cause it to enter the YELLOW state. A management policy conflict detector intercepts these operations, as they would cause a management policy violation. A notification/ semaphore is sent to a management policy conflict resolution entity to adjudicate the situation.

Resolution adjudication could decide to allow the operation and accept the management policy violation, reject the operation or move the management domain residency of the target object such that the operation no longer would violate management domain residency. This adjudication is subject to management policy.

Conclusion

This paper introduces several concepts, management policy, management domains and management jurisdictions. The above discussions illustrate the properties of these concepts and how they inter-operate to provide a new paradigm for management.

This new management paradigm offers end-users more flexibility than ever before in how they interact with their computer environment to provide the required levels of service within an organization.

To illustrate the desirability of this new paradigm, consider the following example. A new human employee is seldom given the opportunity to provide his or her own management environment. They are usually expected to conform to whatever practices that are in force within the organization they join. Why when the new "employee" is a computer (or network) are we willing to concede what isn’t possible in the first instance? Doesn’t every computer come with it’s own set of "policy and procedures" manuals detailing how you are to work with the new device, and, if you don’t follow the procedures the device objects are refuses to work at all. Why is this so? Shouldn’t the computer be subject to the same requirements that a human employee is?

Management policy is an expression of how an organization operates and defines the service levels that are available. As we become more aware of Service Level Agreements (SLA) and the "knock-on" effect outages potentially have on them it becomes increasingly important to be able to relate what is happening at the operational level to what is needed to happen to implement overarching business plans. It is becoming more and more obvious that the correlation of operational events and actions cannot continue to be a function performed by system/ network operator or supervisors.

The capabilities described in this paper when applied complement each other. Management policy without management domains (either de-facto or overtly specified) doesn’t make sense. Management jurisdictions protect the principles and properties of object-oriented design, programming and complement doctrine of leverage and re-use. When used in conjunction with each other, these capabilities realize the next step for management allowing tangible base from which meaningful dialogue for design and development of management products that, provide both a service and business aspect to the management of systems and network environments. 

The inter-relationship between network, service and business oriented management has moved beyond the computer room and requires a "new" paradigm. Management by business objective and the application of management policy to the management domain of management provides this capability. Opportunities abound for the company that can first exploit this challenge. 

Annex

The capabilities described above attempts to provide a real-life-modeling paradigm for use in management. Real-life is much more complex that  described and this reality must be accommodated: this complication exists within both the management domain and management policy spaces.

If management domains are groups of things then the grouping criteria becomes the "interesting" aspect of the concept. Grouping criteria may be thought of as two fundamental types: a simple or enumerated, and a complex or non-enumerated type. 

Similarly, management policy may be thought of as two fundamental types: a [set of] rule statement(s) that when processed using explicit variables provide a result and, a [set of] rule statements that when processed using implicit variables provide a result.

The end result in all instances is the same, however the derivation path to the result is most different.

Grouping criteria

Enumerated management domains

This type of grouping criteria is the easiest and most straightforward. A management domain of interest is constructed with a population list of members expressly given. Examples of this type of management domain are company employees, county/ state/ country residents, etc. the common factor being the management domain members are [relatively] static.

Enrollment and dis-enrollment after the initial establishment may be governed by a "management domain membership" management policy or done via a mechanical means of periodically re-establishing the management domain providing the membership list.

Enrollment criteria may be overt, that is an observable property of an object (i.e. attribute value) or a characteristic, not necessarily an observable property, of the object (for example, the "owning" company name is not an attribute of the employee object). In the latter case membership in the management domain may the only method to deduce what company/ department a given employee work.

Non-enumerated management domains

This type of grouping criteria specifies a "predicate" that when satisfied by an object has the effect of enrolling that object in the management domain. This type of grouping criteria is very powerful in that it provides the capability to specify a management domain of interest without any overt knowledge of the constituency of its members. However, the downside to this specification is that it may take considerable compute power and/ or time to construct an explicit list of members in a dynamic environment, and, once constructed the list may contain inaccuracies depending on the volatility of the environment.

Examples of this type of management domain are: 

  a.. Devices on-line/ off-line,

  b.. Devices with response time excursions, etc.

Explicit management policy

Explicit policies are those where the statements/ rules are directly parse-able without recourse to any information other than what is specified within the rule and/ or passed to the adjudication function. This type of rule can be thought of as the "simple management policy" type.

An example of a explicit management policy statements is: "priority one traffic has absolute priority between the hours 08:00 and 17:00." This statement can return a TRUE/ FALSE response based on the time of day and the priority of the requesting traffic.

Implicit management policy

Implicit policies are those that exist relative to some other management policy and adherence must be computed as a complex operation involving multiple statement/ rules. Adherence may or may not involve values explicit in either the object or the management policy. This type of rule can be thought of as the "complex management policy" type.

An example of a implicit management policy statement is: "priority one traffic has absolute priority between the hours 09:00 and 17:00 if there is no waiting executive originated traffic, and network congestion is less than 5%, and the originating station has nor generated more than 500 messages in the last 60 minutes." This statement can only return a TRUE/ FALSE response after evaluating multiple conditions with each predicate using values other than those originally "passed in" with the request.

This type of management policy is inherently strong in its definition capability, but potentially involves much compute time and/ or power for its evaluation.