QAME Support for Policy-Based Management of Country-wide Networks

QAME Support for Policy-Based Management of Country-wide Networks Clarissa C. Marquezan, Lisandro Z. Granville, Ricardo L. Vianna, Rodrigo S. Alves Institute of Informatics Computer Networks Group Federal University of Rio Grande do Sul Computer Networks Group Abstract Policy-Based Network Management (PBNM) has been around for years. It promises to control the behaviour of system using high level policy definitions more easly understandable by humans. However, in some environments, PBNM may fail if the environment characteristics are not considered. For exemple, PBNM systems that use SNMP as a signaling protocol will probably fail in country-wide networks because firewalls will block the SNMP traffic. In this paper we present the developement and deployment of a PBNM system created in the context of the Configuration Working Group (GT-Config) of the Brazilian National Research Network (RNP). The system, named QAME (QoS-Aware Management Environment) uses technologies that we believe to be more appropriate for a country-wide backbone, such as Web Services. The contribution of our work is that is shows that PBNM can indeed be a solution for QoS management even in hostile environments such as the Internet. 1

Introduction Policy-Based Network Management (PBNM) is widely accepted and industry already uses PBNM in some solutions Current tools fail to deploy PBNM in hostile environments (e.g. Internet) New tools should be designed considering the environments where they would be running RNP Configuration Working Group (GT-Config) has developed a PBNM tool that runs on the Brazilian country-wide backbone Open Source software: Web Services, LDAP, SNMP 1. Introduction Policy-Based Network Management (PBNM) [1] is a concept accepted currently and widely recognized by the network management community. Industry has already adopted PBNM in some network management solutions, but the current available PBNM tools often fail deploying policybased management in hostile environments such as the Internet. One of the reasons comes from the fact that the standard bodies tend to define PBNM protocols and information models that are not always suitable for such hostile environments. We believe, however, that PBNM can be indeed deployed in order to manage heterogeneous and country-wide networks, but this requires the development of PBNM tools that consider explicitly the environment where the tools are supposed to be executed. That will guide the choice on management protocol, information models, policy repositories, and so on. The Brazilian National Research Network (RNP) runs a country-wide backbone and has been supporting some working groups to develop innovative services to be deployed in such backbone. This paper presents the PBNM support developed by the RNP Configuration Working Group (GT-Config). As we are going to see, the PBNM support is accomplished using Open Source software that supports technologies such as Web Services, LDAP and SNMP. We believe that the main contribution of this work is it shows that PBNM cannot only be deployed in controlled and restricted environments, but also in heterogeneous and country-wide networks. 2

Policy-Based Network Management Traditional IETF PBNM architecture Policy Policy Repository Repository Policy Enforcement Points Policy Policy Decision Decision Point Point Policy Policy Decision Decision Point Point Policy Policy Decision Decision Point Point 2. Background In this section we review both Policy-Based Network Management (PBNM) and Web Services (WS). Regarding to Web Services, we review them because WS are a key technology used in our solution. 2.1 Policy-Based Network Management The goal of policy-based management is to govern the behavior of a system based on the definition of policies [2]. Although policies can be used to control several different systems, computer networks are probably the most expressive example of the use of policy-based management. PBNM architectures and systems have been proposed by both academy and industry. In our system we based our implementations on the PBNM architecture defined by the IETF (Internet Engineering Task Force) [3] because we believe it has the potential to be more widely accepted. This architecture is composed by four main components: policy tool, policy repository, policy decision point (PDP), and policy enforcement point (PEP). The policy tool is the administrator front-end from where he or she defines and edit management policies that will be stored in the policy repository for future use. When deploying a policy, the policy tool signs the policy decision points that retrieve the policy from the repository and translate it to configuration commands on the policy enforcement points (e.g. network interfaces, queuing disciplines, etc.) located inside the network devices. Although the IETF does not impose any specific protocol, its architecture suggests the use of LDAP (Lightweight Directory Access Protocol) [4] in the implementation of the policy repository, while the protocol to configure the PEPs inside the network devices can vary from CLI/TELNET, SNMP (Simple Network Management Protocol) [5], COPS (Common Open Policy Service) [6], etc. The communication between the policy tool and the PDPs is not standardized or even suggested, leaving to each developer the decision about the protocol to be used. Considering a country-wide network such as the one run by RNP we have implemented it using Web Services (WS). 3

