Policy-based Management for ALAN-Enabled Networks Ognjen Prnjat, Ioannis Liabotis, Temitope Olukemi, Lionel Sacks University College London, Dept. of Electronic and Electrical Eng., London WC1E 7JE, England email: {oprnjat | iliaboti | tolukemi | lsacks}@ee.ucl.ac.uk; Fax: +44 20 7388 9325 Mike Fisher, Paul McKee BTexact Technologies, Adastral Park, Ipswich IP5 3RE, UK email: {mike.fisher | paul.mckee }@bt.com Ken Carlberg, Gregorio Martinez University College London, Department of Computer Science, London WC1E 7JE, England email: {K.Carlberg | G.Martinez}@cs.ucl.ac.uk

Abstract This paper presents the architecture, the policy schema, and the policy specifications necessary to accomplish effective management of the Application Level Active Networking (ALAN) environment. Using ALAN, developers can engineer applications through the network by utilising platforms (active servers) on which 3rd party software (proxylets) can be dynamically loaded and run. Redirection of packets destined for active processing at the servers is performed by active routers. Management of such large, dynamic systems presents challenges to centralised approaches. Management based on policies locally interpreted in the context of local state is gaining acceptance as an alternative. The IST project ANDROID is using a flexible generic specification for policies, represented in XML, allowing a wide range of policies to be expressed and processed in a common framework. Policies given here focus on management of routers for VPN scenarios, resource and security management of active servers running the proxylets, and management of the information distribution mechanism. Preliminary results were demonstrated during the trial which included the scenario involving the inter-site connectivity and active server resource and security management.

1 INTRODUCTION Traditional centralised approaches to the management of networks and services are beginning to reach their limits as the complexity of the systems to be managed increases. Network equipment is becoming more heterogeneous and the range of capabilities that can be offered by network equipment is growing. At the same time, as users expect networks to provide the features they require on demand, configuration must be performed

much faster than before. All these considerations mean that an automated and distributed approach to network and service management is required, reflecting the distribution of the system elements being managed [1]. This is particularly relevant in active networking scenarios, in which the ability to load software dynamically onto network equipment (e.g. routers, application-layer proxies/servers) allows the behaviour of the network infrastructure to be customised for individual users and applications. In this context, the IST project ANDROID (Active Network DistRibuted Open Infrastructure Development) is focusing on the management of Application Level Active Networks (ALAN). The project has adopted the policy-based, event-driven management approach, and is striving to manage a wide range of functionality needed to provide the ALAN infrastructure. The current ANDROID scenario involves the inter-site connectivity accomplished through the interaction of the Reflector proxylets running on the ALAN active servers. The scenarios under development involve the dynamic set-up of the VPN through policy control of the active routers. Moreover, the policy control is exercised at the active server platforms, where both the security aspects of the active server platform and the proxylet resource allocation and consumption are managed. Finally, the management infrastructure - the management information distribution service (for policy and event distribution) - is also managed through policies. The general approach to the policy definitions was to consider the possible events that can occur in the ANDROID scenario(s), and then to identify the actions to be taken as a response to these events, and consequently the management policies that need to be in place. Finally, the specific example policies in XML are defined.

In section 2 we introduce the basic ALAN and ANDROID principles. In section 3 we give a brief overview of the ANDROID management architecture. Section 4 gives the details of the XML policy and event schema. In sections 6, 5 and 7 we present the policies which are used to manage various aspects of the network. Section 8 describes the recent ANDROID trial, and section 9 concludes the paper.

Proxylet thread resource consumption is left to be managed by application providers or the users and is out of scope. Restricting management system capability from the thread to proxylet level is done since in the business environment in question proxylets are considered as self-contained, user-specified services.

2 ALAN AND ANDROID BACKGROUND

The ANDROID management system is a fully distributed, policy based and event driven management system. Events are unidirectional messages used to communicate changes of state within the system. Policies specify actions that should be applied when particular events occur. The management policies and events are communicated between the components through the management information distribution (MID) system (described in more detail in Section 5) which is itself policy-controlled. The management infrastructure on the active servers includes the resource and security management components, which are policy-controlled and which to large extent use the local information. The active routers are also policy-controlled and provide the basis for the dynamic set-up and tear-down of the IP Virtual Private Network (VPN). The existing ANDROID active networking scenario involves the example end-user service – multicast conferencing. The pseudo-manager can dynamically admit new users through collaboration with Reflector proxylets. The basic aspects of security and resource allocation and consumption on the active server platform are policy-managed. The envisaged future scenario is entirely policy-controlled and involves the example multicast conferencing application within a managed VPN. The scenario involves the policy-based VPN Manager which establishes or tears down VPNs based on the XML events generated by the Reflector proxylet. The security and resource management on the active servers will be fully policy based, and event-triggered. The management information distribution system is to be used for communicating events and policies through the ANDROID system, and will also be policy-controlled.

