Policy Based Network Management of a Differentiated Services domain using the Common Open Policy Service protocol

Transcription

1 Policy Based Network Management of a Differentiated Services domain using the Common Open Policy Service protocol Adam Burke, Neco Ventura Department of Electrical Engineering, University of Cape Town, Rondebosch, Cape Town, South Africa {aburke, neco}@crg.ee.uct.ac.za Abstract There is a demand for enhanced levels of service to be provided over the Internet. The IETF has specified the Differentiated Services architecture as a means of providing distinct classes of service to data packets. As the Differentiated Services architecture does not have any explicit signalling protocol it is necessary to have a mechanism for achieving per-packet admission control. Policy based networking has been proposed as an abstracted management framework suitable for the administration of large heterogeneous networks. This framework can be used to provision and control access to a Differentiated Services domain. This paper describes the components that are required in a policy based network management system. These are to be constructed and assembled with the intention of managing a Differentiated Services domain. A number of Linux routers will be used to constitute the Differentiated Services network. Once the testbed has been established, investigations will be carried out as to the suitability and scalability of policy based network management to administer the resources of a Differentiated Services domain and control access to those resources. Index Terms Differentiated Services, Quality of Service, Policy Based Networking, COPS. I. INTRODUCTION A. Need for Quality of Service and Policy Based Networking The Internet has traditionally been used as a medium for the transport of non real-time data. A best effort service is adequate for this purpose. More recently, however, the Internet has been used to transport real-time media such as voice and video. Such media have far stricter Quality of Service (QoS) requirements. Network service providers need a scalable means of providing measurable quality of service to their customers to The authors would like to thank Telkom SA, Siemens, the National Research Foundation (NRF) and the Department of Trade and Industry (DTI) for supporting this research project. increase their revenue and ensure that their customers are satisfied. Ideally, service providers should implement lightweight traffic differentiation schemes that add value without adding significant additional operational complexity to their network. Two elements are required to achieve this goal. Firstly, a QoS architecture needs to be implemented on the routers in the network. Secondly, a management framework needs to be provided to manage the provision of the enhanced services. Neither the QoS architecture nor the management framework should incur significant labour or resource costs. They should instead increase the earning capacity of the network. Furthermore, they must be hugely scalable to support the current large size networks as well as future networks that will be engineered as the Internet grows at a fast and consistent rate. The Differentiated Services architecture (DiffServ) can provide packet level service differentiation with little additional complexity or processing required within the routers of a DiffServ domain. A Service Level Agreement (SLA) between the customer and the service provider acts as a service contract specifying the type of service that a customer should be given [1]. Policy Based Networking (PBN) facilitates the translation of business policies and contracts to configuration information for distribution to the routers in an administrative domain. This allows greatly simplified management of the domain. Using PBN it is possible to control and limit access to resources and thereby ensure that the DiffServ network is able to meet its expressed QoS guarantees. B. Differentiated Services The Differentiated Services architecture was released by the IETF in This QoS architecture is focused on scalability and therefore limits the amount of additional processing that must be performed by network nodes to provide enhanced services. To achieve this DiffServ does not perform any per-flow processing and limits the amount of state that must be maintained within the core of the network. DiffServ aggregates traffic into a small number of classes of service, known as behaviour aggregates. When a packet enters a DiffServ domain it must be classified at the network boundary according to the service that it should receive within that domain. In the process of

