policy-based active grid management architecture - CiteSeerX

POLICY-BASED ACTIVE GRID MANAGEMENT ARCHITECTURE K. Yang, A. Galis, C. Todd Department of Electronic and Electrical Engineering University College London, Torrington Place, London WC1E 7JE, UK

ABSTRACT Due to the large scale of Grid environment and its rapid expansion, both in Grid resources and Grid network environment, it is getting more imperative to provide a Grid management mechanism that can enable Grid Computing to adapt to various application requirements in a flexible and automated way. This paper proposes to introduce policy-based management, enhanced by active network, to cope with this challenging requirement. Based on the analysis and comparison of three typical Grid architectures, this paper firstly presents a new view of Grid architecture that emphasizes the policy-based Grid management middleware and active network middleware. Then detailed design of these two middleware is discussed. A case study for controlled and secure massive storage access exemplifies this policy-based active Grid management architecture and shows that an improvement in manageability, automation and flexibility of Grid system can be achieved.

1. INTRODUCTION The term “Grid” was coined in the mid 1990s to denote a proposed distributed computing infrastructure for advanced science and technology. Considerable progresses have been achieved since then [1], among which, Global Grid Forum (GGF) [2] is more representational. Based on the analysis of different types of Grid architectures, this section tends to use Grid management to cope with the challenging interoperability problem widely existing in the Grid application and environment.

1.1 Analysis of typical Grid Architectures Recently, Grid computing is more distinguished from conventional distributed computing by its focus on large-scale resource sharing, innovative applications, under the environment of widely-connected network, i.e., the Internet. In order to support this distinct feature, many Grid architectures are proposed, which can roughly be grouped into three main different types. Layers of increasing abstraction: The services for building Grid system are listed and put into different layers. The higher the layer is, the more abstract the functionality is. The researchers using this method tend not to think in the terms of protocols, because complex services sometimes are difficult to reduce to basic protocols. Services in each layer can use only those in same layer and below (though not immediately below). The benefit of this type of architecture is that new services can be easily composed, whilst the drawback is that complex control of these services needs to be provided in some forms. Furthermore, in most cases, a distinct layering is difficult to be given. The typical

architecture belonging to this type is Globus Data Grid Architecture [3] and taxonomy of building blocks for Grid proposed in Grid Protocol Architecture (GPA) workgroup of GGF. Concept space: this method doesn’t care about the layering of architecture and is more like a flat architecture of different building blocks that are further grouped into metadata, data, resources, services, protocols. The representative of this type is the Data Grid Concept Space proposed by Moore, et al, which is also available at the GPA workgroup of GGF. Hybrid of building blocks and concept space: the typical Grid architecture of this type is the EU Data Grid Architecture [4]. It divides the whole Grid architecture into five layers, each of which has its own concept space. The lowest layer is about authorization and authentication, whereas the highest layer is Grid scheduler mainly used for resource broker and job booking. The purpose of Grid architecture is to set up sharing relationship among any participants such as Grid resources and Grid applications or end-users. Therefore, interoperability is the central issue for Grid architecture. In a highly networked environment, interoperability usually means common protocols. Consequently, more work on protocols defining and implementing is undergoing, e.g., Globus [3], EU Data Grid [4], etc. It is essential to work on protocols, but only protocols can’t flexibly solve the widely existing interoperability problems in Grid environment because every protocol can only cope with problems limited to a specific domain or interface. It is impossible to provide a unique protocol that can be used for any inter-service communication and negotiation or accessing any kind of resources due to the fact that Grid technology covers a wide range of network and computer fields. A Grid Management System (GMS), responsible for either a specific domain or the overall Grid system but following the same architecture and management protocols, can fill the space left by protocols and provide a more flexible way for global interoperability of Grid services and resources. This article aims to enhance the currently Grid architecture by introducing policy-based management and active network technology in the form of middleware.

1.2 Policy-based Grid Management There are yet many architectures for the management of Grid networks and the existing ones are focused on some concrete aspects and do not cover the management of the Grid as a whole, with examples as Condor-G system [5] and Nimrod-G Grid resource broker [6]. Due to the complexity of Grid system, and the trend of getting more complex in both hardware/software and