Application level active network (ALAN) [2] provides an environment in which developers can engineer applications through the network by utilising platforms on which 3rd party software can be dynamically loaded and run [3]. The ALAN system consists of client and server applications that are located in the existing Internet. These communicate through Dynamic Proxy Servers (DPS) that are located in strategic points between them. DPS provides an Execution Environment for Proxylets – EEP. Proxylets are downloaded to the DPS and executed on behalf of the users. Those applications provide functionalities that enhance the level of service or introduce new services to the final user. End-to-end active services are provided by one or more DPS’s executing one or more proxylets. Messaging is done in XML [4][5] and is carried over HTTP [6]. These concepts are being refined in the IST project ANDROID, which focuses on the development of a scalable, lightweight management infrastructure for the ALAN-based active networks. ANDROID system is an event driven, policy enabled [7] management system [8]. The focus of ANDROID is on developing the management for primary issues of starting and maintaining the services and on resource and security management. In the ANDROID scenario active nodes are split in two categories: active routers and active servers. The active router provides an execution environment that runs dynamically loaded routing software components. Those components offer to users the customised routing tables according to user defined policies. Flexibility is restricted by allowing users to provide only configuration policies for components that are selected by the router operators. The active server, the equivalent of the ALAN DPS, is the second type of active node that offers more flexibility to users. It can be considered as an end system with a full protocol stack. It also provides an execution environment capable of running user provided processes that are unrestricted above the transport layer [3]. Multiple Execution Environment for Proxylets (EEPs) are allowed to run on each active server. Each EEP is allowed to run one or more proxylets. The EEP is a Java Virtual Machine (JVM) – FunnelWeb [9]. Each proxylet runs on its own JVM. Active server security and resources (consumed by the proxylets) need to be managed locally.

3 ANDROID MANAGEMENT ARCHITECTURE

4 POLICY SCHEMA Management in a distributed system on the scale of the Internet must address support for multiple domains, making independent decisions and using a wide range of technologies. Centralised control will not be possible and the response of the system will be the result of a collection of autonomous actions. There is however the need to exchange management information, for monitoring and control, between interacting systems. In order to achieve this we require common information

models or at least common information syntax. It is not reasonable to expect that a single policy language will be universally accepted so instead we focus on an approach which is intended to facilitate exchange of management information between different systems. This is achieved by identifying a restricted set of common information, much of which is optional, and allowing flexible extensions to accommodate a wide range of specific applications. The schema described here are used within ANDROID to provide a unified management framework.

4.1 Policies and events In an automated, distributed approach to management, decision making must be made based on locally available information and according to a set of rules. These rules, which govern choices in the behaviour of the system, are termed policies [10]. Policies allow the users of a system to specify the behaviour they want it to exhibit. Policies allow selections to be made from a range of options provided by the designer of the policy-controlled component. These selections can be specified in terms of a set of conditions with associated actions. When a policy is triggered, conditions involving locally available information can be evaluated and the appropriate actions initiated. This allows flexibility to be built into a system by supporting a range of different behaviours rather than hard-coding a particular behaviour – essentially fixing the policy at design-time rather than run-time. Policies provide a mechanism to control system components. Autonomous decision making also requires state information to be shared with other components so that a picture of the local conditions can be built up. An event-based mechanism is appropriate in a loosely-coupled decentralised system. A distributed approach based on policies and events allows considerable flexibility in management [11]. Management system components can be organised in a hierarchy, each with a set of policies controlling its decision making. Management issues can be resolved at as low a level as possible, only referring to a higher level when necessary. Thus, problems of heterogeneity and scale can be handled by a “divide-and-conquer” approach, and speed of response can be achieved by resolving problems locally.

4.2 Management information Support for heterogeneous systems makes it essential that events (monitoring information) and policies (control information) are represented in a platform neutral way. XML has recently emerged as a widely accepted way of representing and exchanging structured information. Its principal technical strengths are that it has a text-based representation which imposes few restrictions on network technology or protocols and that (through the use of XML

schema) it has a sufficiently strict syntax to permit automated validation and processing of information in an unambiguous way. It allows users to define representations specific to their own applications with a well defined syntax. Translation between different XML representations is also straightforward using XSLT [12] reducing the requirement for strong standardisation. XML does not, of course, ensure a common understanding of the meaning of the information represented. The use of XML as an intermediate representation still allows policies to be developed using any existing approach. Distributed systems based on technologies such as CORBA, EJB or COM can use mechanisms and protocols optimised for these environments. A well-defined mapping of management information to an XML-based representation can assist considerably in interworking between systems. XML allows the definition of new markup tags and constraints on the relationships between them through the use of templates. Originally, the only mechanism for this was the use of Document Type Definitions (DTDs). More recently, XML Schema [4][5] has been introduced, which allow more control over the way XML documents are specified. Datatypes are supported (all values are strings in DTDs) and there is the ability to specify relationships and constraints between different elements of a document. In addition, and of particular importance here, there is the option of allowing an open content model to be used where required. In a DTD there are limited options for departing from a strict document structure. None of these approaches naturally offers the flexibility to introduce arbitrary user-defined tags in a conformant XML instance document. XML Schema allow this flexibility to be offered in a controlled way. We take advantage of this and propose a syntax for events and policies which specifies features common to all policies or events in a standard way and also allows maximum flexibility in the definition of specific information sets for managing particular components of a system.