Web Services for PBNM Firewall Internet Firewall WS protocol (e.g. SOAP/HTTP) Management protocol (e.g. SNMP) Policy Policy Decision Decision Point Point Network device 2.2. Web Services for PBNM The Web Services (WS) technology [7] has been gaining more and more attention from the network management community because it seems to have the potential to solve some of the problems investigated for years in the area. One of the key features of WS is that they are based on Web protocols such as HTTP and SMTP. That makes the WS suitable to be used as an integration tool for Web applications. Although the complete WS architecture includes components to support several operations (e.g. publish or discover WS), we have used a very simple composition where a service requester (client) invokes a service provides (server) asking for the execution of a particular operation. In our system, WS are essential because they provide the communication service that allows the policy tool and the PDPs to communicate each other even if the infrastructure between them is the hostile environment of the Internet. This way, the PBNM can be deployed installing PDPs on remote network segments often protected by firewalls, which is the case of the RNP s POPs (Point of Presence). Someone can argue that using WS to bypass network firewalls is not an elegant or adequate solution, but if we compare WS with traditional management approaches (e.g. SNMP) it is possible to observe that the use of WS is a practical and feasible solution. Obviously the use of WS can be prevented if the network firewalls are configured to block HTTP traffic targeted to a PDP, but network administrators tend to allow HTTP traffic easier than they allow, for instance, SNMP traffic. The next section presents the architecture of our developed PBNM system. 4

System Architecture Policies edition and definition PDP x PEP association PEP x Policy association PEP registration PDP registration Policy tool Associations LDAP Policy deployment via Web Services Policy Transfer Control PDP Internal Control Repository Generic PDP Policy Adaptation and Deployment Specific PDP 3. System Architecture In a high level abstraction view, the system is divided in three main components: policy tool (that supports policy edition, PDP and PEP manipulation, and policy deployment), generic PDP (responsible for receiving and evaluating policy conditions that eventually evolve the policy status to active) and specific PDP (accountable to translate high level policy definitions into configuration actions in a determined target PEP). 3.1. The policy tool The policy tool is used by the network administrator to execute the following action accomplished by the policy tool internal modules. Policy edition. The administrator can create new policies, modify already created policies, or remove unused policy from the system. The policy edition communicates with an external LDAP server that implements the policy repository in order to edit the policies the user is dealing with. PEP registration. The target devices, as well as their internal PEPs, need to be registered in the system in order to be managed. Currently, we have been supporting Cisco routers and routers based on hosts running FreeBSD and AltQ [8]. PDP registration. In our system, PDPs are ordinary PCs running WS. These devices also need to be registered in the policy tool in order to be used in the policy deployment process. PDP and PEP association. Every PEP is controlled by a PDP, while a single PDP is able to control several PEPs. This PDP/PEP associations need to be registered in the policy tool as well. This allows the tool to select a proper PDP to be used when a policy needs to be deployed in a PEP. Policy deployment. To deploy a policy the administrator selects the desired policy and the target PEP. Then the policy tool selects the appropriate PDP and delivers the policy to it. Deploying a policy also creates an association between the policy and the target PEP. 5

PDP Details Policy and PEP information Policy Transfer Manager (Web service) Schedule Evaluation QoS Evaluation PDP Manager Repository Generic PDP Policy Adaptation Policy Deployment Specific PDP Configuration Actions PEP 3.2. The Policy Decision Point On the PDP device, the process to deploy a policy starts at the Policy Transfer Manager layer. A Web service resides at this layer, it receives the policy identifier and PEP information in which this policy will be loaded. Based on the policy identifier, the web service searches LDAP directory and downloads the policy to the PDP local repository, associating the policy with the respective PEP that must be configured. Besides, this web service is also able to provide information concerning with applied policies of each controlled PEP, each available PEP to be configured, logs from the operations performed by the PDP, and it provides issues to remove a policy even if it was not expired. From the moment a policy is stored at local repository, the PDP Manager (a PHP script) performs periodic evaluations of the policies in this repository. Time and QoS policy components are evaluated, respectively by Scheduler and QoS Evaluation modules. Whether a policy becomes valid, i.e., temporal and QoS requirements become true and expressed in a correctly manner, PDP Manager registers this on the repository and signals the Policy Adaptation layer, informing the specific PDP issues that a policy must be translated and deployed. Policy Adaptation layer gets the stored policy information from the repository and then adapts it to configuration actions that can be understood by the PEPs controlled by this PDP. Then, Policy Deployment layer is called and the policy is effectively loaded to the device. This transfer may occur in different manners, depending on the devices capabilities. For example, we can use SNMP and TFTP to communicate and transfer a configuration file generated by the Policy Adaptation Layer, or maybe use remote commands to perform the configuration actions. The same way PDP Manager, Policy Adaptation and Policy Deployment layer are implemented as PHP scripts. 6