service requirements, the management of the overall Grid system itself in a flexible way is getting more and more important. But, unfortunately, less work has been done about this. It is timeconsuming and error-prone for Grid administrator or resource manager/broker to configure his system manually. And it is extremely hard for him to configure his local resource while considering other domains in the whole Grid system. Policy-based management (PBM) is very suitable to such a complex management environment. In comparison with previous traditional network management approaches, such as TMN or TINA-C [7], PBM offers a more flexible, customisable management solution, which allows each domain, IP network element, storage and computational elements to be configured on the fly, for a specific application tailored for a customer [8]. The aim of PBM is to apply integrated management system so that system management, network management, and application management can cooperate in Grid computing. Nevertheless, this flexibility doesn’ t come easily. The current PBM architecture has problems in the sense that it can only address fairly limited issues and usually requires human intervention. Active Network, as an enabling technology, can solve many of these problems and enable the automation of management process.

1.3 Active Network for Grid Management

Based on the discussion above, this section proposes a new view of Grid architecture as shown in Figure 1, which is more or less based on the layered structure but with different layering from the GGF architecture and EU Data Grid architecture due to its emphasis on Grid management. In this architecture, Grid Management Layer, together with active network middleware, are introduced. Before going into detail of policy-based Grid management middleware, an overall picture of Grid system architecture and its components are discussed in this section. Application

Weather Forecast

Application Specific Tools

Earth Observation

… Visualization Tools

Biology

…

High-Energy Physics

Instruments Management Tools

Data Publishing Tools

Grid Admin

Policy-based Grid Management Middleware Grid API/SDK

Grid Mngt. Layer

FCAPS Management

Resource Broker

Storage Management

…

(Resource)

SQL/ LDAP service

Resource Resource Resource accounting registration allocation service service service

Resource Management Protocols (Fabric)

Network Resource

Computing Resource

Policy code Download

…

Active Networks EE

…

Active Nodes (ABLE)

Resource Monitoring

Domain-level Policy-based Grid Management Domain CoService Replica Consistency Layer (Collective) Scheduler Registration Catalogue Management

Resource Layer

Most challenging problems in Grid context come from heterogeneity of Grid resources and network elements, sheer largeness and inter-domain complexities of programming environment and service deployment. These problems can be solved in some extent using active network technology. On the other hands, the overhead introduced by programmability should not exceed the benefit. Therefore, manageability of programming environments and ease of deployment has to be taken into

2. A NEW VIEW OF GRID ARCHITECTURE

Grid Supporting Env.

While Active Network research has precisely tackled that problem domain in fixed and wireless network environments, the particular conditions of Grid networks have not sufficiently been taken into account. There isn’ t any evidence so far showing that EU Data Grid project [4] is using active technology to maintain the programmability and activeness of Grid system, though there is a so called “active” node, which is actually an agent in multiagent systems. This project is trying to give a good resolution on task distribution throughout the Grid network, but little attention has been paid to the dynamic and automated distribution of new components and new services.

The content of the paper is structured as follows. Based on the discussion in this section, Section 2 presents a new view of Grid architecture that highlights the Grid management components i.e., policy-based management middleware and active network middleware. Then policy-based Grid management middleware and its enhancement with active network middleware are detailed in Section 3 and Section 4 respectively. An active management of Grid scenario for secure and controlled massive storage accessing evaluates the overall Grid management system in Section 5, and finally leads to the conclusion in Section 6.

Application Layer‘

Active network transforms the store-and-forward network into store-compute-and-forward [9]. The innovation here is that packets are no longer passive but rather active in the sense that they carry executable code together with their data payload. This code is dispatched and executed at designated (active) nodes performing operations on the packet data as well as changing the current state of the node. An active network is distinguished from any other networking environment by the fact that it can be programmed. In this paper, this programmability is fully guided by the policies. Potential benefits of such a capability include faster deployment of new services, the ability to customize services for different applications, and ability to automate the service and management configuration.

account, which can be considered by policy-based management technology. Therefore, the relationship between PBM and Active network technology is bi-directional. On one hand, active network is a kind of enabling technology for policy enforcement; on the other hand, PBM also provides the management of active networks themselves.

Networking Supporting

Storage Resource

…

Scientific Instrument

Figure 1. A New View of Grid Architecture This policy-based active Grid architecture constitutes four layers, with Resource Layer, Domain Layer and Grid Management Layer constituting the Grid Supporting Environment, above which, various Grid Applications are built on Application Layer.

2.1 Resource Layer The objective of the Resource Layer is to develop automated system management techniques that enable the deployment of large computing fabrics under the help of resource services and network supporting with reduced system administration and

