Policy Based Management of Telecommunication Networks

madhur@research.bell-labs.com

Madhur Kohli Bell Labs

jlobo@research.bell-labs.com

Jorge Lobo Bell Labs

Preliminary Report

1 Introduction
Network management can be split into ve probably interrelated branches: fault management, con guration management, performance management, security and accounting.1 Many network management activities are carried out by enforcing policies about the behavior of the resources in the network 17 . Policies can be speci ed at di erent levels of abstraction. At a very high level we can nd policies speci ed using natural language. There are, however, many of these policies that can be formulated as sets of lowlevel rules that describe when and how to recon gure a device or how to manipulate the di erent network elements under di erent network conditions 10 in order to achieve certain management goals. Management in telecommunication networks and data networks is not much di erent. Consider, for example, call gapping. Gapping is the time interval necessary between requests sent to a telephone switch signaling control point SCP in order to process the requests on time. A typical policy would say that if the average gapping of a trunk group is larger than a given threshold say g in the last ve hours, the following calls must be re-routed to a di erent trunk until the gapping is reduced. Policies can also be used during fail-overs. For example, if the gapping increases because of a malfunction of a SCP, a policy could automatically set up a backup SCP to take over part of the load. Another example is the setting of modem pools of an Internet Services Provider ISP. The ISP assigns a telephone number to each customer. All numbers share the same pool. There are n modems in the pool. There can be simultaneous connections from the same customer to the pool. All modems in the pool are shared by all customers but the server can be con gured to limit the connections per number. A policy can describe how these limits change according to the time of the day and the class and the location of the customer. The use of general purpose languages to write policies makes for e cient implementations but may require a lot of programming e ort. Our approach has been to design a Network Management System around a very simple but expressive policy description language called PDL. Policies in PDL are primarily de ned by rules of the form:
event causes action if condition

1

A policy rule has the typical reading of the event-condition-action rules found in active databases: if the event occurs in a situation where the condition is true then the action will be executed. Events are generated by the various network elements. The conditions are checked against the state of the network environment and actions usually yield a series of network device dependent commands. The general framework of a rule based policy server can be roughly described as follows: There is an event or a series of events that occurred
1

This classi cation was introduced by the IOS Network Management Forum.

in the network. These events trigger a rule or a group of rules that start a collection of actions or activities directed to address one or several of the management tasks. Consider the following scenario.

Example 1 This example is from 12 and deals with fault management. There is a DECnet network with a workstation named S that also acts as a router. S is connected with a serial line to a similar router named P . S is located in a small branch o ce while P is a concentrator node at a central location. Suddenly there is a burst of tra c through S that causes the memory allocated for networking to over ow and the system crashes. P detects that the link has failed and sends a critical network event to the network failures policy manager. The policy manager after receiving the event starts the following process. 1 It tries to determine if the serial interface still has a carrier signal a continuous signal that carries basic information on the serial connection. 2 If there is no carrier signal the manager can decide the link is not operational. Because of the nature of the failure in our example, the carrier signal still exists. However, link drivers may send a carrier signal ignoring the state of the link. 3 To check further the state of the link, the serial interface in P is put in a loopback to check P 's side of the link. In addition, other hardware level tests are run on P to check the status of the link. After all the checks complete, the manager reports that there is a failure in S or the S side of the serial link is broken.
In this example the event that triggers the activities is very simple: the critical network event. In general, these events could be quite involved as in the gapping example above. However, the example also shows that the coordination of the activities that must be executed after a policy rule is triggered is more than a simple sequence of actions. The problem has the typical characteristics of the execution of activities in a work ow system. A work ow is loosely de ned as a collection of coordinated activities designed to achieve a goal 6 . The activities are run across di erent platforms and might include activities performed by humans. In addition to PDL, we have developed a script language to write work ows for network management. Our goal in this paper is to present a general overview of our policy based telecommunication network management system. The paper has three parts. In the rst part we review PDL, the policy language. The second part describes the script language for work ows. The last part describes the general architecture of the system. We have some concluding remarks in Section 5.