Implementation Developed upon PBNM concepts Integrated into QAME plataform QAME (QoS Aware Management Environment) Modular Web-based Open Source Software, Web Services, SNMP and LDAP tecnologies 4. Implementation The QoS management system developed by GT-Config follows PBNM model of IETF. Through a graphic interface it is possible to include devices, PDPs, and PEPs in network maps, as well as create and edit network management policies. The QAME policy support regards, explicitly, QoS aspects. QAME is composed by several modules, implemented in PHP, Flash and using MySQL to keep its information. The PBNM support in our system is provided by using open source software and technologies such as Web Services, SNMP and LDAP. This system allows QoS configuration actions to be performed through the definition of policies in high level, without regarding the specificities of the device into which it will be deployed. By the translation processes developed in our system, the same QoS policy is able to be deployed in different devices. For example, the same reservation bandwidth policy can be deployed into a CISCO router or into an IBM router. This facility allows network managers to concentrate their efforts to find out solutions for their problems without worrying about implementing them. 7

QAME Interface 5. QAME user interface In QAME, the interaction with registered devices occurs through the resource map (see above) of QAME. This map is implemented using Flash and shows network elements as images that characterize them. Each network segment is represented by a cloud. Hosts, routers, and switches have also their own images. In QAME environment, each device can have capabilities associated to it. A capability is a functionality performed by a device. There are two capabilities related to PBNM in QAME: "PDP" and "PEP". A PDP device must be configured to inform which PDP type it implements (e.g. PDP for CISCO, IBM, or ALTQ target device). A PEP device has user interfaces to define the PDP device that controls the PEP and to deploy policies. 8

Policy Creation and Definition 5.1. Policy Creation and Definition The utilization of a specific language for policy creation obligates users to learn a new language. Avoiding this kind of problem, QAME implements graphic interfaces to the definition of policies and their components: actions, flows and schedules. The issues that can be "addressed" in each of this components belong to PCIM [9] and PCIMe [10] models. In action definition process it is possible to specify bandwidth reservation, to define the value of the DS field (DSCP) for the IP packet of a differentiated services aggregate, to associate priorities and to define different loss levels (dropping of packets). In flow definition the user can construct filters using the following IP header fields: source and destination IP address, source and destination port, transport protocol (TCP, UDP, ICMP) and DSCP. Moreover, address mask, IP range and port range are also accepted to describe sets of networks and/or services. For schedule definition, the supported issues are: month, day of month, day of week, time of day and policy validity period. QAME has also an interface where the user can group actions, flows and schedules to form policies, enabling the reuse of this components. In order to easy the policy creation and edition processes, QAME has also a policy wizard. After policy creation and before policy deployment, the user can visualize how the policy translation will be performed in a specific PDP. This feature helps the afraid operator to check whether the final configuration to be deployed in a target device is adequate or not. 9

Policy Deployment 5.2. Policy Deployment QAME has a simplified user interface for policy deployment. This interface is responsible for deploying and removing policies in QAME, and is also responsible for informing which policies have been already deployed to each network interface inside a specific device. In order to deploy a policy into a device, the user must choose the policy to be deployed, the network interface (PEP) of the target device, and the direction which the policy must be performed (input or output). So, the policy is transferred to the PDP that controls such PEP. To remove policies, the user choose the policies and then click in "Remove Policy" button. QAME maintains logs of policy deployment and removal operations for each PEP, or for all PEPs controlled by a PDP. This log helps network administrators because it registers not only operations performed through the graphical interface but also real configuration actions dispatched from the PDPs at the time the policy schedule becomes true or false. 10

System Deployment 6. System Deployment The system deployment scenario resides on the country-wide backbone of Brazilian National Research Network (RNP), as mentioned before. This network is composed for several points of presence (POPs), more specifically, each Brazilian federated state has a POP (as presented in the figure above). They have their own administrative domains and policies, and each POP is in charge of configuring the devices inside its network. Allowing the POPs of RNP taking advantages of our system, we have installed a copy of QAME system in each one of them. So they are be able to control the devices placed inside their administrative domains. Reaching the main goal, i.e., configuring the devices along the countrywide backbone, each POP is accountable to configure its devices. So the POP administrator should deploy a policy inside the PEPs that compose his/her administrative domain. Regarding policies, the LDAP repository is shared among all QAME environment copies, i.e., a policy stored at LDAP proceeding of one POP is available for the whole POPs. At this moment, our system have been tested in four POPs of the RNP. 11