4.3 Policy There are several existing approaches to policy definition which generally make a number of technologyspecific assumptions about the systems to be controlled. An example is the Policy Core Information Model from IETF [13]. The approach taken here is not a replacement for existing policy-based management systems but aims to support interworking between different policy systems by defining as mandatory only those features we believe to be essential to all policies in an open distributed system and which allow some aspects of policy handling (dissemination and storage, for example) to be handled by generic software. Specific features required in particular frameworks can also be accommodated.

The overall structure of a policy is shown in Figure 1. The general approach is consistent with [10]. A policy is written to be interpreted by a subject which is then expected to perform specified actions on targets, possibly dependent on some conditions.

Figure 1. Policy structure

The top level policy specification consists of six elements. The creator element allows the origin of a policy to be established. This policy specification is intended to be applicable in an environment where there are multiple points of control. Components should be able to accept control from users with different privileges. The administrator of a router, for example, will have ultimate control of its configuration, including the permitted extent of control by other users. End users may be allowed to control the way the router behaves for their own traffic. This is currently missing from the IETF specification [13] – the most significant point of difference between their approach and ours. The info element contains most of the information about the policy which is not directly related to the policy rules. It includes a globally unique identifier for the policy and an indication of the modality of the policy (positive authorisation – what the subject may do, negative authorisation – what it may not do, obligation – what it must do, or refrain – what it should not do). The intention is that the modality should not be mixed within a single policy. The general policy handling components of the management system, which have no detailed knowledge of the specific rules contained in the policy, may then take advantage of this classification. It may also contain a textual description of the policy. The creation time, start time and expiry time of the policy can also be specified. Finally, a list of policies replaced by the current policy may be specified. Policies are considered to be immutable so different versions are not possible. The sender element is an optional list identifying the forwarding path the policy has taken. This information could be used as a check that the policy has followed an expected route, or to establish that the policy has already been received by other parts of the system. This element may be modified between creation and receipt of the policy and would thus not be subject to digital signing. The subject element identifies those entities in the

system which are expected to respond to a policy. Identification of these entities is done by role. This is important so that a policy can refer to entities which are not present or not known at the time of creation. A role refers to a named group of entities. A specific entity can be assigned to one or more roles statically (when the software is written) or by policy. There is no central registry of roles since it is only important that the creator and subjects of a policy share knowledge of the correspondence between role and entities. The optional trigger element relates an event (via its unique event type identifier) to the policies that are supposed to handle it. When an event is detected, relevant policies must be activated. It is assumed that a policy is triggered by a single event. Correlation of events (aggregation, sequences, threshold rates etc.) is assumed to result in the generation of a single event which then triggers an appropriate policy. A system which provides this functionality is described in [14]. If a trigger element is not present, the policy is assumed to be activated as soon as received. This approach can be used in systems which are not based on events. Triggerless policies can be used, for example, to effect immediate configuration changes which control subsequent behaviour. Deactivation of a policy is assumed to be explicit and effected by another policy. Every policy includes one or more actions elements. These specify the behaviour that should result from the triggering of the policy. Each actions element contains an optional condition expression and a set of strings specifying actions to be taken on particular target components. These can use the open content features of XML schema to allow tags appropriate to any particular system to be included in a policy instance. All that is required is for the creator of the policy and the system on which the action is to be taken to agree on the syntax and semantics of the action. When a policy is triggered, each of the actions elements is processed in turn (order is not assumed to be significant). This involves evaluating the condition expression (if present) and then initiating the appropriate set of actions. This allows the aggregation of a number of condition-action blocks in a single policy with a shared trigger and a single creator.

4.4 Event The structure of an event is shown in Figure 2. Its purpose is to provide sufficient information to allow generic components to be used in the distribution of events to all interested entities but also to allow any additional information to be included to support specific circumstances. An event following the syntax specified here may be generated either directly or by an XML-aware component (such as ANDROID security and

resource managers) or by a special monitoring component which obtains information using some other mechanism.

Figure 2. Event structure

The top level event specification consists of seven elements. Each event type has a unique event-id, a globally unique string which is used to trigger appropriate policies. All instances of the same type of event share the same event-id. The time element identifies when the specific event occurred while the optional timetolive element specifies for how long the event is relevant. Use of this information can allow certain events to be discarded if not handled in time, limiting unnecessary management traffic. The source element identifies where the event originated. The sequence element is an integer which is incremented with each event produced from a particular source. This can support partial ordering of events which may be useful, for example, in correlation of events from a single source. The optional information element is a text string intended to be read by people rather than processed automatically. The data element has an open content model and allows any well-formed XML to be included. This is where any specific information about the event can be included, using whatever structure is most appropriate. As with policy actions, it is only necessary that the event producer and the interested recipients share knowledge of contents of this element.

5 MID POLICIES The management information distribution (MID) system is an important element of the management system. It consists of a set of store and forward messaging systems that support flexible delivery of management information (events and policies) expressed in XML, according to the schema described in section 4. Each site runs at least one MID server. Processes needing to send an event or policy use the local MID server as an entry point to the system. At present, Java remote method invocation (RMI) is used for this interface. Internal to the MID system, XML documents are wrapped in another XML document called a notification. This is responsible for controlling the transport of events and policies through the MID system.