2 PDL
A PDL program consists of a nite collection of expressions of two types: policy rule propositions which are expressions of the form of Eq. 1 and policy de ned event propositions which are expressions of the form

event triggers pdem1 = t1 ; : : : ; mk = tk  if condition

2

Similar to policy rules, a policy de ned event proposition reads: If the event occurs under the condition the policy de ned event pde is triggered. The event might be primitive or complex. Primitive events can be seen as the names of simple Java classes. The attributes of these classes are integers, oats, strings, etc, or simple data structures such as stacks, or queues, etc. There are standard attributes in every primitive event class such as time and location such as an URL of the source of the event. There are two types of primitive events, system de ned primitive events and policy de ned events. System de ned events are generated by the environment whiles policy de ned primitive events are only generated by the policy according to the policy de ned event propositions. In the policy de ned event proposition above, the mi 's are the attributes of the policy de ned event pde and their values are the ti 's. The ti 's can be attributes from other primitive events that appear in the event, they could be constants or the result of operations applied to the attributes of the other primitive events in the proposition. Complex events can be disjunctions or conjunctions of primitive events. Given the events e1 ; e2 ; : : : ; en , we will denote the conjunction by e1 &e2 & : : : &en and the disjunction by e1 je2 j : : : jen . An event e can also be negated and it will be denoted by !e. Negated events can also appear in the disjunctions and he conjunctions of events. A policy only observes instances of events mentioned in the rules of the policy. 2

Policy de ned events are local to the policy. Several event instances can be input simultaneously to a policy in a single set. This set is called an epoch. It is assume that there is an instance of the special event null in every epoch. The input of a policy is an in nite sequence of epochs called a history. When a policy de ned event is triggered, the event is added to the immediately following epoch. Epochs do not need to occur at same time intervals. The action can be viewed as a remote procedure call that will directly a ect the state of a device in the network or the invocation of a network work ow. Events so far can only refer to instances of events that occur in a single epoch, but we could have composite events that refer to several epochs simultaneously. For example, the sequence loginFail; loginFail; loginFail may represent the event: three consecutive attempts to login that result in failure." In general e1 ; : : : ; en,1; en may represent the moment when an instance of the event en occurred in the current epoch, immediately preceded by an instance of the event en,1 i.e. an instance of en,1 occurred in the previous epoch, : : : , with an instance of the event e1 occurring n , 1 epochs ago. We can describe many classes of sequences if we borrow the notion of a sequence of zero or more events from regular expressions. We will denote zero or more occurrences of an event E by ^E ". It is assumed that each action generates an event indicating success or failure. An action can generate other events but no assumptions are made about them. Arguments of the action are similar to the ti 's. The condition is a sequence of predicates of the form tt0 , where t and t0 are de ned as the ti 's above and  is a comparison operator such as , =, , etc. There are two more basic operations in PDL. The rst one deals with several instances of an event in an epoch. For a complex event e1 &e2& : : : &en resp. e1 je2 j : : : jen , the event groupe1 &e2& : : : &en resp. groupe1 je2 j : : : jen  represents a single event grouping all the instances of the event e1 &e2 & : : : &en resp. e1 je2 j : : : jen  in the epoch. For example, if there are m instances of event e1 in an epoch instances di er in the values of their attributes, and n instances of e2 , there is only one of the event groupe1 &e2  instead of m  n. The second operator is the aggregation operation Count. We extend the terms with terms of the form Counte; e:attt. Here e is a primitive or policy de ned event, att is an attribute of e,  is a comparison operator and t a term. These aggregations terms are usually paired with a group operator or a caret ^" operator in the event. It counts the number of instances of e in the group that satis es the condition. Aggregations do not need to be limited to count. We can also handle aggregations such as max, min, average, etc. A complete description of the language and its semantics can be found in 14 . Most of the general concepts are coming from the database research in active databases languages. Although the semantics was inspired by automata theory and action description languages in AI. Let's go back to the ISP example and assume there are two customers. We have assigned the number 5559991 to Customer1 and the number 5559992 to Customer2. We have 20 modems in our pool. We would like to allow a maximum of 15 connections to Customer1 during the day and 5 to Customer2. During the night we will allow a maximum of 10 to each customer. The event to monitor is time. We will have a symbol associated with this event, say CoarseTimeEvent. This symbol represents a class of events for which instances occur four times a day, at 6:00am, 12:00pm, 6:00pm and 00:00am. In the condition part of the propositions describing the policy we will need to check when an instance of the event occurs to take the appropriate action. Thus, we will extend the CoarseTimeEvent with an attribute named Time. Time will be the enumerated type f morning", noon", evening", midnight"g. We will use one action in the example, ModemPoolAssigment. The signature of this action is Telephone Numbersf1; 2; : : :; 20g. When this action is executed the con guration of the pool is changed to limit the maximum number of connections of the telephone number given in the rst argument to be the number given in the second argument. The following two propositions cover the actions required in the morning:

CoarseTimeEvent causes ModemPoolAssigment5559991; 15 if CoarseTimeEvent:Time = morning": CoarseTimeEvent causes ModemPoolAssigment5559992; 5 if CoarseTimeEvent:Time = morning":
3

Similarly, there will be two more rules in the policy that will set the number of modems to 10 for both customers in the evening. Let's look at a more complicated example. Suppose we characterize overload as an excessive number of signaling network time-outs over calls made, let say at a ratio of t. If an overload occurs some call requests must be rejected until the time-out rate goes down to a reasonable number, say t0 . We can de ne this policy as follows.

Events: normal mode : policy de ned event; restricted mode : policy de ned event; call made; and
time out.
The events do not have attributes.

Actions: restrict calls, accept all calls Policy description: triggers restricted mode if Counttime out t  Countcall made: restricted mode causes restrict calls: restricted mode; ^call madejtime out triggers normal mode if Counttime out t0  Countcall made: causes accept all calls: normal mode
normal mode; ^call madejtime out
We assume that when the system starts the primitive event normal mode is triggered. This can be accomplished by adding the event proposition power on triggers normal mode" to the policy description. The complex event triggering the rst policy de ned event proposition occurs in an event history in which there is an epoch with an instance of the normal mode event, followed by a sequence of epochs where there is an instance of either the event call made or time out in each epoch in the sequence. The restricted mode event will be triggered the rst time that the condition in the event de nition is true. Note that as far as this policy is concerned there are only four types of events. There is a special function symbol in the conditions of the policy description: Count". This function symbol is a temporal aggregate that evaluates over the sequence of primitive event occurrences that form the complex event. In the example, the aggregate is used to count the number of occurrences of the events time out and call made in the sequence. In general, a temporal aggregate has the structure of a function call with a primitive event symbol or an attribute of a primitive event symbol as its argument. Typical temporal aggregates are Sum, Avg, Min, Max, etc. The condition in the rst policy de ned event proposition is true as soon as in the instance of the complex event the number of time out events is larger than the number of call made events times t. The example above assumes that there can only be one call made event or time out event in each epoch. If several calls or time outs happen simultaneously there will be several instances of the complex event in the history. For example, in the history with the sequence of epochs

fnormal modeg, fcall madeg, ftime out; call made; call madeg, fcall made; call madeg
there are six instances of the complex event normal mode; ^call madejtime out occurring at the last epoch of the history.2 The intention of the policy is to group these instances into a single instance and count the timeouts and the calls made in the whole group. This is captured if the policy is de ned in terms of the
fcall
2

There are three instances of the event call madejtime out in the epoch ftime out, call made, call madeg, and two in made; call madeg.

group operator as followed: normal mode; group^call madejtime out triggers restricted mode if Counttime out=Countcall made t: restricted mode causes restrict calls: restricted mode; group^call madejtime out triggers normal mode if Counttime out=countcall made t0 : normal mode causes accept all calls:
We use the notation groupE , for a complex event E , as the shorthand of the event that results after replacing any basic event e in E with groupe.

3 The work ow language