operation costs. The Grid architecture proposed by Foster et al [10], which also represents the Grid architecture of GGF, regards the Resource Layer in Figure 1 as three different layers: Fabric layer at the bottom, Resource layer at the top, as shown in Italic fonts in Figure 1, and Connectivity layer in the middle. Since all three different layers mentioned in [10] are about resource and its access control, we put them together as one layer called Resource Layer to leave more space for other important layers that are not mentioned in GGF Grid architecture, such as Management Layer. This also attempts to avoid possible literal confusion it may cause. Please note that active node is built up in this layer to provide the core functionality of active network.

2.2 Domain Layer While the Resource layer is focused on interactions with a single resource, the next layer in the architecture, i.e., Domain Layer, contains protocols and services that are not associated with any one specific resource but capture interactions among resources without any change of lower layers. Because this layer only cares about the resources and the services provided by the corresponding resources within a domain, we refer to this layer as Domain Layer. It is also referred to as Collective Layer by GGF due to the fact that this layer provides relatively collective functionalities among resources instead of just within one specific resource. In this sense, Grid management Layer is also a collective layer but focusing on the whole management of Grid system. Putting both domain layer and Grid management layer into one as so called collective layer will overload one layer, especially in the current situation that more new components are being introduced into these two layers due to the increasing variety of management requirement. The domain layer provides a wide range of protocols and services, for examples: Co-scheduler allows upper level to request the allocation of one or more resources for a specific application and the scheduling of tasks on the appropriate resources. Replica Catalogue supports the management of domain storage resources to maximize data access performance with respect to response time, reliability, and cost. Consistency Management maintains domain consistency without deteriorating performance. The consistency within a domain is necessary whilst global reliability and incompleteness of state is tolerated in practice. Policy-based Grid management is deployed in this layer to take care of the management issues evolved in domain level and to keep communication with the policy components in Policy-based Grid Management Layer. Notice that active networking support is newly introduced in this layer. Multiple Executable Environments (EE) for different purposes, such as high-performance or XML parsing, are provided for dynamic router/gateway configuration, or new services installation/updating. Active network technology makes the Grid system environment programmable and more flexible, or so called active.

2.3 Grid Management Layer The Grid Management Layer maintains the management of whole Grid system in multiple domain environments. Its

functionalities can be classified by FCAPS, but paying more attention to resources management, especially transparent massive storage access. Resource broker is a very important toolkit that can serve as the intermediary of two domains. The storage management is to ensure the development of a uniform interface to different systems so as to provide interchange of data and meta-data between sites, and to develop appropriate resource allocation and information publishing functions to support the Grid. There may be other kinds of resource management, but all of them are based on policies. Policy is a kind of rule in the form of if then . A straightforward way for Grid administrator to give Grid management command or guide is to produce high-level rules such as if then . Then policy decision needs to be made upon the given policy, and the code for making policy decision can be dynamically downloaded via Policy code provider, which magnificently enlarges the openness of new Grid services. Policy code provider registers the requirement of codes for policy decision, resources monitoring or policy enforcement, looks up the location of required code, and uses active network technology or mobile agent to deploy the code for new components such as policy decision or enforcement. By using rule-based policies to give overall Grid management command or strategy, a unique but ubiquitous method of managing Grid environment can be guaranteed. Further description of this Policy-based Grid management middleware is given in next Section.

2.4 Grid Application Layer The top layer of this Grid architecture comprises the user applications that operate within a specific area such as weather forecast, biology, etc and Application Specific Tools that makes the development of these applications more easily.

3. POLICY-BASED GRID MANAGEMENT MIDDLEWARE This middleware sits on the top of Grid Supporting Environment and serves as the first access point for Grid administrator, or software on its behalf, to configure and manage intra-domain and inter-domain Grid resources. It is the core of Grid management. In order to deploy Policy-based management technology in Grid architecture, a standardization process should be followed to ensure the interoperability between equipments from different vendors and, furthermore, PBM systems themselves from different developers. Both the Internet Engineering Task Force (IETF) [11] and the Distributed Management Task Force (DMTF) [12] are currently working for the definition of standards for Policy Based Management. The work done by IETF is more related to the network management and the IETF policy architecture has covered almost all the components required by a policy-based management system, therefore, the IETF policy architecture gains more popularity and is adopted in this Grid architecture. The architecture of active Grid management

middleware and its components are shown in Figure 2, which details the skeleton of policy architecture proposed by IETF. Other Management Station

Policy Tools

Policy Receiving Module Policy Editor GUI

Policy Repository JDBC

Credential Check

Policy Parser

PDP Manager

PDP (VPN)