Conclusions QoS management is still a practical problem because operators tend to have few knowledge about QoS configuration Developed system is effective because it considers the hostile environment where it would be running The current usage of our system is due to: the use of Web Services the use of policies as a mechanism to abstract the details of the QoS-enabled devices 7. Conclusions In this paper we have presented the PBNM support implemented in the QAME system as part of the efforts to deploy PBNM in the country-wide backbone of the Brazilian National Research Network (RNP). The QAME policy support was developed using the PHP language, while the user interface has been enhanced through the network maps implemented with Flash presentation technology. Although the developed system is currently being tested by four RNP s POPs, the feedback already received from the POPs operators allows us to list the following observations: - QoS management is still a practical problem because operators tend to have deep knowledge about routing and common tasks, but QoS configuration, although needed, is normally less known; - PBNM is an effective approach for QoS management, at least for the RNP POPs operators, because it easies the configuration of QoS-enabled devices; - Although it is a preliminary conclusion, LDAP has the real potential to allow the sharing of policy definitions among different policy users. The above observations could only be achieved because the developed system is effective. And the system is effective because it was developed explicitely considering the hostile environment where it would be runing. We do believe that the current usage of our developed system is a consequence of the use of Web Services (to support the system communications) and the use of policies as a mechanism to abstract the details of the QoS-enabled devices. 12

Future Work Improve graphic interface issues Extend PDP support Extreme and IBM devices Develop an hierarchical PBNM to brazilian country-wide backbone 8. Future Work First issue on future work is related to the improvement of the graphic interface. Based on the feedback from the users of our system we notice that there are some aspects that could be better expressed in our interface. For example, it would be better presenting in a graphical manner the components of a flow at the moment of its definition. So this could ease the system operation. A second issue that must be regarded as a future work is extending the supported PDPs types. Nowadays we have support to configure CISCO and ALTQ devices. But we also intend to provide QoS configuration facilities to Extreme and IBM equipments. As a main future work, we intend to provide solutions related to the distributed scope where our system is placed. The scenario where the developed system is residing, the Brazilian country-wide backbone, is composed by different administrative domains with different needs. However, sometimes the same action must be configured in major part of this country-wide backbone. Indeed, it is interesting to develop a system that is able to support the definition of a policy by the high level administrator and to spread it automatically along the low level administrative domains. We call this an hierarchical PBNM approach. 13

Thanks for your attention! Contact: Clarissa C. Marquezan (clarissa@inf.ufrgs.br) Lisandro Z. Granville (granville@inf.ufrgs.br) Ricardo L. Vianna (rvianna@inf.ufrgs.br) Rodrigo S. Alves (sanger@inf.ufrgs.br) Computer Networks Group http://networks.inf.ufrgs.br Institute of Informatics Federal University of Rio Grande do Sul, Brazil References [1] M. Sloman. Policy Driven Management For Distributed Systems, Plenum Press Journal of Network and Systems Management, Vol. 2, no.4, pages 333-360, December 1994. [2] A. Westerinen et al., Terminology for Policy-Based Management, RFC 3198, IETF, November 2001. [3] J. Halpern and E. Ellesson. Policy Framework (policy) IETF Working Group. Disponível em: <http://www.ietf.org/html.charters/policy-charter.html>. [4] M. Whal, T. Howes and S. Kille. Lightweight Directory Access Protocol (v3), RFC 2251, IETF, December 1997. [5] S. Waldbusser, J. Saperia and T. Hongal. Policy Based Management MIB darf-ietfsnmpconf-pm-15 (Work-in-progress), DRAFT, IETF, 2004. [6] D. Durham et al., The COPS (Common Open Policy Service) Protocol, RFC 2748, IETF, January 2000. [7] F. Curbera, M. Duftler, R. Khalaf, W. Nagy, N. Mukhi, and S. Weerawarana. Unraveling the Web Services Web: An Introduction to SOAP, WSDL, and UDDI. IEEE Internet Computing, Vol. 6, Issue 2, pages 86-93, March/April 2002. [8] K. Cho. Managing Traffic with ALTQ. In Proceedings of USENIX 1999 Annual Technical Conference: FREENIX Track, Monterey CA, June 1999. [9] B. Moore, E. Ellesson, J. Strassner and A. Westerinen. Policy Core Information Model -- Version 1 Specification, RFC 3060, IETF, February 2001. [10] B. Moore. Policy Core Information Model (PCIM) Extensions, RFC 3460, IETF, January 2003. 14