In this section we describe the language of work ows to specify complex actions. The language consists of four types of symbols: a set N of action or activity symbols, a set of exogenous event symbols, a set of endogenous event symbols and a set of local work ow event symbols. Exogenous events are unsolicited events sent to the work ow that might change the ow control of the activities. Endogenous events are events generated by the work ow to possible a ect the ow of sub-activities invoked by the work ow. There is also a set of standard domains and types such as integers, oats, string of characters, etc. Activity symbols are of di erent arities. There might be symbols of arity 0. Each activity symbol of arity n denotes the name of an activity that takes n arguments also called parameters each of a particular type. Each argument has an associated type too. There is a distinguished activity name wf in N called the name of the work ow. This activity may appear as an action invocation in a policy rule in PDL. The attributes of wf are called the work ow arguments. The local work ow events are generated by the work ow activities: except for the activity symbol wf that named the work ow there are two local work ow event symbols for each activity name a in N : asucceeds and afails . The event asucceeds will denote that the activity a, invoked by the work ow, terminated successfully. The event afails will occur if the activity a fails to complete its task. Local, exogenous and endogenous event symbols may have attributes and we will use the standard dot ." notation to access the attributes of an event as in PDL. Complex events in the work ow language will be limited to be disjunctions of non-negated simple events and as in PDL the disjunction of e1 through en will be denoted by e1 j


jen . There are four types of statements or propositions in the work ow language, dependency work ow propositions, alert activity propositions, instance termination propositions and con ict work ow propositions. Dependency propositions are expressions of the form:

Start at1 ; : : : ; tj  after event1; : : : ; eventm if condition

3

where a is an activity name di erent from the work ow name wf  of arity j and the ti s are terms of the appropriate type. The condition is like in Eq 1. Each eventi is a local or exogenous event or a disjunction of local or exogenous events. The proposition is said to be well-formed if every event symbol that occurs in any of the terms in the condition or in the arguments of the activity also appears as a single primitive event eventi no in a disjunction this is similar to the safe condition in database queries. We will assume that all the propositions are well-formed this is a easy syntactic check. The proposition says that activity or action a, with the given parameters, can start after event1; : : : ; eventn have occurred if the condition about the attributes of the events is met. We say that this proposition applies to the activity a. We can also write propositions of the form Start at1 ; : : : ; tj  if condition;" Start at1 ; : : : ; tj  after event1 ; : : : ; eventm " and Start at1 ; : : : ; tj " with their obvious meaning. An activation set for an activity a is a nite and totally ordered set of dependency propositions that apply to a. The ordering in the activation set will determine the attributes used during the invocation of 5

an activity if several dependency propositions that apply to the activity are simultaneously satis ed. For the time being we assume that a sub-activity of a complex action will be invoked only once. Later we will address how we handle loops.
Alert activity propositions are expressions of the form

Alert a with eventatt1 = t1; : : : ; attj = tj  after event1; : : : ; eventm if condition

4

a is the name of an activity di erent from wf . The event is an endogenous event of arity j , the atti s are its attributes and ti s are terms of the appropriate type. Each eventi and the condition are like in Eq. 3. The intuitive reading of this proposition is: alert the activity a of event after event1 ; : : : ; eventm have occurred if the condition is met. If a is not active the proposition has no e ect.
Instance termination propositions are expressions of the from

Terminate with status after event1; : : : ; eventm if condition

5

The events and the condition are like in Eq. 3. The status can be either failuret1; : : : ; tf  or successt1; : : : ; ts ; the ti s are terms. Informally, the proposition says that a work ow instance will terminate with the given status after event1 ; : : : ; eventn have occurred if the condition about the attributes of the events is met. With the termination the work ow engine looses control over all the sub-activities that the work ow instance has initiated. It is up to the work ow programmer to alert the sub-activities of the termination using alert activity propositions before this proposition is satis ed.
Con ict work ow propositions are expressions of the form:

Never a1 ^ : : : ^ am

6