Each MID server has a set of policies which determine how it handles XML documents it receives. Basic event distribution behaviour is determined by a policy for each event type. This effectively links each event type (given by the content of the event-id element) to a destination. The destination can indicate a number of communication endpoints to which the event should be forwarded. Each endpoint may refer either to a process outside the MID system or to another MID server instance. A communication endpoint specifies the protocol to be used and the appropriate protocol-specific address. In the current implementation there is support for use of sockets, Java RMI and Simple Object Access Protocol (SOAP) [15]. The policies defining the behaviour of the MID can in principle be set by the event source, interested recipients and third parties. This approach gives a very flexible basic messaging system. Additional functionality can be introduced via the use of event filters as described in [14]. These are dynamically loaded software components which allow customised transformation of management information including aggregation, correlation and thresholding.

6 VPN MANAGEMENT POLICIES This section describes the management of a dynamic VPN service. Management is defined through various scenarios (use-cases) that relate to the establishment or tear-down of a VPN, or parts thereof. The VPN Manager centralises the access control, and can be used as a final arbiter of which endpoints or sites are allowed to join or leave a VPN. A user or an active service sends events to the VPN Manager to join/create or leave a VPN. Policies are then used to control the initial establishment of the VPN. From the perspective of the VPN manager, access policies dictate which nodes would be able to join the VPN. In the future, site policies will also be defined for those nodes initiating the request to join VPN and these will dictate the form of their participation: as purely a receiver (uni-directional mode), or as a potential participant (bi-directional mode). Another extension to this model is the ability to query the parameters associated with an existing VPN. Thus, the use-cases include joining/creating a VPN, leaving a VPN, and querying a VPN. The VPN Manager sends back an event to the user or the active service to notify if the requested operation was accepted or not. The VPN Manager also sends the events to the routers to configure the VPN. The management policies are defined on the basis of the types of events that occur in each use-case. Only the details of the policies concerning the VPN join/create use-case are described in detail in the following. Figure 3 presents the XML Join-KeepAlive-VPN event. It can be noticed that the structure and contents of the message are generic in form and do not have any

strong dependencies based on the type of VPN manager that is used. The TAG entity (a reflector) identifies the type of node that is requesting a VPN to be established. The VPN itself uses a soft state design and requires periodic keep-alive messages to be sent – in this case, every 120 seconds.

identification number, the time for a new keep-alive message to be sent, and the VPN total duration. aDnVpnCr: involves sending a event back to the user (or active service) notifying that the request can not be fulfilled by the Active Router or that it is not acceptable according to the polices existing in the VPN Manager.

ca337bc0-da78-11d5-923b-00010347ec1b 33.08.10.16.11.2001 http://www.example.com TAG 123 Join-KeepAlive-VPN site1 dummy1234 VPN_VISIO 120

Several sub-scenarios where this event is involved are presented below. No pre-existing VPN and no other requests to join the VPN: in this case, the VPN Manager receives a request event, but takes no further action because there are no other participant(s). No pre-existing VPN and one pre-existing request to join the VPN: this case represents a second participant of the VPN, and now the VPN Manager can establish a VPN between the appropriate routers. Existing VPN: the VPN Manager adds a new participant in the VPN. This requires updates to all the existing routers participating in the VPN. In each of the above scenarios, a confirmation message is sent back so that a level of assurance exists that the message has been received and acted upon by the VPN Manager. Subsequent Join/Create messages by the participants act as a means of refreshing the soft state associated with a VPN participant.

Figure 3. Join-KeepAlive-VPN event

Events: Create/join VPN event (eJnKplvVpn): users (or active services) send this Join-KeepAlive-VPN XML-based message to create a new, or join an existing, VPN. This message provides all the information needed to describe the specific VPN that the user or active service wants to create (or join). Combinations of this event and related conditions and actions, define the full set of policies in the scenario of creation of a VPN (Table 1). Conditions: pVPNDscr: this condition type provides all the information needed to describe the specific VPN that an user or an active service wants to create (or join or keep-alive, if it is already created). This information can be a pre-registered VPN identification number or a description of the type of information/traffic to be carried out through this VPN (e.g. a video conference in one specific multicast group and/or port number). pAUTHInfo: this condition type describes the authentication information needed to validate an user or active service requesting to create, join or keep-alive a VPN. This information can be expressed in terms of attribute certificates, X.509 certificates or login/password. Actions: aCrVpn: this action involves the generation of an event sent to an active router (or a set of active routers) indicating that the VPN Manager allows the creation of a new VPN with some specific parameters, such as the source and destination points, the VPN mode, and the cipher, integrity and compression algorithms. aAcVpnCr: this action involves sending an event back to the user (or active service) notifying that the request can be fulfilled by the Active Router. This event will indicate some VPN specific parameters, such as the VPN

Table 1. VPN policies (VPN creation scenario)

Event eJnKplvVpn

Condition pVPNDscr pAUTHInfo

Action aCrVpn aAcVpnCr aDnVpnCr