2 classification the packet is assigned to a behaviour aggregate that describes how the packet will be treated within the domain. The assignment of a packet to a behaviour aggregate may be based on a number of fields in the IP packet header including, but not limited to, its source address, destination address, source port, destination port, and protocol. This assignment is communicated to other routers within the domain by setting the DiffServ Code Point (DSCP) of the packet to a specific value. This is the Type of Service field of the IPv4 header or the Traffic Class field of the IPv6 header [2]. Thus the information required by routers within the core of the network to classify packets according to the service they should receive is contained in a single field of the packets IP header. This marking only needs to happen once and so there is a reduction in the cumulative amount of processing required to classify packets as multi-field classifiers are only required at the entry points to a Differentiated Services domain. More importantly, this method does not require DiffServ nodes to maintain state for individual flows as each packet contains a mark specifying the service it should receive. A core router may be servicing hundreds of thousands of flows so this is a significant reduction in overhead. DiffServ has no explicit signalling protocol so no processing of signalling messages is required by the routers in a DiffServ domain. As there is no signalling protocol for making reservations, it is essential for the ingress routers to a DiffServ domain to perform some form of admission control. This is achieved using two mechanisms. Firstly, traffic is only assigned to an enhanced service level if the customer has paid for such a service. Secondly, that customer may only send data at a rate less than or equal to that which is described in their SLA. Ingress routers may condition incoming traffic to achieve this. Using these two mechanisms it is possible to ensure that the SLAs of the network may be met and the required QoS provided to the customers. The IETF has described two classes of service that can be implemented on DiffServ routers. The Expedited Forwarding (EF) behaviour provides a virtual leased line service. It was designed for traffic that requires strict bounds on delay as well as guaranteed bandwidth. This service is most suitable for low bit rate, delay sensitive applications like voice. Packet level admission control is used in that EF packets that exceed their negotiated rate are dropped at the ingress to the Diffserv network. This ensures that the network does not become flooded with EF streams and starve other traffic. The Assured Forwarding (AF) behaviour was designed to provide a service similar to that which a lightly loaded network would provide. It was intended for traffic types that require guaranteed bandwidth with less stringent delay requirements. AF packets that exceed their negotiated rate are re-marked to a higher drop precedence at the ingress to the DiffServ domain. The AF behaviour can be used to provide varying grades of service based on the amount charged for each service. This is referred to as Olympic service where gold, silver, and bronze payment and service options are available. C. Policies in Networking Initial attempts to provide management structures to networks were focused on individual network elements. This model worked well in small networks but with the enormous stretch of current networks and the need to dynamically change the behaviour of the network this is no longer a suitable approach. Management of a large number of heterogeneous network nodes can easily become a complex and time consuming administrative task. This is particularly true if each device has to be individually re-configured to provide new services or meet new SLAs. A policy is a definite goal, course or method of action to guide and determine present and future decisions. In the context of networking, a policy is a combination of rules and services where the rules define the criteria for resource access and usage to provide services. Policies are seen as a way to administer, manage and control access to the resources within a network through the use of generalised rules. This abstraction of the management functionality enables this task to be automated. The policies of a network determine and limit which subnetworks or customers have access to enhanced service levels within the network and what rate they can send data to that behaviour aggregate. By controlling and limiting access to resources the service provider can ensure that the network does not become congested and retains its ability to meet its SLAs. D. The Problem The problem investigated for this paper is the distribution of policy information with the aim of managing a Differentiated Services domain. PBN coordinates admission control and access to resources in the DiffServ network. A network administrator should be able to control the service given to individual customers and ensure that SLAs with those customers are adhered to. The level of service given to an individual packet should correlate to the policies and SLAs of the service provider. These policies must therefore be distributed to the network nodes that handle the packets and provide the services. The aim of this paper is to describe the work that is being carried out to set up a DiffServ network that is managed by a policy based network management framework. Investigations will be carried out as to the suitability and scalability of the implemented solution in terms of admission control and resource usage. II. POLICY BASED NETWORK MANAGEMENT A. Overview of Architectural Components In order to manage a network using policy based networking certain architectural building blocks are required to support this management framework.