Each ai in the expression is an activity name. The informal reading of the constraint is: never allow the concurrent execution of the activities a1 ; : : : ; am ." A work ow is a collection of dependency propositions organized in activity sets together with a collection of alert activity propositions and con ict propositions. Note that in contrast to policies in PDL where the events triggering rules are coming from devices around the network, the events that a work ow manipulates are local to the work ow and its sub-activities. The formal semantics of the work ows has been developed using relational transducers. In a relational transducer inputs, outputs and states are represented using relational databases and state transition functions as updates to these databases. We do not have space in this overview paper to present the details but the interested reader can nd the full speci cation in 11 .

Example 2 The situation in Example 1 can be encoded as follows: Work ow: SerialLinkFailureP; S  Start Terminate with Start Start Terminate with Terminate with
CarrierSignalP; S  success link"; P; S; down" after CarrierSignalfails LoopBackP; S  after CarrierSignalsucceeds PhysicalLayerTestP; S  after CarrierSignalsucceeds success link"; S; P; down or"; S; down" after LoopBacksucceeds ; PhysicalLayerTestsucceeds success problems with link in"; P  after LoopBackfails jPhysicalLayerTestfails

No alert or con ict propositions are required in this problem. 6

The language can handle nested or structured work ows since the invocation of an activity by a work ow can result in the invocation of a new work ow as long as the main work ow is informed of the termination condition of the sub-work ow. However, there are situations where we would like to repeat operations. A simple but common example is to retry an activity if the activity fails. To incorporate loops we add to the dependency propositions expressions of the form:

Restart wf t1 ; : : : ; tn after event1; : : : ; eventm if condition

7

where wf is the name of the work ow. The work ow is supposed to be of arity n. The ti s are terms of the appropriate type. The events and the condition are like in Eq. 3. The reading of the proposition is: restart the current instance of the work ow after the events occurred if the condition is met. Similar to the termination proposition, it is up to the work ow programmer to alert the sub-activities initiated by the previous instance before a dependency proposition of this form is satis ed. If the programmer nds it convenient to leave several iterations running simultaneously the engine will allow it.

Example 3 Assume there is an activity a that should be retried until it nish successfully. We can create
a sub-work ow wfa with the propositions:

Start a Restart wfa after afails Terminate with success after asucceds
The work ow will call wfa as an activity and this will do the iterations. We could add attributes to the work ow to limit the number of iterations, let say, by adding timeout events.

4 The policy server

In this section we describe a distributed policy execution environment. This system executes PDL policies for network management. It is implemented in Java and is currently being used for Operations, Administration, Maintenance and Provisioning in several carrier-grade communication networks.

4.1 Architecture
A policy is composed of a set of PDL rules which specify the desired behavior of some resources in the network. These event-condition-action or event-condition-event rules de ne the events and conditions that must occur for an action or event to be triggered. Events are generated by devices or software systems in the network to track changes in their state. Actions can be simple device speci c actions to be executed at a given device system or work ows of simple actions as de ned in the previous sections. Each work ow is implemented as a PDL policy where the actions are the component actions of the work ow and the events are the success, failure and other events raised by the execution of these components. The distributed policy based management system we have built consists of a collection of cooperating policy enabled nodes called Policy Elements. These policy elements communicate using events and actions. Every policy induces a hierarchical view of policy elements. The nodes in this hierarchy cooperate to enforce the given policy. The leaf elements of this hierarchy interface various hardware software elements in the network to the policy server. There is at least one leaf element in every policy server. Interior elements coordinate between leaves and or other interior elements. There may be zero or more interior elements in any given policy server. Any policy element can be simultaneously part of many policy servers, i.e. cooperating in the enforcement of several policies concurrently e.g. a work ow that is invoked as an action by several 7

Figure 1: Policy Server

Figure 2: Architecture

other work ows. The policy elements are implemented in Java with the exception of some network device speci c modules. Every policy speci es a set of domains to which it applies. These are property based speci cations of the elements to which the policy may be applicable. This is one of the factors which determines the particular elements that participate in a particular policy execution. Domains are not directly pertinent to work ow execution, but are important for the simple actions which compose a work ow. This is because these actions have meaning at speci c elements only. For example, setting a route makes sense for routers irrespective of manufacturer but not hubs. Every policy element consists of several sub-systems or services. Each of these performs a speci c policy management role. 1. Policy Engine which manages the registration and execution of policies. Whenever an element is selected to participate in a policy execution it is provided the sub-policy that it is responsible for. This is installed in the policy engine which routes appropriate events to it and actions from it. 2. Action=Workflow Manager which processes action work ow requests. Actions triggered from the policy engine are routed to the action work ow manager which determines where the action is to be executed and sends the appropriate request.