The example on Figure 4 demonstrates an event-condition-action combination that may appear during the VPN join/creation scenario. This Active Router Operator-specified policy allows creating new VPNs for videoconferences between the Android Partners. When these policy conditions are verified, two events are sent. The first one is sent to an Active Router (or a set of Active Routers) indicating the creation of a new VPN with some specific characteristics. The second one is sent to the Active Service, indicating that its request has been fulfilled and providing the information needed for the keep-alive message to be sent, and regarding the total VPN duration. Policy-ID (Policy 1) Event (Join-KeepAlive VPN), Event Originator (Active Service) Condition (If “Traffic to be carried out through this VPN” is related with a “videoconference” and “Role of the petitioners” is “Android Partners”) Policy Originator (AR Operator)

Action 1 (Send Create VPN event “aCrVpn” to the Active Router) Action 2 (Send Accept VPN Creation event “aAcVpnCr” to the Active Service) AR AR Operator AROperator1 [email protected] Policy1 Obligation VPN Manager eJnKplvVpn Kind-Of-Traffic Equals Video-Conference Petitionar-Role Equals Android-Partners Active Router aCrVpn Active Service aAcVpnCr

Figure 4. Example VPN policy (creation scenario)

Following is summary of events for other use-cases. Leave VPN event (eLvVPN): for this event, the VPN Manager removes a router from the VPN, and updates all the other routers with this updated information. If there is just another router in the VPN, the VPN Manager destroys the VPN. Query VPN event (eQrVPN): this is considered an optional event that produces additional information for a VPN participant. For example, participants may require knowing the identities of other participants in the VPN in case they may have access policy restrictions. Finally, it is important to point out that there are two types of policies that can be applied to the dynamic management of a VPN. The first approach, presented here, is centralised at the VPN Manager. Policies based on access control can be used by the VPN Manager to reflect a final point of authority about who is allowed to

join the VPN. Other centralised policies may exist reflecting the form of security used to validate credentials for those requesting to join or leave a VPN. Policies for VPN management may also be in the form of a decentralised system, reflecting the management decisions of individual users participating in a VPN. In this case, there may exist access control policies determining whether a given end-point is allowed to join a specific VPN, or if certain types of traffic may enter or exit the local endpoint of a VPN.

7 RESOURCE AND SECURITY MANAGEMENT 7.1 Architecture Here we present the resource and security management functionality needed for policy enforcement on the active servers (ASs). We first capture the required functionality in terms of use-cases, and then elaborate on the resource and security infrastructure on the ASs. The use-cases focus on the resource and security management aspects of the ASs, and include the service set-up and in-service use-cases, initiated by the user or the AS operator. Service negotiation and set-up use-case involves the interactions between the user, the service provider and the active router/server operators which involve the negotiation of the resource usage, SLA definition, and set-up of the necessary policies. Service initialisation use-case involves the user requesting the start of the service by sending the relevant events to the operators. After performing the resource and security management checks based on policies, the operators load the requested proxylets. Runtime service management use-case involves the operators monitoring the behaviour of the proxylets, and, in case of unexpected behaviour, applying the relevant policies so as to preserve the resource integrity and security of the platforms they operate. Service modification use-case involves the modification of the service parameters, either by the user or the operator. Specific sub-cases are: the reallocation of the proxylet making up a service to another processing platform, operated by the same or different operator; requesting the increase or decrease of the resources dedicated to the proxylet. Service termination use-case involves stopping the service by the operator or the user. The AS hosts one or more EEPs which run one or more proxylets. On each AS, there is a policy infrastructure, providing for policy authentication, generic policy handling, policy storing, while in the future policy conflict resolution will be also considered. The AS also supports the event/notification handling functionality (MID - described in section 5). Finally, the specific management functionality is located on the AS: security and resource managers. These two basic management components are also XML-enabled: they can receive

events/policies, interpret them, and apply management actions on targets. The components on the AS also need to be capable of generating appropriate XML events - this is performed by the event generator. EEP controller is another management component which ultimately enforces the management actions, such as loading and running proxylets, on the EEP. These are defined by both the resource and security managers, and are communicated as XML events to the EEP controller. Proxylets and EEPs running on an AS consume the resources provided by the OS. Resource management is important from both the operator perspective, where the AS operator dictates resource consumption of user processes; and service-user perspective, where proxylets themselves are allowed to adapt resource usage levels dynamically. Three main categories of the local resources to be managed on the AS are CPU, storage and network [16]. Within these main categories, further subdivisions exist: e.g. within CPU time there are Kernel-mode and User-mode categories, and within memory there are physical and virtual sub-categories. Resources consumed by the EEPs and the proxylets are managed by the local management system. Resource management involves the tasks of resource monitoring - observing the consumption of resources by processes; and resource allocation and reallocation: effectively closing the local control loop e.g. (re)scheduling a process. User demand for specific resources on ASs is liable to change unpredictably with time. Static resource allocation cannot provide QoS to users amidst spiky resource utilisation patterns: hence a dynamic model for resource allocation / reallocation is also required [16]. The resource manager component uses the resource monitoring and estimation components. The management actions decided by the resource manager are either communicated in the form of events, created with the help of the event generator component, to the EEP controller, or are directly enforced on the resources via the resource allocation controller. The security manager performs the policy-controlled deployer and proxylet authentication, as well as the set-up of the java.policy file which restricts the proxylet access permissions to the resources [17]. The security and resource management policies are enforced sequentially, i.e. all the events are first processed by the security manger, which then forwards the requests for further processing to the resource manager, which, if the resource relevant conditions are met, ultimately enforces the management actions on the targets.