3 The required components are A policy repository A policy management tool A number of policy enforcement points A policy server or policy decision point A means of communicating between the policy decision point and the policy enforcement point. These components are illustrated in Fig. 1 below and will all be described in further detail here. Fig. 1. Overview of Policy Based Networking Architecture In a policy based networking framework a policy repository stores the network s policies. A policy repository is typically implemented in a distributed directory. The Lightweight Directory Access Protocol (LDAP) [3] can be used to access this directory. Data is stored using the Policy Core LDAP Schema [4]. By using a distributed directory the management system is more fault tolerant and the processing load is also distributed over a number of servers. Data within the policy repository is updated and modified by the policy management tool (PMT). This tool may provide a graphical user interface to allow network administrators to dictate how the different categories of DiffServ routers within a domain should be configured. This information will then directly affect how packets within the network are to be treated. Ingress and egress routers should be configured differently to routers in the core of the DiffServ domain because they have different functionality. The Policy Enforcement Point (PEP) is a packet level network node that is responsible for treating the packets in a manner that is consistent with the policies. It may simply be a router with some additional software enabling it to receive and interpret policy information. The Policy Decision Point (PDP) performs the job of communicating the policies from the repository to the PEP. The PDP must first retrieve the required subset of information from the policy repository that is relevant to the PEP, and this data must then be sent to the PEP for configuration. There may be a number of PDPs in a DiffServ domain to decrease the effect of any failures and also to distribute the processing load. The Common Open Policy Service (COPS) protocol [5] enables transmission of policy information between the PEPs and the PDPs. The COPS protocol allows two modes of operation; requests for policy data may be either outsourced or provisioned. In the outsourced model, requests are sent from the PEP to the PDP for each and every local decision. This may, for example, be to determine if an RSVP reservation request should be accepted. This model typically has a significant network usage and processor overhead requirement. It is therefore not suitable for use in a DiffServ domain where one of the primary intentions is to achieve a scalable infrastructure. In the provisioning model of COPS operation the PEP requests relevant policy and configuration information from the PDP. The PDP responds by sending it the appropriate data. The PEP need not request further information from the PDP but the PDP may send additional data or changes in the policy to the PEP as that data becomes available. COPS Usage for Policy Provisioning (COPS-PR) [6] is an extension of COPS to support the provisioning model. As this discussion is focused primarily on the use of PBN for providing differentiated services, the provisioning model will be used as the basis for further explanations and descriptions. B. Common Open Policy Service protocol The COPS and COPS-PR protocols are used for communication between the PDP and the PEPs. COPS is intended to be a scalable protocol that allows policy servers to communicate policy decisions to network devices. COPS is an extensible protocol and was designed to support multiple types of policy clients. It leverages the advantages of self-identifying objects to this end. It can thereby transport diverse client-specific information and a variety of policy information. Currently recognised client types include an RSVP client [7] and a DiffServ client [8]. This paper focuses solely on the DiffServ client type. COPS is a simple client/server protocol. The client in this case is the PEP and the server is the PDP. COPS requests from a PEP are typically in response to some operational event that requires the knowledge of some policy information. In COPS-PR requests from the client describe the PEP and its configurable parameters. Since these parameters change infrequently there will be few requests sent from the PEP to the PDP once the PEP has received its initial configuration information. In this manner, there is minimal management traffic and processing of policy information so the PEP s resources are dedicated to its primary purpose of serving packets. COPS uses TCP to ensure reliable transmission of policy information. This allows the use of state sharing and synchronisation mechanisms and the exchange of differential updates. The PEP initiates the TCP connection which is maintained as long as both the policy elements are up. The use of a single TCP connection also guarantees that only one PDP sends policy information to a PEP at one time. Each COPS-PR message carries a set of policy data. The data structure used for this purpose is a Policy Information Base (PIB). The PIB is named in the COPS-PR message and