Resource Monitoring

SOAP

active packets

Sub-policies Generator

PEP Manager COPS

PDP

Codebase

Active Packets Generator

Active Network Execution Environment

PEP

Element Wrappers Typical Grid Resources

Computational Resources

Storage Resources

WINMAN Network Elements

Scientific Instruments

Figure 2. Policy-based Grid Management Middleware Architecture

3.1 Policy Tools Policy Tools provide the mechanism to receive policies from other management stations. With this tool the administrator can also define new policies for the system, edit existing ones, or simply view the policies that exist in the policy repository. The input of policies may be done in a high level language or in a visualisation way, which offers abstractions to the administrator. But the specification of policies is in XML (eXtensible Markup Language). In this case, the tool also performs a translation of these high level policies to a set of policy representation that can be interpreted by PDP. The extension of policy core information model (PCIM) [13] defined by the IETF, in the form of XML schema, is used to express the syntax of policy. Policy Tools mainly include Policy Receiving Module and Policy Editor GUI. Policy Receiving Module is implemented as a static agent for receiving XML-based policies given by upper management station. There are two ways to get policy. One is to receive from the upper level or other domain by using Policy Receiving Module, whilst another means is to be inputted directly by network administrator with the assistance of Policy Editor GUI. Policy Editor GUI provides a user-friendly way for administrator to input some simple information such as massive storage host names, select the QoS parameter required by user such as gold or sliver or bronze, etc., then it can generate XMLbased policy automatically and store it into the Policy Repository. Mobile agent is used for XML-based policy transportation due to its autonomous mobility [14].

3.2 Policy Repository The policy repository is used for the storage of policies, after they have been defined and validated by the policy management tool. The general framework of IETF does not require a specific implementation for the policy repository, or the repository access protocol. In this paper, relational database management system (RDBMS) is used for policy database, which is connected to Policy Tools and Policy Decision Point (PDP) via JDBC (Java Database Connectivity).

3.3 Policy Decision Point (PDP) PDP is the component that retrieves policies from repository, parses them thus evaluates them and eventually sends the necessary commands to the policy target. Additionally, the PDP also checks if the resources needed for a specific policy are available in all the controlled devices. The main role of PDP manager is to co-ordinate the different PDPs to support integrated scenarios, and resolve possible conflict. PDP manager can also dynamically download PDP code according to the availability of the code and the decision of PDP. PDP manager serves as the coordinator of PDP, Policy Parser and Credential Check Module. It uses Policy Parser to read policy from policy DB and to parse policy with the help of XML parser, and then it calls Credential Check Module to check the validity of policy user. The existence of PDP manager makes the whole policy management middleware extensible to contain other future PDPs. The Credential Check module is in charge of checking the privileges for services granted to any actor. Each actor that asks for the use of Grid resources should also submit a credential. The Credential Check Component then takes this credential and looks in the meta-policy database for a meta-policy related with that credential to check if the intended management actions (policies) are available to the actor that presented the credential. Finally, if the credential is correct, i.e., the actor has the correspondent privileges, these policies are passed to PDP, e.g., VPN PDP. PDP Module together with Sub-policies Generator can translate higher-level policy into domain level policies, with the information from monitoring service. After receiving the policies in XML file, which also has passed the credential check, the PDP Module extracts from the XML file the domain level policies. Then, it needs to decide when this policy should be applied by looking at the conditions of the policy thus deciding whether it needs any information to make a decision. If so, it will ask Monitoring Service to register the condition to be monitored. Otherwise, it asks the resource Monitoring Service if there are enough resources to apply this policy. If the answer is positive, the policy will be passed to PEP Manager Module to be fulfilled. All the policies are based on fixed schema, so that they are understandable by different levels. The Resource Monitoring service module receives the registration of resource monitoring according to the requirement of policies and make sure that all the resources registered can be monitored. If the necessary metering code (daemon) is not currently instantiated, it will try to download it by making a query to the specific resource monitoring service and install it.

Monitoring Service component just enquiries the Resource Monitoring Daemon to get the necessary information.

Grid Network Administrator

Resource monitoring functionality also exists in PEP to monitor the enforcement result of the policy.

Based on the parameters given by PEP Manager, Active Packet Generator can automatically encapsulate the code for policy enforcement into ABLE-formatted packets with the help of active network middleware.