7.2 Policies 7.2.1

Resource management

Based on the use-cases explained above, we categorise the resource management policies into policies for service

initialisation, run-time management, service reallocation, resource increase/decrease, and service termination. The reason for using this categorisation is the types of events that occur in the use-cases. Some policies apply to more than one use-case. Based on the originator we also categorise policies into two main groups: policies originated by users and by AS operators. Main difference is the delivery and/or execution guaranties they offer. Users are able to define their own administrative policies in order to manage their own services. In case of conflicts with policies specified by the AS operators the user defined policies are not executed and a notification is sent back to the user. Since not all the policies can be described here, the Table 2 gives the events, policies and actions associated with the service initialisation use-case. Policies are identified by the conditions that the resource manager has to evaluate. Actions can be applied directly to targets or can be sent as events through the notification system to the appropriate management component. Combinations of events, conditions, and actions define the full set of policies (Table 2). Table 2. Resource policies (service initialisation)

Event eLdPrx

eRnPrx

Condition

pCPUthr pMEMthr pDISKthr pNETthr pPredMeta pTD

Action aLdPrx aAlRs aMRMP aDnLdPrx aFLd aNtfAR aRnPrx alRs aMRMP aDnRnPrx aFRn aNtfAR

Events: Load proxylet event (eLdPrx) is received by the security manager (and after processing forwarded to the resource manager), when a User or AS Operator wants to load a specified proxylet on the AS. Run proxylet event (eRnPrx) is received by the security manager (and after processing forwarded to the resource manager) when a User or AS Operator wants to run a specified proxylet that has already been loaded on the AS. Conditions: pCPUthr: this condition type describes a range of policies that are associated with CPU usage. The possible operands are measured values (in percentages) such as: total time, kernel time, user time. Operands can be also statistical information about the above measured values such as average, standard deviation, percentiles. pMEMthr, pDISKthr: these types of conditions have as

operands the amount (in absolute values or percentages) of free/used memory /disk space. pNETthr: operands of these types of conditions are: incoming/outgoing bytes per second and statistical information on those values, such as average, standard deviation and percentiles. The above are checked by the resource monitor. pPredMeta: condition involves the predicted future resource usage using information found in proxylet metadata and is checked by the resource estimator. Actions: aLdPrx: involves the generation of an event indicating that the resource manager allows loading the proxylet. aRnPrx: involves the generation of an event indicating that the resource manager allows running the proxylet. aAlRs: a direct method call to the resource allocation controller that will enforce hard resource allocation or change process priorities. aMRMP: is related to conflict resolution and will be used in the future to set valid policy in case of conflicting requirements. aDnLdPrx, aDnRnPrx: involve sending an event back to the user notifying that the request could not be fulfilled. aFLd, aFRn: forwarding actions are applied when the AS cannot load/run the requested proxylet. The original load/run event is forwarded to another AS for processing. aNtfAR: The AS notifies the active router (AR) that the request for service has been forwarded to another AS. AS AS Operator ASOperator1 [email protected] Policy1 obligation Resource-Manager eLdPrx Total-CPU-Usage LessThan 60% EEP-Controller aLdPrx

Figure 5. Example resource management policy

The example policy of Figure 5 demonstrates one event-condition-action combination that appears during

the Service Initialisation. This AS Operator specified policy allows loading of user requested proxylets if the Total CPU time load of the AS is less that 60%. Policy-ID (Policy 2) Event (Load Proxylet), Event Originator (User) Condition (If "Total CPU time load" less than 60%) Policy Originator (AS Operator) Action (Send Load proxylet event to EEP Controller) 7.2.2

Security management

Based on the use-cases we categorise the security policies in: policies for service initialisation, service reallocation and service termination; and policies for runtime management. This categorisation is based on the type of events that occur in use-cases and on the source of the events. Most of the policies in group one originate from users, while the group two policies are mainly established by the AS operator. Since not all the policies can be described here, the following shows the example security events, conditions and actions associated with the service initialisation use-case. Different combinations of these (Table 3) define the full set of policies. Table 3. Security policies (service initialisation)

Event eLdPrx

Condition

pAuthDeployer pAuthProxylet eRnPrx

Action aLocSPU aLdPrx aDnLdPrx aSecAl aRnPrx aDnRnPrx aSecAl

Events: Load proxylet event (eLdPrx): received by the security manager when a user or AS operator wants to load a specified proxylet on the AS. Run proxylet event (eRnPrx): received by the security manager when a user or AS operator wants to run a specified proxylet that has already been loaded to the AS. Conditions: pAuthDeployer: returns True if the deployer of the specified proxylet is authenticated, i.e., has provided some verified identification such a certificate and False otherwise. pAuthProxylet: returns True if the proxylet has been signed with a valid certificate and False otherwise. The proxylet is signed with the certificate of the proxylet creator. Actions: aLdPrx: involves the generation of an event indicating that the security manager allows loading the specified proxylet.