4 can be used to push policy information from the PDP to the PEP or to send information and notifications from the PEP to the PDP. The usage of standardised PIBs results in abstracted management data which is understood throughout the domain. Therefore there is no need to use different formats for the policy information in a heterogeneous network or to have additional policy information relating to routers from different manufacturers. For this project policy data is sent in Differentiated Services Quality of Service Policy Information Base tables [8] within a COPS message. C. Policy Enforcement Point A PEP is a policy enabled network node. As its name implies it is responsible for ensuring that the policies of the business are adhered to in the treatment of individual packets. The primary role of a PEP is to service packets in a manner that is consistent with the network policies. If the PEP is in the core then it must simply provide service to packets that is commensurate with their DSCP. If the PEP is at the ingress to the DiffServ network then it will have to use a multi-field classifier to assign incoming traffic to behaviour aggregates and mark the packets accordingly. In marking the packets for a specific type of service, admission control is being performed. Admission is granted if the packet originates from a customer with a valid SLA for enhanced service. If data is received from a customer at a rate greater than that which has been agreed upon then a lower level of service may be provided to out of profile packets. The PEP may also condition incoming data according to the bandwidth that has been provisioned for individual customers and behaviour aggregates. This functionality ensures that the core nodes do not become congested and can thereby meet the QoS requirements of the traffic that is being transported. A crucial part of PBN is the concept of roles. A network administrator must assign a combination of roles to each of the interfaces on a PEP [9]. For example, an interface may be an ingress to the DiffServ domain, or it may be in the core of the domain. Roles may also communicate information about an interface s speed and duplex state. In this manner, the exact details of each interface are abstracted to allow management data to be understood across the domain. D. Policy Decision Point The PDP provides the interface between the policy information stored in the policy repository and the PEPs where that information must be used to provide QoS to packets. The policy repository may be distributed over a large geographical area but can be easily accessed by the PDP with the use of LDAP. LDAP supports referrals and replication to aid this process. When a PEP establishes a COPS connection to a PDP, the PDP must determine what policy data needs to be sent to the PEP. The PEP may inform the PDP of what policy information it has stored locally and it will also send information about the roles of its interfaces. Based on this information, the PDP sends the necessary configuration and provisioning data to the PEP in PIB tables contained in COPS messages. In the configuration or provisioning model of COPS operation a PDP proactively provisions and configures a PEP s resources in response to changes to the policy repository. Any required change to a PEP s configuration may be performed in bulk where the entire router QoS configuration is changed or may be performed incrementally where, for example, a single classification rule needs to be changed. Network resources are provisioned in a quasi-static manner with changes happening on an administrative timescale of days or weeks. III. IMPLEMENTATION The system to allow policy based network management of a DiffServ domain will be implemented on a testbed of Linux routers which will act as PEPs. A single Linux server will be used for the PDP, policy repository, and PMT. The queuing disciplines included in the Linux kernel will be used for servicing the IP packets. Netfilter will be used for marking the DSCP IP header field of packets entering the network. Fig. 2 below shows a logical view of the proposed testbed network. In practice, a role is an administrator-supplied text string. The PDP uses the information about the roles of an interface to decide what policy information is relevant and needs to be sent to that PEP. Once a PEP has sent information about its capabilities and roles to the PDP it will receive the necessary data for configuration and provisioning of its resources. In normal operation the PEP may also send unsolicited reporting and accounting information to the Policy Decision Point for later use in billing applications. Fig. 2. Logical view of testbed network

5 A. Linux By utilising the traffic control tools available in the Linux kernel (version ) a number of policy-enabled Linux routers will be set up. Linux was chosen as the operating system for use in this project for a number of reasons. Primary amongst these is its suitability for the development of networking applications. For the 2.2 release of the Linux kernel the networking subsystem was completely redesigned. The new networking code that was produced as a result of this has greatly enhanced the performance and feature set of the Linux operating system. The new routing, filtering, and classifying code has more features than are provided by many dedicated routers, firewalls and traffic shaping products. The process of redesigning the networking subsystem also removed the cumulative effects of repeated upgrades and fixes that were applied to the previous set of code. Linux has a sophisticated system for bandwidth provisioning called Traffic Control. This system supports various methods for classifying, prioritising, sharing, and limiting both inbound and outbound traffic. There are a number of packet scheduling algorithms supported by current versions of the Linux kernel. These include Class Based Queuing, Hierarchical Token Bucket, Clark-Shenker-Zhang and a priority queue packet scheduler. Classless queues supported are Random Early Detection, Stochastic Fair Queuing, True Link Equalizer, Token Bucket Filter and Generic Random Early Detection [10]. Support for Differentiated Services on Linux is also included in the Traffic Control framework. Support for Diffserv has been integrated into standard kernel releases since version Packets can easily be classified into classes using only the DSCP or some combination of the source and destination port and IP address [11]. It seems that either Linux routers are not yet ready for commercial networks or commercial networks are not yet ready for Linux routers. In a research environment, however, Linux provides all the necessary functionality for performing networking experiments and investigations at very low cost. B. COPS Implementation The Network Protocols Group at the Tampere University of Technology has developed an implementation of the COPS protocols with COPS-PR extensions [12]. This open source implementation will be used to provide the communications mechanism between the PDP and the PEP. Intel has released a reference implementation COPS Client software development kit. Unfortunately, the server software is only released in pre-compiled binary format which makes it unacceptable for use in this project. C. OpenLDAP LDAP is a mature technology and there are a number of tools available to support this protocol. OpenLDAP was chosen for use in this project because it is a robust, commercial-grade, open source suite of applications and development tools. There is a large developer base for this suite and its usage on Linux is well documented. D. Applications to be developed The applications for the PDP, the PEP and the PMT are currently under development. Furthermore, algorithms will have to be designed with the purpose of translating information from the forms found in these various elements into formats that can be used elsewhere. This is represented in Fig. 3 below. Fig. 3. Formats used for transmitting policy information Information from the web interface of the PMT will have to be translated into an LDAP schema for storage in the policy repository. The PDP will have to read the information from the policy repository and then convert that into appropriate PIB tables for distribution to PEPs. The PEPs will then have to decode the PIB tables into an XML schema. The Linux Traffic Control Next Generation framework uses this XML schema to produce commands and configuration information for use by the tools that configure the traffic control functionality of the Linux kernel. A simple web based PMT will be designed to allow configuration information to be entered and changed. This will also facilitate the graphical display of current configurations and data paths. Secure HTTP and appropriate authorisation mechanisms will be used to ensure the integrity of the system. CGI scripts will be used for processing the information entered by the network administrator and the conversion of this information into useful LDAP data. E. Investigations to be performed Once the necessary components have been designed and implemented, studies will be carried out on the DiffServ and PBN management frameworks. Experiments and calculations will primarily be aimed at determining the feasibility of using PBN to manage a DiffServ domain in terms of service provision and admission control. Growth and scalability are of significant concern in IP networks so it will be necessary to ascertain the scalability of this architecture. Before the scalability of the PBN management system can be measured, it must be shown that this solution is able to manage the domain to provide services according to the requirements of those using the network. It is also very important for the network to maintain a free flow of traffic