3.4 Policy Enforcement Point (PEP) The policy target is the managed device, where the policy is finally enforced. There is a need of a transport protocol for communication between PDP and PEP, so that the consumer can send policy rules or configuration information to the target, or read configuration and state information from the device. There is no specific requirement of protocol for this operation. Apart from COPS protocol, which is defined by the IETF Resource Allocation Protocol workgroup, active network technology is mainly used for policy enforcement in this paper. In order for policy enforcing codes to communicate with different controlled elements, such as massive storage, computing resources or scientific instruments, the corresponding element wrapper needs to be provided. The design and implementation of this policy-based Grid management middleware is an extension of the PBM architecture developed in the context of EC IST Project WINMAN [15], whose controlled elements is shown in Figure 2. WINMAN is a European research and development project aiming to offer an integrated network management solution for the provisioning and maintenance of IP over WDM end-to-end transport services.

4. ACTIVE NETWORK MIDDLEWARE IN GRID MANAGEMENT ARCHITECTURE After introducing active network technology into Grid management, a new active Grid management architecture, as shown in Figure 3, provides mechanisms automatically adapting Grid network elements to different Grid applications and the management of the Grid system itself. In this paper, the method to add programmability to Grid management is to extend the widely used Grid supporting tool, Globus, in the means of middleware. Both policy-based Grid management middleware and active network middleware can be used by Grid supporting environment to facilitate the corresponding functionality so as to achieve better usage and management of different Grid resources such as massive storage resources, computing resources and special scientific instruments.

Policy-based Grid Management GUI/API XML: UCL Policy1

Active Network Middleware (ABLE)

According to the given policy, PEP Manager can select which kind of PEP enforcement protocols, such as COPS (Common Open Policy Service), SOAP (Simple Object Access Protocol), together with its parameters to be used to fulfil the policy. COPS and SOAP are two standard, well-implemented protocols for policy enforcement. In this paper, we evaluate the use of active network technology as another alternative for enforcing policy.

Grid Applications

XML: Storage Scheduler

MA XML Interpreter EE Policy-based Grid Management Middleware

Active Grid Mgnt. Env.

Grid Supporting Envirnment (Globus)

Storage Scientific Instruments Resources

Computional Resources

Figure 3. Overall Policy-based Active Grid Management Architecture Active node, the core of the active network, is based on the ABLE. ABLE [16] is an active network architecture that primarily addresses the network management challenges. Its main component is the active engine that is attached to any IP router or massive storage or computational resources to form an active node. Based on standards, ABLE can easily be deployed in Grid networks. That is, the mobile code is written in Java, and it is encapsulated together with data using the standard ANEP (Active Network Encapsulation Protocol) headers over UDP [17]. The codes configuring the routers to support QoS or codes scheduling computational resource are installed on these active nodes to control the packet forwarding or computing process accordingly. ABLE is extended in this paper to support mobile agent Execution Environment (EE) and XML interpreter/parser EE. Mobile agent EE is environment where mobile agent is executed. Mobile agents can be used for direct active node configuration such as triggering the monitoring mechanism to support policy decision. Policies are represented using XML due to XML’ s built-in syntax check and its portability across the heterogeneous platforms. A privileged EE, such as XML interpreter, manages and controls the active node and provides environment where network policies are executed. Policy-based Grid management middleware is part of the Active Grid Management Environment and is used to control and manage the Grid environment by defining new policies, e.g., to apply a new DiffServ shaper, or modifying existing policies, e.g., to add a new massive storage accessing role. Active packets carry the codes for these functionalities.

5. CASE STUDY: CONTROLLED AND SECURE MASSIVE STORAGE ACCESS Based on the policy-based active Grid management architecture given above, this section presents a case study to evaluate this architecture, i.e., controlled and secure massive storage accessing in the Grid environment. Secure and controlled massive storage is also a challenging research field in Grid computing. This section provides, as a case study, a solution to this by introducing both IP VPN (Virtual

Private Networks) and Storage Scheduler, as shown in Figure 4. IP VPN can secure the communication between massive storage and Grid application residing in different domains whereas storage scheduler considers the access control of massive storage. Administrator

XML

SNMP

Domain PBGM +AN EE +Globus SNMP

Domain B

IP VPN Cisco

Massive Storage

8. REFERENCES

XML

Policy Station

Domain A

7. ACKNOWLEDGEMENTS This paper describes part of the work undertaken in the context of the EU IST project WINMAN. The IST programme is partially funded by the Commission of the European Union.

Code DB

Domain PBGM +AN EE +Globus

further performance testing of the whole system needs to be done, which also requires a reasonable Grid application to be implemented using this system.

Cisco active packets

