Substituting COPS-PR: An Evaluation of NETCONF and SOAP for Policy Provisioning Theo Ferreira Franco, Weldson Queiroz Lima, Giancarlo Silvestrin, Rafael Corezola Pereira, Maria Janilce Bosquiroli Almeida, Liane Margarida Rockenbach Tarouco, Lisandro Zambenedetti Granville Institute of Informatics – Federal University of Rio Grande do Sul – Porto Alegre, Brazil Email: {tffranco, wlima, gsilvestrin, rcpereira, janilce, liane, granville}@inf.ufrgs.br
Andr´e Beller, Edgard Jamhour, Mauro Fonseca Pontifical Catholic University of Paran´a – Curitiba, Brazil Email: {beller, jamhour}@ppgia.pucpr.br,
[email protected] Abstract— The COPS-PR protocol has been defined by the IETF to provide policy provisioning in networks managed through the Policy-Based Network Management approach. Although some network players already ship their devices with proper COPS-PR support, there is a trend in the industry and in the IETF of discontinuing COPS-PR as a policy protocol. Meanwhile, two other protocols, namely NETCONF and SOAP, have been seriously considered in the network management field. This paper proposes and evaluates both NETCONF and SOAP as substitutes for COPS-PR, presenting how these protocols can be used for policy provisioning. The performance evaluation of NETCONF and SOAP against COPS-PR addresses two main aspects: network usage as a result of protocol overhead, and protocol delay as a result of protocol message processing. This study shows that both NETCONF and SOAP are interesting and feasible replacements for COPS-PR, but require appropriate modeling when deployed in networks.
I. I NTRODUCTION Policy-Based Network Management [1] has been proving to be a feasible approach for the management of distributed systems and networks. The effective employment of PBNM, however, depends on proper network protocols to enable the communication between policy entities such as policy servers and clients. The Internet Engineering Task Force (IETF) has been actively working on PBNM standardization, for example, defining the Common Open Policy Service (COPS) [2] protocol and Policy Information Bases (PIBs) [3], which specify policy objects manipulated by COPS. COPS has also been extended through the definition of COPS for policy provisioning (COPS-PR) [4], more suitable for Differentiated Services (DiffServ) [5] networks, which contrasts with the base COPS protocol that is more proper for Integrated Services (IntServ) [6] networks operating with the Resource reSerVation Protocol (RSVP) [7]. Recently, two other protocols started to be seriously considered in the network management field: SOAP and NETCONF. The Simple Object Access Protocol (SOAP) [8] is basis for the Web services architecture [9]. Although SOAP has been conceived to allow general inter process communication among Web applications, it is being tailored specifically for systems management by industry consortiums, such as OASIS [10] and WS-Management [11]. Meanwhile, the NETCONF
configuration protocol [12] is being standardized by the IETF motivated, among other reasons, by the failure of its Simple Network Management Protocol (SNMP) [13] framework in providing proper support for device configuration. Although SOAP and NETCONF have been originally defined outside the PBNM world, such protocols can be used for policy provisioning replacing COPS-PR. That would enable, for example, the communication among policy entities (e.g., policy clients and servers) located in different administrative domains having the Internet as an intermediate network. Such communication is possible because both SOAP and NETCONF can be layered on top of Internet protocols such as HTTP, SMTP, and FTP, which are often allowed by Internet firewalls on the boundaries of administrative domains. COPSPR traffic, however, is unlikely to receive the same treatment, ending up being confined to each domain. Most important, however, is the fact that the adoption of COPS-PR in successful proportions has been informally reported to have failed, leading the IETF not to incentive further developments of the protocol, and then opening new standardization fronts such as the one that defines NETCONF. COPS-PR is a connection-oriented, binary encoded protocol, while SOAP and NETCONF, although also being connection-oriented, have their messages encoded in verbose eXtensible Markup Language (XML) [14] documents. This can decisively impact on the performance of PBNM, for example, affecting the bandwidth consumption and response time when new policies need to be deployed in managed networks. In this paper we investigate the performance of SOAP and NETCONF for policy-based management replacing COPS-PR in a DiffServ testing environment. In order to execute such comparison we have implemented prototypes that introduce in SOAP and NETCONF the same policy handling operations supported by COPS-PR. Considering that COPS may not evolve to a de facto standard management protocol, this performance evaluation is important because it presents the pros and cons in adopting alternative solutions for policy provisioning instead of COPS-PR. The remainder of this paper is organized as follows. Section 2 reviews COPS-PR, NETCONF, and SOAP. In Section 3 we
Proceedings of the Seventh IEEE International Workshop on Policies for Distributed Systems and Networks (POLICY'06) 0-7695-2598-9/06 $20.00 © 2006 IEEE
present the mapping of COPS-PR operations to NETCONF and SOAP. Section 4 introduces our testing management scenario and two policies used in our evaluations, which are presented and analyzed in Section 5. Section 6 finishes this paper presenting concluding remarks and future work. II. BACKGROUND COPS-PR, NETCONF, and SOAP share some common features, but are also different in other aspects. This section reviews these three protocols pointing their similarities and differences. A. COPS-PR COPS-PR defines a simple management model where network devices (PEPs - Policy Enforcement Points), using TCP, are permanently connected to a (usually) single policy server (PDPs - Policy Decision Points) in order to retrieve updated policy information. Each PEP has an internal Policy Information Base (PIB) that holds policy information consistent with those found at the associated PDP. Since several events may occur in a computer network (e.g., PDP/PEP connection lost) and in the PBNM environment (e.g., deployment of new policies) that may lead the policy information at PEPs and PDPs to be inconsistent with each other, COPS-PR defines a set of messages to handle the necessity of synchronizing and updating PEP’s PIBs according to the policies found at the PDP. One single PEP may in fact have several policy clients, each one responsible for a non-overlapping policy area (e.g., QoS, security, etc.). For the sake of simplicity, from now on, we will assume only one policy client per PEP. In addition, we also assume that such policy client is responsible for dealing with DiffServ policies, to be used in our evaluation experiments. In the remaining of this paper, the terms PEP and client may thus be used interchangeably to refer to the single process running inside a managed device responsible for implementing the COPS-PR support. After device booting or a TCP connection loss, clients open a new connection with its associated PDP and attempt to establish a policy session sending the client type identification (e.g., QoS client) in a Client-Open (OPEN) message (Figure 1-a). If the PDP does not support the announced client type, a Client-Close (CC) message is sent back. Otherwise, the PDP replies with a Client-Accept (CAT) message. If PEP and PDP hold old information describing the internal state of each other, the PEP issues a Request (REQ) message informing its capabilities and installed policies. The PDP, on its turn, determines which policy actions are required in order to lead the PEP’s PIB to a consistent state. The PDP then replies with a Decision (DEC) message that informs which PIB data must be removed (if any) and which other must be updated and/or created. Finally, the PEP notifies the PDP about the success or failure in installing the new policies with a Report (RPT) message. Figure 1-a shows the common message exchange between PEPs and PDPs when PEPs boot or recover from a TCP connection loss in a COPS-PR managed network.
While in an active policy session, further PDP and PEP events may require the update of policy information. If PEP internals change (e.g., OS updated, configuration updated, board added/removed), a new REQ message informing the new device state is issued (Figure 1-b). The PDP then replies with policy actions related to the new PEP state. In another situation more frequent than the previous ones (Figure 1-c), at the PDP side, if policy information changes (e.g., new policies are to be deployed, old policies to be removed, current policies to be modified) a new (unsolicited) DEC message is sent from the PDP to all PEPs that are related to the policy whose information has changed. Again, each DEC message that is issued due to either a REQ message or a policy update in the PDP must be properly acknowledged by each PEP with a RPT message. This last scenario is usually the most critical one because it involves updating a (maybe large) group of PEPs at the same time, which impacts in the bandwidth consumption and provisioning response time. PEP PIB
PDP
Server Client
syn syn,ack ack
PEP
PDP
OPEN CAT
PIB
REQ
REQ DEC
DEC
RPT
RPT
(a) Device boot
(b) Device status updated PEP1
PDP
PIB
PEP2
PEPn
PIB
PIB
DEC
RPT
(c) Policy Information updated at the PDP Fig. 1.
PDP/PEP interaction using COPS-PR
Although different encodings are possible, COPS-PR messages are usually binary-encoded following the Basic Encoding Rules (BER) [15]. PIB classes and instances are identified by an OID (object identification) and a user-friendly OID name. PIB modules are described in documents ruled by the Structure of Policy Provisioning Information (SPPI) [16]. These features are important because they contrast with the information encoding and specification found in NETCONF and SOAP. B. NETCONF Although NETCONF is a protocol not yet standardized – the 9th version of the protocol draft [12] has been released in October 2005 –, it seems that the NETCONF main functionalities have reached a mature state. NETCONF aims at defining a common and flexible way to configure heterogeneous network devices. A NETCONF-enabled device offers an Application Programming Interface (API) through
Proceedings of the Seventh IEEE International Workshop on Policies for Distributed Systems and Networks (POLICY'06) 0-7695-2598-9/06 $20.00 © 2006 IEEE
where NETCONF managers retrieve, edit, copy, and remove the device’s configuration. NETCONF is based on a Remote Procedure Call (RPC) paradigm and follows the traditional manager-agent model. Different than COPS-PR, however, managed devices implement a NETCONF server that waits for managers (i.e., clients) calls. Although a server cannot call a client’s operation, an IETF Internet draft [17] defines a publish-subscribe model of NETCONF asynchronous messages where servers (devices) can notify clients (managers) about events occurred inside managed devices. Prior to any configuration, a management session must be opened between a manager and the managed device. As in COPS-PR, while in the session establishment phase, the target device advertises its capabilities informing which protocol operations and extensions it supports. Although the NETCONF base protocol defines a limited set of operations, additional operations can be implemented and advertised in the session establishment. The following list presents the operations defined in the base protocol: • • • • • • • • • •
initiates a configuration session; retrieves configuration and status information; retrieves only configuration information; modifies the current configuration; copies a configuration; removes a configuration; allows exclusive access to the configuration data; releases a lock previously acquired; closes the current session gracefully; stops any ongoing operation and closes the session.
NETCONF communications are handled in a protocol architecture composed of four layers (Figure 2). From bottom to top, the application protocol layer provides connectionoriented, reliable, and secure communication services based on application protocols such as SSH, BEEP, and SOAP (as in COPS-PR, NETCONF connections are persistent between protocol operations). The RPC layer implements a simple request-reply mechanism using XML encoded messages layered over application layer protocols. On top of the RPC layer, the operations layer encodes, also using XML, NETCONF operations like those listed before. Finally, the data exchanged in NETCONF operations are transmitted in the content layer. 4
Content (e.g., DiffServ-related configuration data)
3
Operations (e.g., , )
2
Remote Procedure Call (RPC)
1
Application protocol (e.g., BEEP, SOAP, SSH)
Fig. 2.
NETCONF layers
Because RPC and operation layers’ data are encoded following a NETCONF XML schema, servers and clients can easily validate the messages exchanged. Content layer’s data
may not be encoded in XML and is quite dependent on the managed device implementation. In fact, the protocol specification neither defines how content layer’s data is encoded nor informs what data can be manipulated by the protocol. This is expected to be addressed by complementary IETF work. Although a raw transport service would immediately suggest a NETCONF over TCP binding, the current NETCONF specification states that NETCONF over SSH is a mandatory mapping. Complementary Internet drafts, on turn, define other NETCONF encapsulations over BEEP and SOAP. It is particularly interesting to notice the NETCONF/SOAP binding, where SOAP provides the Web substrate for NETCONF message exchange. However, as it will be presented in the next subsection, SOAP can solely and independently from NETCONF implement its own network management support. Despite the several protocol architectures defined for NETCONF-based management, we will consider in the evaluations presented in this paper only the NETCONF/TCP binding because it requires less protocol encapsulations, resulting in less protocol overhead. C. SOAP and Web Services for Network Management The use of SOAP for network management has been attracting the attention of both academia and industry, mainly in the last four years. In academia, the investigations have been trying to understand the impact of using Web services for management considering, for example, bandwidth consumption [18], response time [19], and SNMP integration [20]. In industry, two main consortiums have been defining standards for Web services-based management. OASIS (Organization for the Advancement of Structured Information Standards) [10], for example, explores not only Web services for management, but the management of Web services. A second group, formed by AMD, BMC, CA, Dell, Fujitsu, Intel, Microsoft, NEC, Novell, Sun, Symantec, and WBEM Solutions, has released a new specification named WS-Management [11] that defines how SOAP messages must be encoded when they are used for service management. Web services can be seen as independent software components available on the Web and accessed by networked applications or by other Web services. Web services communication is possible thanks to SOAP, an XML-based protocol that also employs an RPC paradigm. Similarly to COPS-PR and NETCONF, SOAP also follows the client-server communication model where a server exposes Web services operations to remote clients. SOAP messages, as in NETCONF, are also layered on top of application protocols such as HTTP, SMTP, and FTP. Different than NETCONF, however, SOAP operations and message content are both clearly defined (the specification of NETCONF message content, as seen before, is left to complementary work), thus allowing faster development and deployment of Web services-based management solutions. Although SOAP content data may use different encodings (e.g., base64), XML is far more frequent than any other option. Since SOAP is quite general and flexible, alternative communication models other than RPC may also be supported,
Proceedings of the Seventh IEEE International Workshop on Policies for Distributed Systems and Networks (POLICY'06) 0-7695-2598-9/06 $20.00 © 2006 IEEE
such as asynchronous, one-way notifications. Despite its flexibility, SOAP clients and servers are asymmetric entities in terms of Web services operations: only clients can call server operations. It is not possible for a server to call a client operation. If that is required, a Web service needs to be implemented at the client side, and clients and servers then swap their roles to call the new operations on the opposite direction. Considering this feature, a mapping from clientserver entities to manager-agent roles in Web service is neither direct nor obvious, and depends on specific management scenarios. For example, one can implement a Web service at the manager side to have something more similar to the PDPs from the COPS-PR approach, while someone else could prefer to have Web services at the device side to have an approach closer to the NETCONF model. As we are going to justify in the next sections, in our evaluation experiments we have implemented Web services at both manager and device sides. In order to have COPS-PR, NETCONF, and SOAP in perspective, Table I summarizes some of the main aspects of these protocols presented in this section. TABLE I COPS-PR, NETCONF, AND SOAP
Target usage Lower layer protocols Operation call directions Notifications Manager-agent roles Usual encoding Content definition
CHARACTERISTICS
COPS-PR NETCONF Policy Configuration provisioning management TCP SSH, BEEP, SOAP Client Server Client Server Server Client Unsolicited DEC, Specified in an RPT Internet draft Server-client Client-server BER XML Defined in PIBs Not specified
SOAP Internet inter-process communication HTTP, SMTP, FTP Client Server WS-Notification specification Design dependent XML User defined
III. M APPING COPS-PR TO NETCONF AND SOAP Before replacing COPS-PR with NETCONF or SOAP, we need first to define how these protocols would operate in a policy provisioning environment. In this section we introduce a mapping from COPS-PR operations and data to NETCONF and SOAP. A. COPS-PR to NETCONF One of the most significant differences between the way COPS-PR and NETCONF operate is related to the clientserver model. While in COPS-PR the protocol clients are found at the PEP (managed device) side, NETCONF clients are implemented at the PDP (manager) side. This indirectly defines which entity (manager or device) must take care of underlying protocol disconnections. From the manager perspective, concerning this aspect, COPS-PR is more attractive because managed devices (and not the manager) are responsible for recovering from connection losses. In NETCONF, however, the manager needs to keep track of all connections and reestablish those that eventually get lost. Concerning another aspect, the current version of the Internet draft that defines NETCONF notifications [17] states
that a manager needs to subscribe with the managed device informing which events the manager is interested in. Once an event of interest occurs, a notification is asynchronously sent from the managed device to the interested manager. In COPS-PR, however, notifications (e.g., unsolicited DEC, RPT) are sent to the remote entity without requiring any previous subscription. We begin our COPS-PR to NETCONF mapping defining that all NETCONF policy provisioning notifications are sent to the interested party only upon proper subscription, as defined in NETCONF. Giving this initial definition, Figure 3 presents the COPS-PR to NETCONF mapping considering the PDP/PEP interactions. For a clearer comparison, we assume in Figure 3 and subsequent explanatory text that COPS-PR and NETCONF are layered over TCP. However, as pointed before, NETCONF minimally requires a secure, SSH-based transport service, which we assume to be transparently provided, and thus not depicted in Figure 3. PEP PIB
PDP syn syn,ack ack OPEN
PEP PIB
PDP syn syn,ack ack
CAT
REQ
DEC
RPT
(a) COPS-PR
Fig. 3.
TCP connection establishment
Provisioning session establishment Policy information request Policy information transfer
(b) NETCONF
COPS-PR x NETCONF messages
After the TCP connection is established, a provisioning session must be established too. During session establishment, the PEP informs to the PDP about the type of policy (e.g., QoS, security) the PEP supports. If such a type is not supported by the PDP, the session and underlying TCP connection are closed. COPS-PR, as seen before, uses OPEN and CAT messages for session establishment. NETCONF, on its turn, defines that messages (triggered in parallel) are used by manager and device to inform each other’s capabilities. A COPS-PR PDP denies a session by returning a CC message that may inform the address of another PDP that supports the PEP type. In our NETCONF mapping, if the PDP does not support the PEP type, the underlaying TCP connection is immediately closed by the PDP, that may additionally contact another PDP that supports the advertised PEP type and delegates to that PDP the responsibility of provisioning policies to the unsupported PEP. Despite the session issues, in the remaining of our analysis we will consider that the provisioning session establishment will always succeed. In order to receive provisioning-related notifications from a PEP, the PDP needs to subscribe itself together with such a PEP. Thus, the message is sent from the PDP to the PEP, which replies informing in the
Proceedings of the Seventh IEEE International Workshop on Policies for Distributed Systems and Networks (POLICY'06) 0-7695-2598-9/06 $20.00 © 2006 IEEE
message the identification of the just created subscription entry at the PEP side. After session establishment, or if the PEP internals change, a REQ message is sent to the PDP by the COPS-PR PEP, or an notification by the NETCONF device. The contents of these messages report the PEP capabilities and currently installed policies. In return, or if the PDP policy information changes, the COPS-PR PDP sends a DEC message, or it requests a operation in the case of the NETCONF PDP. The contents of such messages now indicate which policy information needs to be removed and which other must be installed and/or updated at the PEP’s PIB. If the PIB update succeeds, the COPS-PR PEP replies with a RPT message, while NETCONF returns an reply. If the PIB update fails, however, the COPS-PR RPT includes a failure flag, while NETCONF returns an message. Here again, we will consider that PIB updates will always succeed. As already presented, NETCONF content layer does not currently define how NETCONF management data must be coded. However, it is reasonable to believe that XML documents would be one of the preferred options. In our COPSPR to NETCONF mapping we translate PIB information (defined in SPPI files) into XML documents. This process is accomplished through the smidump tool [21]. smidump is part of the libsmi package developed at the Technical University of Braunschweig and is able to generate XML versions of SNMP MIBs and COPS PIBs. We then use the resulting XML files and, through XML parsers, include values associated with the policy information to be manipulated at both PDP and PEP sides. B. COPS-PR to SOAP SOAP notifications [22] are Web services operations whose response contains no resulting value. Since they are just a different type of operation, notifications can only be issued by SOAP clients directed to SOAP servers. Thus, it is not possible to have clients calling server operations in one direction and being notified in the opposite one, because clients cannot implement and expose operations to work as notification receivers. As observed in the COPS-PR to NETCONF mapping, we need a PDP that calls some PEP operations (e.g., DEC/) but also a PDP able to receive PEP notifications (e.g., REQ/). Since these interactions (calling operations and receiving notifications) are not possible to be implemented in a single SOAP client-server pair because it allows communications only in one direction, we need an additional client-server pair to support communications in the opposite direction. In the COPS-PR to SOAP mapping we thus define that a SOAP PDP implements a SOAP sever and a SOAP client that run at the same time. The PDP’s SOAP server is able to receive SOAP notifications, while the PDP’s SOAP client is used to issue remote operations at the PEP side. Complementary, a SOAP PEP also implements a SOAP server and a SOAP client. In this case, the PEP’s SOAP client is used when the PEP
needs to notify the remote PDP, while the PEP’s SOAP server exposes the PEP operations available to that PDP. Although SOAP notifications also use a publisher-subscribe model, the interested receiver is not obligated to register together with the event source if such a source already knows the receiver address. In this COPS-PR to SOAP mapping, we assume that PEPs do not require known PDPs to register together with PEPs to receive notifications: PEPs send notifications to PDPs regardless PDPs subscriptions. Having a pair of client-server connections makes the connection management of the underlaying protocol more complex. In order to treat both connections as a single one, we define that if one of the connections is lost, the other one must be immediately aborted. Thus, if the SOAP client or server at one end (PEP or PDP) detects a connection loss, the other client or server at the same side must be internally contacted and requested to shut its connection down. Figure 4 presents the COPS-PR to SOAP mapping. Here again, for a clearer comparison, we assume in this figure that SOAP is layered directly over TCP, although the SOAP/HTTP binding is far more frequent and adequate for communications over the Internet. PEP
PDP
PDP
PEP PIB
PIB syn syn,ack ack syn syn,ack ack
syn syn,ack ack OPEN
Open()
CAT
TCP connections establishment
Provisioning session establishment
REQ
Request ()
Policy information request
DEC
Decision ()
Policy information transfer
RPT
(a) COPS-PR
Fig. 4.
(b) SOAP
COPS-PR x SOAP messages
Because PEPs that are based on SOAP can initiate the provisioning communication, PDPs are free of managing PEPs reconnections, as in COPS-PR. Just after the two PEP/PDP connections are established, the PEP calls the PDP’s Open() operation informing its type. The return of the execution of Open() will indicate whether the provisioning session has been accepted or not: if the PEP type is not supported by the PDP, the result denies the session and informs the address of an alternative PDP (if any) that may support the PEP type. If the PEP internal status changes, new policy information may be required. Once the status changes, the PEP’s SOAP client notifies the PDP’s SOAP server calling the Request() one-way notification operation. When notified, the PDP’s SOAP server internally contacts the PDP’s SOAP client. If new policy information is available for the notifying PEP, or if the policy at the PDP is changed and requires the update of the PEP’s PIB, the PDP’s SOAP client calls the
Proceedings of the Seventh IEEE International Workshop on Policies for Distributed Systems and Networks (POLICY'06) 0-7695-2598-9/06 $20.00 © 2006 IEEE
Decision() operation exposed by the PEP’s SOAP server. The Decision() execution informs whether the new policy information has been successfully deployed at the PEP. SOAP is quite flexible in terms of data encoding. Although a developer may choose to use its own data encoding, usually the encoding provided by the SOAP RPC mechanism is sufficient for most distributed applications. SOAP encoding facilities allows to encode from simple types as integers and string to more complex ones as arrays and objects. In our COPSPR to SOAP map we define that policy information originally defined in PIBs need to be translated to objects of a objectoriented programming language (e.g., C++), and then transferred between PDPs and PEPs using the encoding support provided by SOAP. Since PIBs define policy information in a object-oriented fashion, the translation from PIBs information to SOAP objects is quite straightforward. Having defined the protocol mappings, we now present a management environment and associated QoS policies used to evaluate NETCONF and SOAP against COPS-PR.
In our tests we assume that the PEP is able to act as a edge or a core DiffServ router. In a managed network, edge routers connect end-user hosts from network segments (using edge interfaces) to the network backbone (using core interfaces). Core routers, in turn, are connected to edge routers and to one another to form the network backbone. As an example of a scenario where edge and core DiffServ routers are found, figure 5 depicts a managed network composed of 16 LANs (where end-user hosts are located), 8 edge routers, and 4 core routers.
LAN Edge router Core router
IV. T ESTING E NVIRONMENT AND P OLICIES Our testing environment is composed of two Linux PCs acting as PDP and PEP, respectively, and a 3Com Superstack 3 3300XM switch that connects the PDP and PEP PCs to each other via 100 Mbps network connections. These two PCs run the three pairs of PDP/PEP, each pair corresponding to each protocol being tested, i.e., COPS-PR, NETCONF, and SOAP. Table II summarizes the hardware and software configuration for our testing PCs. TABLE II C ONFIGURATION OF PDP AND PEP PC S PDP/PEP configuration CPU Pentium 4 (2.4Ghz) RAM memory 256 MB Operating system Slackware 10.1 (2.4.28) COPS support Intel COPS SDK v 3.1 (build 26) NETCONF support Madynes Yenca v 1.0 SOAP support gSOAP v 2.7.5
The running processes playing the roles of PDP and PEP have been all implemented in C/C++. The COPS-PR support has been provided by the Intel COPS SDK [23]. Although Intel has discontinued the development of its COPS SDK and other COPS libraries are available, we have yet used the Intel’s one because it originally (and more user-friendly) support the DiffServ PIB. The NETCONF support is based on the YENCA package (version 1.0) developed by the INRIALORIA Madynes research group [24]. Although a more up to date version of YENCA is provided by Madynes, we have used version 1.0 because it has been also coded in C/C++, while the current available version is coded in Python. In addition, we have slightly extended version 1.0 to include the notification support, which was not available in the original code. Finally, the SOAP support has been provided using the gSOAP library [25], which is a popular SOAP suite widely used in industry and by developers from the free software community.
Fig. 5.
DiffServ-enabled network with edge and core routers
The following subsections describe the policies we have used in our evaluations. A. Testing Policies for Edge Interfaces of DiffServ Routers DiffServ defines three classes of services for traffic forwarding: expedited forwarding (EF), assured forwarding (AF), and best effort (BE). AF is subdivided in four additional classes (AF1, AF2, AF3, AF4), corresponding to different priority levels. Packets are mapped to the aggregated classes according to the edge policies, characterized by a Committed Information Rate (CIR), a Committed Burst Size (CBS), a Peak Information Rate (PIR), and a Peak Burst Size (PBS). Our testing policies for edge interfaces of edge routers define how the traffic of some critical applications (VoIP, video, HTTP, TELNET, and FTP) is grouped in DiffServ aggregates in a hypothetical managed network, as follows: • • • • • •
P1: VoIP traffic is aggregated in the EF class, with a rate of 2M and burst size of 256K; P2: Video traffic is aggregated in the AF1 class, with CIR=10M, CBS=1M, PIR=2M, PBS=512K; P3: HTTP traffic is aggregated in the AF2 class, with CIR=5M, CBS=512K, PIR=1M, PBS=256K; P4: TELNET traffic is aggregated in the AF3 class, with CIR=2M, CBS=256K, PIR=512K, PBS=128K; P5: FTP traffic is aggregated in the AF4 class, with CIR=1M, CBS=256K, PIR=256K, PBS=64K; P6: All remaining traffic is classified as best effort (BE).
The set of the above edge policies is mapped to DiffServ PIB objects according to Figure 6, which also present additional details ommited in the above policy descriptions for the sake of simplicity.
Proceedings of the Seventh IEEE International Workshop on Policies for Distributed Systems and Networks (POLICY'06) 0-7695-2598-9/06 $20.00 © 2006 IEEE
Figure 7 shows how the previous policies are mapped to the DiffServ PIB in routers with core interfaces, and additionally shows complementary information for the core policies.
. . .
Fig. 6.
Policies for edge interfaces of DiffServ routers
B. Testing Policies for Core Interfaces of DiffServ Routers Our policies for core interfaces of DiffServ routers additionally considers the priority of discard associated to the AF classes. Each AF class may be associated to one of three discard priorities, defining subclasses (e.g., AF11, AF12, and AF13). In addition, in these core policies we also define the allocation of bandwidth for some DiffServ aggregates. Given that q(x) return the number of bytes in the queue of the DiffServ class x, we have the following core policies. • P1: EF traffic has priority over any other traffic; • P2: AF1 traffic has 30% of bandwidth allocated; – If q(AF1)>50, AF13 packets start to be discarded; – If q(AF1)>80, AF12 packets start to be discarded; – If q(AF1)>100, AF11 packets start to be discarded; • P3: AF2 traffic has 15% of bandwidth allocated; – If q(AF2)>50, AF23 packets start to be discarded; – If q(AF2)>80, AF22 packets start to be discarded; – If q(AF2)>100, AF21 packets start to be discarded; • P4: AF3 traffic has 10% of bandwidth allocated; – If q(AF3)>50, AF33 packets start to be discarded; – If q(AF3)>80, AF32 packets start to be discarded; – If q(AF3)>100, AF31 packets start to be discarded; • P5: AF4 traffic has 10% of bandwidth allocated; – If q(AF4)>50, AF43 packets start to be discarded; – If q(AF4)>80, AF42 packets start to be discarded; – If q(AF4)>100, AF41 packets start to be discarded; • P6: BE traffic receives the remaining bandwidth available.
. . .
Fig. 7.
Policy for core interface of DiffServ routers
V. E VALUATION We evaluate COPS-PR, NETCONF, and SOAP observing two parameters: network usage and protocol delay. We assume that each PEP involved in the evaluation already has the previous presented policies installed. Then, we modify the PEP’s PIBs in three progressive configurations of different complexities in order to check how the protocols behave in each of such progressive configurations. Since we have two policies (for edge and core routers), the final number of modifications is six, three for each policy. The progressive policy modifications update the PEP’s PIBs as follows. The numbers inside brackets inform how many policy objects have been transferred in each modification.
Proceedings of the Seventh IEEE International Workshop on Policies for Distributed Systems and Networks (POLICY'06) 0-7695-2598-9/06 $20.00 © 2006 IEEE
• • •
Modification #1 (simple) - Already defined traffics have their policing process redefined [13]; Modification #2 (intermediate) - New traffics are defined and aggregated with already defined traffic [102]; Modification #3 (complex) - All policy objects installed are modified [147].
Core policies modifications Modification #1 (simple) - The bandwidth allocated for each aggregated is changed [4]; • Modification #2 (intermediate) - The traffic discard priorities and thresholds are modified [28]; • Modification #3 (complex) - All policy objects installed are modified [85]. The following subsections present the network usage and delay evaluations considering the previously presented policies and the six progressive modifications. •
SOAP itself), the network usage of NETCONF and SOAP may vary according to the protocol architecture employed: Figure 8 presents in fact the most “economic” protocol architectures for NETCONF and SOAP. 25000 Network usage (bytes)
Edge policies modifications
20000 15000 10000 5000 0 0
20
40
60
80
100
120
140
160
Policy objects COPS-PR
NETCONF Comp. SOAP
Comp. NETCONF
SOAP
A. Network Usage Network usage shows how many bytes went to the wire in a policy provisioning action. For each pair of PDP and PEP we evaluate the network usage when the PDP contacts and update the PEP’s PIB due to a policy information update at the PDP side. Although other operations are important (e.g., network usage for provisioning session establishment), the modification of policies in the PDP triggers the update of several PEPs associated to the modified policies, and this generates the large amount of messages associated to a single PDP update. We thus focus in checking the amount of network bytes consumed by PDP and PEP for: (a) COPS-PR DEC/RPT pair of messages, (b) NETCONF / pair of messages, and (c) SOAP Dec() operation call and associated reply. The network usage is given in terms of the number of PIB objects manipulated at the PEP side: with more objects more network bandwidth is consumed. As presented before, the number of objects carried in each of the six progressive policy modifications are (ordered by the number of objects): 4, 13, 28, 85, 102, and 147. Given these numbers of objects, the network usage presented by COPS-PR, NETCONF, SOAP, and compressed NETCONF and SOAP for a PEP’s PIB update is depicted in Figure 8. As expected, COPS-PR consumes less network bandwidth than uncompressed NETCONF and SOAP because its operations are binary-encoded, thus resulting in messages shorter than the XML-based messages from NETCONF and SOAP. Observing NETCONF and SOAP, it is possible to check that NETCONF is more economic than SOAP. SOAP consumes more bytes because its XML messages requires a transport protocols (from the Web services terminology) that may not be required by NETCONF. In our tests, SOAP messages have been layered over HTTP, while NETCONF messages have been transported directly by TCP. Since the NETCONF current drafts indicate that other protocol bindings are possible (including the one where NETCONF messages are transported by
Fig. 8.
Network usage
Another issue that may vary the network usage is the type of objects being transferred. Although numeric objects are more likely to happen, other types are also possible such as strings and PIB cross-references via OID objects. Giving these variety of factors, defining final expressions that compute the network usage for COPS-PR, NETCONF, and SOAP is a difficult task. Considering the evaluations executed, however, we estimate the network usage (N U ) of COPS-PR, NETCONF, and SOAP in terms of the number of transferred objects (Objs) approximately as: N U cops-pr ≈ 48 · Objs + 144 N U netconf ≈ 137 · Objs + 310 N U soap ≈ 155 · Objs + 1161 It is important to notice that the greater the number of transferred objects, the greater the difference among COPSPR, NETCONF, and SOAP. Although such a difference may be irrelevant for message with few objects, it may also cause temporary bandwidth race when several objects are required to update the PIB of several PEPs. For example, to update 1000 PEPs transferring 4 objects, COPS-PR consumes around 3 Kbytes, NETCONF consumes around 7.5 Kbytes, and SOAP consumes around 17 Kbytes. To update the same 1000 PEPs, but now transferring 147 objects, COPS-PR consumes around 72.5 Kbytes, NETCONF consumes around 203 Kbytes, and SOAP consumes 240 Kbytes. Fortunately, with the bandwidth available in the today’s networks, the network usage imposed by NETCONF and SOAP, even though greater than COPS-PR, is unlikely to evolve to critical network congestions. In addition, we have tested compressed traffic of NETCONF and SOAP, as also presented in Figure 8. In this case, the zlibbased compression process reduces the number of used bytes
Proceedings of the Seventh IEEE International Workshop on Policies for Distributed Systems and Networks (POLICY'06) 0-7695-2598-9/06 $20.00 © 2006 IEEE
of NETCONF and SOAP to levels even lower than the network usage associated to COPS-PR. Thus, in the unlikely event of restricted bandwidth, compressed NETCONF and SOAP messages may be employed to consume less bandwidth than COPS-PR. B. Protocol Processing Delay The protocol processing delay allows determining the overhead in handling the protocol messages. In this evaluation we are not interested in checking the time spent by PEPs to install policies because this may vary from PEP to PEP according to the underlaying device QoS architecture. Instead, we are interested in measuring solely the delay associated with the encoding, transferring, and decoding of the protocols messages. As in the case of network usage, this evaluation is focused in the policy update required when the PDP internals change, which requires PEP’s PIB to be manipulated using the protocols operations. Figure 9 shows the delay associated with each protocol, again in terms of the number of objects transferred between PDP and PEP.
Protocol delay (s)
0.014
than SOAP, less people have contributed to the YENCA implementation, then resulting in a less optimized code if compared with the gSOAP API. In essence, however, both NETCONF and SOAP with optimized implementations will eventually present similar performance, since both are based on XML. We have also checked the processing delay considering the protocol compression process for NETCONF and SOAP. As can be observed, the addition of compression slows down both NETCONF and SOAP, but they still perform better than COPS-PR. Thus, the compression processes reduces the bandwidth consumption (as observed in the previous subsection) without compromising the overall performance of the protocols. The general conclusion regarding protocol delays is that neither NETCONF nor SOAP presents delays that would indicate performance problems when employing such protocols for policy provisioning. In fact, the results show that NETCONF and SOAP are better than COPS-PR due to the fact that they employ XML messages instead of more expensive binaryencoded message.
0.012
VI. C ONCLUSIONS AND F UTURE W ORK
0.010
In this paper, we have proposed the use of NETCONF and SOAP as substitutes for COPS-PR. The main motivation for such substitution is that COPS-PR has been facing a discontinuity trend, as observed even inside the IETF work, which, for example, has opened a new work group to develop NETCONF. The two most important difficulties in modeling NETCONF and SOAP for policy provisioning is related to the event messages support currently available in both protocols, and the way the client-server communication model is employed in NETCONF and SOAP. NETCONF barely supports notifications, having such support defined in a recent Internet draft. NETCONF notification model, however, is similar to the one presented by COPS-PR: a managed device is able to notify the associated manager using the same connection used by the manager to configure the network device. In the case of SOAP, the notifications support is more tricky because SOAP currently does not allow a single connection to be used as a means to call operations in one direction, and notify the endpoint in the opposite direction. To work around this problem, we modeled SOAP-based PDP and PEP as hybrid entities having, each one, a pair of Web services client and server. In terms of modeling, we can conclude that neither NETCONF nor SOAP fits well with the original COPS-PR communication model. However, both protocols can be used for policy provisioning if their messages are used to deal with those policy-related events detected and issued by PDPs and PEPs. In this paper we have proposed one specific modeling of NETCONF and SOAP for policy provisioning, but other modelings using different protocol adaptations may be proposed as well. The evaluations considering the network usage and protocol delay have shown that NETCONF and SOAP may substitute
0.008 0.006 0.004 0.002 0 0
20
40
60
80
100
120
140
160
Policy objects COPS-PR
NETCONF
Comp. NETCONF
Comp. SOAP Fig. 9.
SOAP
Protocol delay
Different than the results obtained from the evaluation of network usage, COPS-PR performs worst than NETCONF and SOAP when the protocol delay is observed. The main reason for such result is that COPS-PR is a binary protocol whose messages are encoded following the Basic Encoding Rules (BER), as already mentioned. Decoding a binary protocol is more expensive than decoding text-oriented protocols such as NETCONF and SOAP because bit operations are required to retrieve all information transferred in protocol message. Text encoded protocols, however, are less expensive because no complex bit-level operations are required, and thus a faster protocol processing is achieved. The difference observed between NETCONF and SOAP is also sensible. The gSOAP package used for the SOAP implementation is a SOAP API largely employed and maintained with the frequent help of the free software community. This grant to gSOAP a more robust and optimized implementation than YENCA, used to implement the NETCONF support. Since NETCONF is a more specific, less employed protocol
Proceedings of the Seventh IEEE International Workshop on Policies for Distributed Systems and Networks (POLICY'06) 0-7695-2598-9/06 $20.00 © 2006 IEEE
COPS-PR with possible advantages. Although the XMLencoded messages used by NETCONF and SOAP consume more bandwidth than COPS-PR, the compressed versions of the same XML messages end up consuming less bandwidth. If we further consider the protocol delay, COPS-PR performs worst than NETCONF and SOAP because the processing required to encode and decode its binary messages is more expensive than the processing required to encode and decode XML messages. Even when the compression process is introduced, NETCONF and SOAP performs better because treating the textual XML-encoded messages is less expensive than COPS-PR. Thus, in general, the proposed modeling and evaluations results allow us to conclude that both NETCONF and SOAP are real feasible replacements for COPS-PR. Since NETCONF and SOAP more easily enable policyrelated communications between entities located in different administrative domains, security issues may arise. Both protocols proposed security solutions to be used in their employment. These solution obviously impact in the protocols performance. One future work to be carried out is related to the evaluation of the performance of NETCONF and COPS when security support is introduced in policy provisioning. In addition, a scalability evaluation is also required to determine, for example, how scalable is a PDP when using different policy provisioning protocols, and how this same scalability is affected when the aforementioned security support is introduced. ACKNOWLEDGMENT The authors of this paper would like to acknowledge the CNPq (Brazilian National Research Council) for its support. R EFERENCES [1] J. Strassner, Policy-Based Network Management: Solutions for the Next Generation. Morgan Kaufmann, Aug. 2003, ISBN: 1-55860-859-1. [2] D. Durham, J. Boyle, R. Cohen, S. Herzog, R. Rajan, and A. Sastry, “The COPS (Common Open Policy Service) Protocol,” RFC 2748 (Proposed Standard), IETF, Jan. 2000. [3] R. Sahita, S. Hahn, K. Chan, and K. McCloghrie, “Framework Policy Information Base,” RFC 3318 (Informational), IETF, Mar. 2003. [4] K. Chan, J. Seligson, D. Durham, S. Gai, K. McCloghrie, S. Herzog, F. Reichmeyer, R. Yavatkar, and A. Smith, “COPS Usage for Policy Provisioning (COPS-PR),” RFC 3084 (Proposed Standard), IETF, Mar. 2001. [5] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, and W. Weiss, “An Architecture for Differentiated Service,” RFC 2475 (Informational), IETF, Dec. 1998. [6] R. Braden, D. Clark, and S. Shenker, “Integrated Services in the Internet Architecture: an Overview,” RFC 1633 (Informational), IETF, Jun. 1994.
[7] R. Braden, L. Zhang, S. Berson, S. Herzog, and S. Jamin, “Resource ReSerVation Protocol (RSVP) – Version 1 Functional Specification,” RFC 2205 (Proposed Standard), IETF, Sept. 1997. [8] W3C, “SOAP Version 1.2,” 2005, . [9] 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, no. 2, pp. 86–93, 2002. [10] “Organization for the Advancement of Structured Information Standards (OASIS),” 2005, . [11] A. Arora, J. Cohen, J. Davis, M. Dutch, E. Golovinsky, Y. H. J. He, D. Hines, R. Inohara, C. Kmpfe, M. Milenkovic, P. Montgomery, A. Nosov, A. Padlia, R. Reich, L. Russon, J. Schlimmer, E. Suen, V. Tewari, and K. Wilson, “Web Services for Management,” Jun. 2005, . [12] R. Enns, “NETCONF Configuration Protocol,” (Internet-Draft), IETF, Oct. 2005, (work in progress). [13] D. Harrington, R. Presuhn, and B. Wijnen, “An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks,” RFC 3411 (Standard), IETF, Dec. 2002. [14] W3C, “Extensible Markup Language (XML),” 2005, . [15] I. O. for Standardization, Information processing systems - Open Systems Interconnection, Specification of Basic Encoding Rules for Abstract Notation One (ASN.1), December 1987, international Standard 8825. [16] K. McCloghrie, M. Fine, J. Seligson, K. Chan, S. Hahn, R. Sahita, A. Smith, and F. Reichmeyer, “Structure of Policy Provisioning Information (SPPI),” RFC 3159 (Proposed Standard), IETF, Aug. 2001. [17] S. Chisholm, K. Curran, and H. Trevino, “Netconf Event Messages,” (Internet-Draft), IETF, Oct. 2005, (work in progress). [18] T. Fioreze, L. Z. Granville, M. J. B. Almeida, and L. M. R. Tarouco, “Comparing Web Services with SNMP in a Management by Delegation Environment,” in IM 2005 - 9th IFIP/IEEE International Symposium on Integrated Network Management, Nice, France, May 2005. [19] A. Pras, T. Drevers, R. v.d. Meent, and D. Quartel, “Comparing the Performance of SNMP and Web Services-Based Management,” IEEE eTNSM - eTransactions on Network and Service Management, vol. 1, no. 2, p. 11, Dec. 2004. [20] T. Klie and F. Strauss, “Integrating SNMP agents with XML-based management systems,” IEEE Communications Magazine, vol. 42, no. 7, pp. 76–83, July 2004. [21] Frank Strauss and Juergen Schoenwaelder, “libsmi - a library to access smi mib information,” Nov. 2005, http://www.ibr.cs.tubs.de/projects/libsmi/. [22] G. Steve, D. Hull, and B. Murray, Web Services Base Notification (WS-BaseNotification), 1st ed., IBM, Tibco, HewlettPackard Company, July 2005, (work in progress). [Online]. Available: ”http://www.oasis-open.org/committees/download.php/13488/wsnws-base notification-1.3-spec-pr-01.pdf” [23] “Intel COPS Client Software Development Kit,” previously available at http://www.intel.com/labs/manage/cops/. [24] B. Zores, R. State, and O. Festor, “YENCA release 1.0,” Nov. 2004, available at http://sourceforge.net/projects/yenca/. [25] “gSOAP Web Services toolkit,” 2005, available at http://sourceforge.net/projects/gsoap2/.
Proceedings of the Seventh IEEE International Workshop on Policies for Distributed Systems and Networks (POLICY'06) 0-7695-2598-9/06 $20.00 © 2006 IEEE