aRnPrx: involves the generation of an event indicating that the security manager allows running the specified proxylet. aLocSPU: invokes a direct method call on the security manager which creates/updates a local policy file with the relevant proxylet/user authorisation to the local AS resources. aSecAl: involves the generation of an event informing the AS operator that a security violation has occurred. An event is also generated and sent to other security managers within the AS operator's domain informing them of the violation so that they can take appropriate actions. aDnLdPrx, aDnRnPrx: involves sending an event back to the user notifying that the request could not be fulfilled by the AS. EE Admin /AS/ADMIN 127.0.0.1 270920011237 Obligation Security eLdPrx pAuthDeployer Equals True pAuthProxylet Equals True Resource-Manager aLdPrx Security Manager aLocSPU

Figure 6. Example security management policy

The example security policy shown in Figure 6 is triggered by an event requesting for a proxylet to be loaded. There are two conditions (pAuthDeployer and pAuthProxylet) that have to be satisfied before the actions aLdPrx and aLocSPU are invoked. Policy-ID (Policy 3) Event (Load proxylet), Event Originator (User)

Condition (If "Deployer authenticated" and "Proxylet authenticated") Policy Originator (AS Operator) Action 1 (Invoke Load_proxylet method on Resource manager) Action 2 (Update the java.policy file related to the proxylet)

8 ANDROID DEMONSTRATION Some of the policy-based components described here were demonstrated at the ANDROID project demo in Essen, Germany, July 2001. The ANDROID multi-site demo involved a multimedia conference (shared whiteboard, video) between a number of sites of the project partners (BT, MediaSec, NTUA, 6WIND, University College London). The sites joined the conference through the collaboration of the management system and the Reflector proxylets, running at the active servers located at each site. The resource monitoring software was running at two of the sites (UCL, MediaSec) - two distinct management domains. The objective of the inter-site demo was to show the actions of proxylets, events, and policies operating independently and transparently from normal applications - i.e., applications that have not been changed in order to accommodate new functionality. The three proxylets that were demonstrated were: Reflector, Transcoding Active Gateway (TAG), and the R-let. Reflector provides inter-site connectivity between local multicast capable networks across an unicast-only type of network (such as the Internet). It accomplishes this by joining designated groups and determining if the local network has a receiver and/or source for the group. If it does, then it registers itself with a pseudo-manager using the XML event messages. The pseudo-manager then informs the Reflector about the presence (and lack thereof) of other Reflectors located in other sites. When a Reflector receives a multicast packet from the local site, it encapsulates it as a unicast packet and sends it to the other Reflectors it has been informed about. Reflector operates on behalf of all the receivers and sources within a site – i.e., there is no one-to-one correlation between Reflector and host. In future demos, the pseudo-manager will be replaced with a VPN Manager, which in turn will establish or tear down VPNs (described in section 6) based on the events generated by the Reflector proxylet. TAG has a similar reflection capability as the Reflector proxylet. However, its reflection is based on a per-host basis in which a TAG-client is used by the end host, and a TAG-server (proxylet) is dynamically loaded onto an AS connected to the multicast capable network.

LEARnet

BT

UCL-CS UCL-EE

6-Bone

Internet

6Wind - AS + Reflector - AS + TAG - Host + NTE/VIC

NTUA

MediaSec Figure 7. Demonstration

The topology of the demo is shown in Figure 7: the presence of the active servers (ASs) and their hosting of the Reflector and TAG proxylets. At each site, additional hosts were used to run the Video Tool (VIC) and the Network Text Editor (NTE). The activation of these tools represented “triggers” that subsequently activated the TAG and Reflector proxylets. The resource measurement and security infrastructure exercised in the demo is shown on Figure 8. The resource monitoring GUI is used to launch the resource measurement proxylet (R-let) at the AS. AS is secured by the security manager, which performs proxylet deployer authentication on the basis of the authentication policy (as described in section 7.2.2). Monitoring of the AS resources, consumed by the proxylets used to facilitate Mbone tools like the Video Conference (VIC) tool, is done by the R-let. This is a trusted proxylet that uses MonitorAPI objects and method calls to measure the resources on the AS. MonitorAPI is a Java API that uses Java Native Interface (JNI) calls to the operating system and more specifically to libGTop [18], a library that fetches system-related information such as CPU load, memory usage, etc. A snapshot of the resource monitoring GUI is shown on Figure 9. On the left, the tree of the end-end active service is shown. On the first level, the list of the ASs is shown (in this case, the ASs running the Reflector proxylets –one at each site). For each AS, the total CPU, memory, disk, and network bandwidth are shown. Finally, for each EEP and proxylet running on an active server, CPU (user, kernel, and total time) and memory consumption are shown. Clicking on the