Grid App. GA

Figure 4. Case Study: Massive Storage Access Control After receiving the requirement from Grid application, which may be in the form of Grid service specification or agreement, Grid administrator used policy-based Active Grid Management Station to manage the underlying active Grid environment by giving policies, which might be automatically translated to from Grid service specification. These policies are further expressed in XML files and transported to domain Policy-based Grid Management (PBGM) station after digitally signed. Domain PBGM station, being so familiar with its own domain, makes decision based on the received policy. In Domain A, the decision may be to open a port number so as to receive the coming packets and enable the reconfiguration of massive storage access control by Grid application GA. Whilst in Domain B, the PDP module performs the following steps: downloads the code for VPN configuration and storage scheduler (PEP codes) if they are not currently available on Grid application GA; GA encapsulates the code and data and sends them out in the form of ABLE active packets that can configure the routers (to set up IP VPN) and massive storage (to support controlled access) in AN EE so as to achieve secure and controlled massive storage accessing.

6. CONCLUSIONS AND FUTURE WORK As shown in the above case study, after administrator inputted the requirement in response to Grid application demand, the whole procedure processed automatically. Administrator doesn’ t need to care about the information specific to the domain. The whole system scales to the changing of the application requirement automatically and flexibly thanks to the inherent programmability of active network and its intelligence empowered by policies. All these functionalities are implemented as Grid middleware that sit on the well-known Grid supporting environment, Globus. The design and implementation of policybased management middleware is based on the PBM architecture developed in EC IST Project WINMAN. The integration of policy-based management with active network technology shows an improvement in automation, manageability and programmability for the Grid computing environment. But

[1] Allan R.J. “Survey of Computational Grid, Meta-computing and Network Information Tools”. On web site: http://www.dl.ac.uk/TCSC/Subjects/Parallel_Algorithms/ste er_survey/ [2] Global Grid Forum Web Page: http://www.gridforum.org/ [3] Foster I. and Kesselman C. “Globus: A Toolkit-Based Grid Architecture”. Foster, I. and Kesselman, C. (eds.), The Grid: Blueprint for a New Computing Infrastructure. Morgan Kaufmann, 1999. pages 259-278. [4] EU DataGrid Project web page: http://www.eu-datagrid.org [5] Frey J., Tannenbaum T., Foster I., Livny M., and Tuecke S. "Condor-G: A Computation Management Agent for MultiInstitutional Grids", Proceedings of the Tenth IEEE Symposium on High Performance Distributed Computing (HPDC10), San Francisco, USA, August 2001. [6] Buyya R. “Nimrod/G: An Architecture for a Resource Management and Scheduling System in a Global Computational Grid”. Proc. 4th Int’l Conf. on High Performance Computing in Asia-Pacific Region (HPC Asia 2000), IEEE CS Press, Los Alamitos, USA, 2000. [7] Hall M., Nilson G. and Prozeller P. Management Architecture Specification. TINA-C (www.tinac.com), December, 1993. [8] Galis A., Tan A., Serrat J., Nikolakis Y. et al. “ Policybased Network Management for Active Networks” . Proceedings of IEEE ICT 2001, Bucharest, Romania,2001. [9] Galis A., Plattner, B., Smith, J.M., Denazis S., Moeller E., Guo, H., Klein C., Serrat J., Laarhuis J., Karetsos, G.T., Todd, C. "A Flexible IP Active Networks Architecture". Proceedings of International Workshop on Active Networks, Tokyo, October 2000. [10] Foster, et al., "The Anatomy of the Grid: Enabling Scalable Virtual Organizations". Intl. J. Supercomputer Applications, 15(3), Sage Publications, USA, 2001. [11] IETF Policy workgroup web page: http://www.ietf.org/html.charters/policy-charter.html [12] Distributed Management Task Force (DMTF) web page: www.dmtf.org [13] IETF PCIM draft on web: http://www.ietf.org/internetdrafts/draft-ietf-policy-pcim-ext-08.txt, 2002 [14] Kozt D., and Gray R.S. “ Mobile Agents and the Future of the Internet” . ACM Operating Systems Review, 33 (3): 7-13, ACM Press, New York, 1999. [15] WINMAN web site: http://www.winman.org [16] Kornblum J., Raz D., and Shavitt Y. “ The active process interaction with its environment” . Proceedings of IWAN 2000, October 2000. [17] ANEP IETF RFC on web: http:// www.cis.upenn.edu/~switchware/ANEP/docs/ANEP.txt