Figure 3: Interior Element In addition to the common parts of the policy element, interior elements have: 1. Domain Distributor which determines the appropriate policy elements to receive particular action requests and policy registrations. Leaf elements have several specialized services which allow them to interface to devices and systems in the network. 1. Action Mapper which maps action requests from policies to actual device speci c commands to be performed by the device. 9

2. Event Mapper which converts world device speci c events into policy events. 3. Event Filter which only passes events that are desired by some policy. Any event that no policy has expressed interest in is discarded by the lter. 4. Domain Filter which dynamically determines if this leaf element is indeed part of the action or event domain speci ed by the policy. If this is not so the event or action is ignored.

Figure 4: Leaf Element

4.2 Policy Registration

When a new policy is introduced into the network, it is analyzed and a policy element is chosen as the root of the hierarchy which will enforce this policy. The policy is then registered with this element. This results in it being decomposed into a local coordination part and several sub-policies which will cooperate to realize the policy goals. Actions for the local policy are registered with the action work ow manager of that element. An evaluator for it is also started in the local policy engine. The remaining sub-policies are distributed to policy elements which form the next level in the policy server hierarchy for this policy. Each of these elements performs the same registration steps speci ed above. This process terminates when the element being registered with is a leaf element. Leaf elements do not perform a policy decomposition step. Instead, they register events desired by the local policy mapped from world events with their event lter. They also register the domain expressions speci ed in the policy for actions and events with the local domain lter. This allows the dynamic determination if the policy is still applicable to this element.

4.3 Policy Execution

Policy execution is initiated by world events at leaf elements. Changes in the state or resources of network elements devices or systems result in a set of world events. These events are mapped to a canonical form 10

called a policy event. Those policy events which are desired by some policy are passed through the event lter to the domain lter. The remaining events are discarded. This restricts the set of events seen by a policy to be exactly those which it wants to see. Every event registration has an associated domain of applicability as de ned by some policy. The domain lter discards all events whose domain membership constraint is not satis ed, e ectively disabling the policy in this element. Any event that survives both event and domain lters is delivered to the policy evaluator. When the event expression and condition of any rule in the policy are satis ed the evaluator requests the action work ow manager to process the associated action for that rule. This action may represent an action to be executed at some element or an event to be delivered to some element including itself. In the case of a leaf element these actions may map to some sequence of world actions which would act on hardware software entities in the network. This behavior is repeated at all elements in the hierarchy to which events are delivered in this step.

4.4 Work ow Execution

Having the implementation of the policy server gives us the work ow engine for free. What we have done is to write a translator of work ow scripts into policies in PDL. A start event is associated with each work ow. When a policy is registered with some policy engine, all the work ows in the policy and their start events are registered with the action work ow manager of that element. The invocation of an action corresponding to the work ow results in the action work ow manager registering the policy implementing it and then raising the appropriate start event to the element where the work ow is to be executed. The execution of the work ow proceeds by invoking the actions triggered by the start event and feeding back the success and failure events of these actions to the PDL program. This in turn res some rules resulting in the execution of other component actions. This process repeats until the work ow is completed which results in its success or failure event being raised to the element which originally invoked the work ow.

Directories: We would like to mention that the implementation makes intensive use of directory technology to store static and semi-static data. The di erent parameter con gurations of the policy elements are stored in a Lucent Directory Server LCDS. Similarly, event schemas are store in LCDS. Domains are resolved by querying the directory. We are also planning to store action schemas and device speci c event mappings to policy events in the directory. We envision a system manager de ning a policy in two steps. First, the manager will consult a directory server to obtain: 1 the set of events that the system is able to monitor 2 the set of actions that can be invoked by a policy and 3 the set of functions that system supports to evaluate the status of the environment. Then the manager will write policies by combining events, actions and functions from the directory and store them back in the directory. The policy server will consult the directory server to bring up the policies to be enforced. The stability of the information will support recovering from failures of the di erent components of the policy server.