particular parameter measured per proxylet/EEP brings out a window which shows the parameter utilisation in real-time. On the right-hand side of the screen, the top window depicts the total CPU used by the reflector proxylet on the UCL AS. The initial peak in the CPU usage is due to the clients at different sites joining the shared whiteboard session. The utilisation is then constant for some time, until the second peak appears when the clients join the video sessions. The bottom right graph depicts the total network traffic going in the active server. Note that the two graphs are not aligned. The initial peak in the bottom graph is due to the clients joining video sessions. The step increase in traffic is due to the fact that the MediaSec site after some time started sending a watermarked stream to the other multimedia conference participants. This resource monitoring information relates to the AS on the UCL site. The future ANDROID demos will include the implementation of the full set of resource management policies and other resource management components (described in 7.2.1), that will allow the effective resource management based on the knowledge of the local state, which is captured by the resource monitoring infrastructure described in this section. R-let

Measurements GUI

RMI Status/Requests

XML Event Data Store Monitoring Station

Proxylet 1…N

FunnelWeb RMI Load

Security Manager

MonitorAPI

libresource (JNI) LibGTop

Policy Store OS

Active Server

Figure 8. Demo: resource/security management

Figure 9. Resource monitoring GUI - snapshot

The demonstration currently under preparation will build on the demo described in this section, and will

exercise the policy control over the whole spectrum of the ANDROID functionality, as described in this paper. The dynamic set-up and tear-down of the VPN will be policycontrolled (deploying policies described in section 6), and the security and resource aspects of the active servers will be controlled by policies described in section 7. The VPN management components and the security and resource management components will be fully integrated with the management information distribution system, which itself is policy controlled (as described in section 5).

9 CONCLUSION Conventional, centralised management designs do not scale well in the future highly distributed networking scenarios, where the need for delegation of management decisions to local system components which can make autonomous decisions is of paramount importance. The ANDROID project aims to develop a flexible, policy-based management system that enables control (by both users and infrastructure operators) of active nodes and services in the context of the Application Level Active Networking environment. Here we have presented the high-level ANDROID management architecture developed to accomplish these aims. We have introduced flexible policy and event schemas specified in XML, and elaborated on a range of policies required to manage: the active server resource and security aspects; dynamic VPN control; and the distribution of management information. Finally, we briefly described how some of the aspects of the described policy-based control were demonstrated in a real-life trial.

10 REFERENCES [1] Sloman M., “Policy Driven Management for Distributed Systems”, Journal of Network and Systems Management, 1994. [2] Fry M., Ghosh A., “Application Level Active Networking”, Computer Networks, 31 (7) (1999) pp. 655-667. [3] Marshall I. W., et. al., “Application-level Programmable Network Environment”, BT Technology Journal, Vol. 17, No. 2, April 1999. [4] W3C, “XML Schema Part 0: Primer – W3C Recommendation, 2 May 2001”, [www] http://www.w3.org/TR/xmlschema-0 [5] W3C, “XML Schema Part 2: Datatypes – W3C Recommendation, 2 May 2001”, [www] http://www.w3.org/TR/xmlschema-2 [6] Marshall I. W., Fry M., Velasco L., Ghosh A., “Active Information Networks and XML”, in “Active Networks” ed. S. Covaci, LNCS 1653 pp. 60-72, Springer-Verlag, 1999. [7] Sloman M., Lupu E., “Policy Specification for Programmable Networks”, Proceedings of the IWAN '99 Conference, Springer-Verlag, 1999.

[8] Marshall I. W., Hardwicke J., Gharib H., Fisher M., Mckee P., “Active Management of Multiservice Networks”, Proceedings of the Network Operations and Management Symposium (NOMS), 2000. [9] FunnelWeb, [www] http://dmir.socs.uts.edu.au/projects/alan/ [10] Damianou N., Dulay N., Lupu E., Sloman M., “Ponder: A Language for Specifying Security and Management Policies for Distributed Systems”, Imperial College Research Report DoC 2001, January 2000. [11] Marshall I. W., Gharib H., Hardwicke J., Roadknight C., “A Novel Architecture for Active Service Management”, IEEE/IFIP International Symposium on Integrated Network Management (IM’2001), Seattle, May 2001. [12] W3C, “XSL Transformations (XSLT) Version 1.0 – W3C Recommendation 16 November 1999”, [www] http://www.w3.org/TR/xslt [13] Moore, B., Ellesson, E., Strassner, J., Westerinen, A., “Policy Core Information Model – Version 1 Specification”, RFC 3060, February 2001. [14] Natarajan R., McKee P, Mathur A.P., “A XML Based Policy-Driven Information Service”, IEEE/IFIP International Symposium on Integrated Network Management (IM’2001), Seattle, May 2001. [15] W3C, “Simple Object Access Protocol (SOAP) version 1.1 – W3C Note 08 May 2000”, [www] http://www.w3.org/TR/SOAP/ [16] Liabotis I., Prnjat O., Sacks L., "Policy-Based Resource Management for Application Level Active Networks", Second IEEE Latin American Network Operations and Management Symposium LANOMS 2001; August 2001. [17] Prnjat O., Olukemi T., Liabotis I., Sacks L., "Integrity and Security of the Application Level Active Networks"; IFIP Workshop on IP and ATM Traffic Management WATM’2001 and EUNICE’2001; September 2001. [18] LibGTop Home Page, [www] http://www.home-oflinux.org/gnome/libgtop/about-libgtop.html