6 with limited congestion to ensure that the QoS requirements of the traffic streams are met. One of the reasons that DiffServ is so scalable is the small amount of additional processing that is required to classify packets according to their required class of service. This measure will be quantified for a Linux router. Other processing loads come in the form of the DiffServ queuing and packet scheduling algorithms. The limiting factor in terms of the scalability of the PBN system is the PDP. The PDP must service a large number of PEPs within the DiffServ network. The requirements on the PDP in terms of memory and processing will be measured for each PEP that the PDP will need to communicate with. [9] R. Sahita, S. Hahn, K. Chan and K. McCloghrie, RFC 3318: Framework Policy Information Base, IETF, March 2003 [10] B. Hubert et al, Linux Advanced Routing & Traffic Control HOWTO, March 2003 [11] W. Almesberger, Linux Network Traffic Control - Implementation Overview, Proceedings of 5th Annual Linux Expo, pp , May 1999 [12] J. Lemponen, Implementation of Differentiated Services policy information base on Linux, Master s thesis, Tampere University of Technology, IV. CONCLUSION Differentiated Services has been introduced as a scalable means of providing different levels of service to packets in an IP network. It has been explained that as DiffServ has no explicit signalling protocol, it needs some means of performing admission control to ensure that it is useful in providing QoS to traffic streams. Policy based networking has been described and proposed as a means of managing a DiffServ domain. It allows centralised, abstracted management of the routers within the domain and hence eases the administrative burden. A testbed DiffServ network will be set up and managed using policy based networking so that studies can be performed on it. Investigations will be focused on the suitability and scalability of the implemented solution. The system must be suitable for performing admission control and providing guaranteed service levels. It must be scalable to manage large networks and many customers. REFERENCES [1] D. Grossman, RFC 3260: New Terminology and Clarifications for Diffserv, IETF, April 2002 [2] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang and W. Weiss, RFC 2475: An Architecture for Differentiated Services, IETF, December 1998 [3] J. Hodges and R. Morgan, RFC3377: Lightweight Directory Access Protocol (v3): Technical Specification, IETF, September 2002 [4] J. Strassner, B. Moore, R. Moats and E. Ellesson, Policy Core LDAP Schema, draft-ietf-policy-coreschema-16.txt, October 2002 [5] D. Durham, J. Boyle, R. Cohen, S. Herzog, R. Rajan and A. Sastry, RFC2748: The COPS (Common Open Policy Service) Protocol, IETF, January 2000 [6] K. Chan et al, RFC3084: COPS Usage for Policy Provisioning (COPS-PR), IETF, March 2001 [7] S. Herzog, J. Boyle, R. Cohen, D. Durham, R. Rajan and A. Sastry, RFC 2749: COPS usage for RSVP, IETF, January 2000 [8] K. Chan, R. Sahita, S. Hahn, and K. McCloghrie, RFC 3317:Differentiated Services Quality of Service Policy Information Base, IETF, March 2003