5 Final remarks
The PDL language combines ideas from three di erent sources, the action languages of Ge ner and Bonet 7 , the action language of Gelfond and Lifschitz 8 , and the composite temporal event language for active databases of Motakis and Zaniolo 16 . We should also mention that complex events similar to ours have been used in other languages in the past see for example 13, 9 . The semantics of PDL was inspired by the automata-based semantics of action theories 2, 8 and their application to active databases 3, 4 . A full description of the language can be found in 15 . The semantics of the work ow language is described using relational transducers 1 and is described in 11 . Relational transducers are state machines based on the relational database model. This paper also describes the translation of work ow scripts to PDL. A 11

more detailed description of the architecture of the system being used to do Operations, Administration, Maintenance and Provisioning in a carrier-grade communication network can be found in 5 .

References
1 S. Abitaboul, V. Vianu, B. Frodham, and Y. Yesha. Relational transducers for electronic commerce. In Proc. 17th ACM SIGACT SIGMOD Symposium on Principles of Database Systems, 1998. 2 C. Baral, M. Gelfond, and A. Provetti. Representing Actions: Laws, Observations and Hypothesis. Journal of Logic Programming, 311-3:201 244, 1997. 3 C. Baral and J. Lobo. Formal characterizations of active databases. In D. Pedreschi and C. Zaniolo, editors, Logic in Databases, number 1154 in Lecture Notes in Computer Sciece, pages 175 196. Springer, Italy, July 1996. 4 C. Baral, J. Lobo, and G. Trajcevski. Formal characterizations of active databases: II. In Proc. of the International Conference on Deductive and Object Oriented Databases, Lecture Notes in Computer Sciece. Springer, Switzerland, December 1997. 5 R. Bhatia, M. Kohli, J. Lobo, and A. Virmani. A policy-based network management system. In Proc. of the International Conference on Parallel and Distributed Techniques and Applications International Conference on Arti cial Intelligence, June 1999. 6 The Work ow Management Coalition. Terminology and glossary. Technical Report WFMC-TC-1011, The Work ow Management Coalition, June 1996. 7 H. Ge ner and B. Bonet. High-level planning and control with incomplete information using POMDP's. In Working notes of the 1998 AAAI fall symposium on Cognitive Robotics, October 1998. 8 M. Gelfond and V. Lifschitz. Representing action and change by logic programs. Journal of Logic Programming, 17:301 321, 1993. 9 R. E. Gruber, B. Krishnamurthy, and E. Panagos. High-level constructs in the READY event noti cation system. In 8th ACM SIGOPS European Workshop, Sintra, Portugal, September 1998. 10 M. Z. Hasan. An active temporal model for network management databases. In IFIP IEEE 4th International Symposium on Integrated Network Management, pages 524 535, Santa Barbara, California, May 1995. 11 M. Kohli and J. Lobo. Work ow in network management, 1999. Submitted for publications copies can be obtained from the authors. 12 A. Leinwand and K. F. Conroy. Network Management: A practical perspective. Addison Wesley, second edition, 1996. 13 D. F. Lieuwen, N. Gehani, and R. Arlein. The Ode active database: Trigger semantics and implementation. In Proc. of ICDT, pages 412 420, New Orleans, LU, February-March 1996. 14 J. Lobo, R. Bhatia, and S. Naqvi. A policy description language. In Proc. of AAAI, Orlando, FL, July 1999. 15 J. Lobo, R. Bhatia, and S. Naqvi. A policy description language. Technical report, Bell Labs Report, 1999. To appear in AAAI99. 16 I. Motakis and C. Zaniolo. Temporal aggregation in active database rules. In Proc. of SIGMOD, Tucson, AZ, May 1997. 17 R. Wies. Policies in network and system management - formal de nition and architecture. Journal of Network and System Management, 21:63 83, 1994. 12