Phone: (0422) 2572177 ext. 4436. E-mail: ... Keywords: Active Networks, Policy Based Network Management, Service Level .
Policy Based Architecture for Active and Programmable Network Management S. Rajeev1, K.V. Sreenaath2, A.S.Bharathi Manivannan3 1 Department of Electronics & Communication Engineering 2 Associate Software Engineer, Computer Associates, Hyderabad, India 3 Software Engineer, Caritor, Chennai, India Phone: (0422) 2572177 ext. 4436 E-mail:
[email protected],
[email protected],
Abstract: Active Network is a network where the nodes are dubbed active that can look inside packets and run the executable code in those packets. Real Time implementation of Active Networks has several important criterions that should be met for successful implementation. The policy-based approach can be used to manage different aspects of a network that are commonly known as policy disciplines [1]. Some examples of policy disciplines are Service Level Agreement (SLA), Quality of Service (QoS), Security, and IP address allocation [2]. Policy-based networking configures and controls the various operational characteristics of a network as a whole, providing the network operator with a simplified, logically centralized, and automated control over the entire network. Policy Based Management of Active Networks satisfies all the major criterions for efficient real time implementation. Keywords: Active Networks, Policy Based Network Management, Service Level Agreement, Quality of Service, Modified Bloom Filter. 1. Introduction The concept of Active Network is to move from static routers to active nodes that can handle "smart packets" (also called capsules) that have their own executable code. Alternatively, the capsule may contain a pointer that references some code already located on the network. Network nodes may change their behavior based on the code or modify the capsule contents in order to affect network nodes down the line. A capsule may also define its own path through the network. Policies are rules that govern the overall functioning of the system. . Policy Based Network Management (PBNM) is an over-arching technology for an automated management of networks [12, 13]. Policies encode the high-level goals and requirements of management. Policy based management is being adopted widely for different domains like Service Level Agreement (SLA), Quality of Service (QoS) [3], Security and Virtual Private Networks (VPNs) [2]. Active and Programmable networks has fundamental management issues such as SLA, QoS, Security, Self Configuration management that are crucial for its successful implementation. Policy based management of active networks addresses all the major issues in real time implementation. In this paper we propose a policy based framework for active and programmable network tested using Network
Processors [11]. A Service Level Trading [4] (SLA) algorithm for SLA trading between passive and active routers is developed along with real time implementation of Modified Bloom Filters [5] for compatibility of active networks with existing routers. The paper is organized as follows. Implementation issues of active networks are given in section 2. Architectural framework for Policy Based Management of Active Networks is presented in section 3. The SLA Trading Algorithm is explained in section 4. Test Results and Observations are provided in section 5. Conclusions are drawn in section 6. 2. Implementation Issues of Active and Programmable Networks in Real Time Implementation of active networks in real time is a difficult task. There are many issues that need be addressed while implementing active networks in real time. Some of the key issues are • Self Organization of Active Networks Active or programmable networks are used to manage and control mobile ad hoc operation and other legacy networks. Hence they should be highly self-organized and dynamic in nature that can function without the intervention of a human administrator. To achieve these for real time implementation of active networks policy based approach should be adopted. • Tradeoff in amount of Code versus data Tradeoff between the length of the code and the length of data is another important aspect in the success of real time implementation of active networks. There must be an optimized level of code that should be injected along with data in programmable networks. Several bytes of code that functions on few bytes of data in a packet virtually becomes an inefficient one. Thus there should be a tradeoff between the length of the code and length of the data for effective functioning of active networks. The optimized length of code and data are necessary for providing good QoS that adapts to link quality which can be achieved by means of writing high end policies. • Compatibility of active networks with existing routers Much of the existing routers are passive in nature which are not adaptable to active networks. With the implementation of active code and active networks, compatibility of existing passive routers in such a network becomes an important criterion. This can be achieved by means of effective Service Level Trading between the passive routers and active routers on handling packets with active codes. • Authentication and Authorization The active code can contain compressed form of data to be transported which needs to be authorized before processing them to prevent any malicious activity that may affect the entire network. This adds another level of complexity to the success of active and programmable networks. Routers are Policy Enforcement Points (PEP) on which authorization, accounting and other relevant policies can be enforced. Policy Server (Policy Decision Point-PDP) and Authentication, Accounting and Authorization (AAA) server can be used for authorization, authentication and accounting of the packets of active network. Distributed Substring Authentication Protocol (DSAP) [6] can be used as an effective authentication mechanism
3. Architecture The framework of the “Policy Based Active and Programmable Networks” is given Fig.1. The Diffserv architecture [7] of real time implementation is considered here. The architecture describes the management framework between two Diffserv domains: Domain 1 and Domain 2. Domain 1 consists of an active router A1, two passive routers P1 and P2 and a SLA Trader. An active router is a router which is compatible for processing and routing packets of an active network while a passive router is a router which is capable of routing packets of only a passive network. Domain 2 consists of two active networks A1 and A2, a passive router P1, a Policy Domain and a SLA Trader. The policy domain consists of a Policy Server, AAA (Authorization, Authentication and Accounting) Server, a Policy Management Console (PMC), Directory Server and Other Policy Relevant Servers. The Policy Server serves as the decision taking point in the active network. PMC is the console through which the policies are entered by the administrator. AAA server is responsible for authorization, authentication and accounting in the active network. High end policies are stored in the Directory Server. The communication between the Policy Server and the Directory Server is through
Fig.1 Policy Based Architecture for Active and Programmable Networks
Light Weight Directory Access Protocol (LDAP) [8]. The policy server is connected to other policy relevant servers such as Time servers and Certificates servers. The SLA Trader is the component through which the Service Level Agreement Trading between the routers within the same domain or in different domains takes place. 3.1 Component Interaction through Routers and Policy Server Policies are stored in the directory server while the authorization, authentication and accounting information are stored in the AAA server. Let us consider a packet with code and data arrives in the Domain 1 and routed to P1. P1 is a passive router which is not capable of handling packets of active networks. Initially authentication and authorization of the arrived packet needs to be resolved. Hence P1 queries the nearest Policy Server, which in this case is in Domain 2. The Policy Server takes the relevant polices for that
packet and then contacts the AAA server and responds back. Only if the packet is found to be from a legitimate source it is further processed. All the relevant policies are enforced in all the PEPs. In order to process the arrived active network packet, P1 should send it to any other active router within the same domain or in another domain. To know which neighboring routers are “active routers”, Modified Bloom Filters [5] are used. (Explained in section 3.2). After membership test, a suitable active router is found, which, in this case is A1. Then a Service Level Agreement is traded between the two routers i.e. P1 and A1 with the help of the SLA Trader and using the SLA trading algorithm given in section 4. After a suitable agreement is traded and accepted A1 processes the active network packet. SLA Trader is the component which implements the SLA Trading algorithm given in section 4 fro SLA Trading between the routers. If in case there exists no active router within the same domain and is available in some other domain, then the Service Level Agreement between the two routers which are in two different domains takes place through the SLA Trader component in the two domains. 3.2 Compatibility of active networks with existing routers using Modified Bloom Filters Compatibility of existing passive networks with active networks is achieved by means of Modified Bloom Filter and SLA Trader Component. A Modified Bloom filter [5] is a simple space efficient data structure for representing a set in order to support membership queries. It is a way of using hash transforms [9] to determine set membership. It has lower error rate and higher rejection time when compared to the Conventional Bloom Filter [9] and hence used in real time active networks. Consider an N element Modified Bloom Filter (Vector) used to represent, for example a set of Routers. All cells are initialized to ‘0’. 1 0 0
2 0 0
3 0 0
4 0 0
5 0 0
6 0 0
7 0 0
8 0 0
9 0 0
10 0 0
11 0 0
12 0 0
Let us assume that we use 3 hash transforms for demonstration h1, h2 and h3. The filter is first updated with the word ‘A1’. When the various hash transforms are applied, let us assume the following results: h1 (A1) = 3; h2 (A1) = 7; h3 (A1) = 1; time_of_updating (A1) = ‘00:00:01’;
Next the filter is updated with the word ‘A2’. Again, let us assume the following results after hashing: h1 (A2) = 4; h2 (A2) = 12; h3 (A2) = 9; time_of_updating (A2) = ‘00:00:03’;
After hashing, the filter is updated with the results: 1 A1 00:00:01
2 0 0
3 A1 00:00:01
4 A2 00:00:03
5 0 0
6 0 0
Applying membership test to a router ‘A3’,
7 A1 00:00:01
8 0 0
9 A2 00:00:03
10 0 0
11 0 0
12 A2 00:00:03
h1 (A3) = 12; h2 (A3) = 1; h3 (A3) = 4;
Now, the fields of cells 12, 1 & 4 are compared: Cell 12: Bit: set. Time of updating: 00:00:03 Cell 1: Bit: set. Time of updating: 00:00:01 Cell 4: Bit: set. Time of updating: 00:00:03
Since the times of updating are not the same, ‘A3’ is rejected as a non-member and hence it is not an active router to which the packets can be passed. This process of membership test for all the neighboring routers is tested using the Modified Bloom Filter. In this way a list of all the neighboring active routers are hashed and entered into the Modified Bloom Filter of the passive router. When the passive router wants to find out a neighboring router which can process the packet form the active network then it tests the membership of all the neighboring with the Modified Bloom Filter. When the membership of a neighboring router is confirmed then it means that it is an active router. The passive router then trades the Service Level Agreement with that active router using the SLA Trading Algorithm given in the following section. Once a suitable agreement is agreed upon between the routers the packet is passed on to the active router. In this way compatibility with existing routers is achieved. 4. SLA Trading Algorithm An SLA Trading algorithm for trading in active networks is given in Table 4.1, 4.2. A passive provisioning algorithm does wait for requests from its customers to select as to which resources to buy. Whereas an active provisioning algorithm [10] tries to forecast future needs, and will reserve resources (active routers) in advance. Reserving in advance may be based on statistical information or on trend analysis. UPDATE_PERIOD volume() send bid() accept bid() known dests MIN_REQUIREDBW MAX_ALLOWED_DELAY MAX_ ALLOWED_PL MIN_ REQUIRED_BC MAX_ ALLOWED_QD MIN_ REQUIRED_TP MAX_ ALLOWED_JI MAX_ ALLOWED_C MIN_ REQUIRED_PP MAX_ ALLOWED_COST
Table 4.1: Parameters : Time for updating : volume function for an SLA object (time x bandwidth) : sends an offered SLA to peer : sends an accept message : reachability list : Minimum required bandwidth : Maximum allowed delay : Maximum allowed packet loss : Minimum required buffer capacity : Maximum allowed queuing delay : Minimum required throughput : Maximum allowed jitter : Maximum allowed congestion : Minimum required physical paths : Maximum allowed cost
Once an SLA trader identifies its needs to buy some resource from any one of its peers, it will have to select one of the bids and buy it. The selection of the bid is made based on
the bid’s value for the SLA trader and its price. For bids of equal value, if no special policy is applied, the bid with the first lower price will be selected. The SLA trader will also have to evaluate whether the selected bid is worth buying using a profitability analysis algorithm. This algorithm helps justifying whether buying that bid is profitable; to make money through selling of derived services. This algorithm also ensures that SLA traders won’t build service loops. Table 4.2: SLA Trading Algorithm struct bid { router_dest, // router destination bw, // bandwidth delay, packet_loss, buffer_capacity, queuing_delay, throughput, jitter, congestion, physical_paths, cost } process trading () { while (true) { for each d in known_router_dests { /* buy bids */ if((bw_to_router(d)>MIN_REQUIREDBW) and (delay_to_router(d)
