Measurements of the performance of the RSVP protocol - CiteSeerX

Measurements of the performance of the RSVP protocol Franco Tommasi1 , Simone Molendini2 , Sandro Zacchino1 1

2

Dept. of Innovation Engineering - University of Lecce {franco.tommasi,sandro.zacchino}@unile.it ISUFI, Innovative Materials and Technologies School - University of Lecce {simone.molendini}@unile.it

Abstract. RSVP (Resource ReSerVation Protocol) is an Internet protocol designed to allow applications reserving network resources. RSVP is used i n the QoS context but also as a general purpose signaling control in the MPLS and Traffic Engineering areas. The acceptance of the protocol has been slowed mainly by concerns about its overhead and scalability. This paper describes then the most meaningful techniques standardized by the Internet Engineering Task Force (IETF) to overcome this problem, that we implemented extending a widespread daemon, and it analyses the results of experimental measurements, comparing them with those of the original RSVP.

1 Introduction RSVP (Resource ReSerVation Protocol) is an IETF (Internet Engineering Task Force) proposed standard signaling protocol [7]. It allows unicast or multicast sending and receiving applications to transmit their QoS needs to Internet nodes in the path. The RSVP has been designed in a manner that allows to manage QoS information as opaque objects defined by the IntServ architecture’s services. Beyond its original use, the well-studied RSVP has been then considered as a signaling protocol in the MPLS [2] architecture as a label distribution protocol. The general acceptance of the protocol has been slowed mainly by concerns about its scalability. The load generated by the management of thousands of RSVP sessions has been judged too heavy for a single core router by many. The requirements posed by the current version of the protocol in terms of memory, processing and bandwidth are essentially proportional to the number of sessions maintained by the router. Nor it is to be expected that a future improvement of such resources could be a solution to the problem as it is conceivable that an improved hardware would lead to more applications requiring QoS services. The IETF RSVP Working Group believed that it was necessary to introduce some extensions to the protocol to allow its utilization with a large number of flows. A lot of work inside the IETF was devoted to solve this problem and the “RSVP Refresh Overhead Reduction Extensions” [6] published as RFC2961 collected this work. This RFC exploits the inherent flexibility of the protocol and extends it in order to reduce

the dependency of the total overhead of the RSVP signaling on the number of RSVP sessions, though preserving the original flows isolation. Such techniques may be also used in the MPLS/Traffic Engineering context as described, for example, in [1-5]. It is then a crucial aspect assessing the RSVP suitability as a signaling protocol for a large number of unicast flows. This paper discusses some of the most meaningful techniques of RFC2961 we contributed standardizing and developed and the measurements of their influence in a real network. Such results give an original insight on the behavior of RSVP. The implementation is briefly explained together with a careful analysis of the results of a measurement, comparing the performances of those extensions with the original RSVP: what we produced is, as far as we know, the first analysis of those extensions. Section 2 introduces the RSVP Overhead Reduction Extensions, Section 3 discusses the measurements of the mechanisms adopted in this paper and final conclusions are then provided.

2 Description of the RSVP Overhead Reduction Extensions We describe in this section the most meaningful extensions in [6], henceforth RFC2961, designed to reduce the protocol’s overhead, comparing them with the original definition of the RSVP protocol, henceforth RFC2205. In RFC2961 flows are still dealt with separately: for each of them the standard RFC2205 operations are performed (setup/refresh/teardown). The way messages are sent and processed is changed instead. 2.1 Bundling of Messages The Bundle message defined in RFC2961 packs a number of RSVP messages sent to the same RSVP neighbor within a single larger RSVP message. To this purpose a new RSVP Bundle message is defined: this message has its own header and a body which is made up with a sequence of RSVP messages (each with its own header and body). Bundling is performed on a per-hop base. The receiving router unpacks the submessages and processes them. The advantages brought by the adoption of such mechanism are given by the reduced usage of bandwidth, as a number of IP and datalink headers are replaced by a single one, and by the fewer network interruptions for the router’s OS to deal with. 2.2 Refresh by a Message ID and Summary Refresh The “Summary Refresh” extension is based on the creation and the transmission of IDs associated with refresh messages. The periodical refresh of RSVP states is then simply performed by sending the IDs of the original messages thus dramatically reducing the amount of refresh traffic. Path and Resv trigger messages are sent with a new

MESSAGE_ID object. This object has a 32-bits long ‘Identificator’ field that identifies the message. The value of the Identificator field has a scope that is local to a pair of nodes, and is equal to the last assigned ID increased by one (until it wraps around to zero). Once a node has created a new state by sending a trigger message together with its ID, it can subsequently use the MESSAGE_ID object to refresh this state. Multiple states can be refreshed with a new Summary Refresh message made up by a sequence of IDs. The usage of IDs for refresh purposes greatly reduces the amount of the bandwidth wasted for signaling purposes and the use of CPU to maintain the soft state of the RSVP sessions.

3 Measurement of the RSVP extensions We have implemented the said extensions in an existing RSVP daemon and compared the performance with that of the original version to estimate the advantages. 3.1 Description of the implementation of RFC2961 We are currently aware of two, widespread, freely available implementations of the RSVP daemon. The first one, the ISI distribution [10], has been written at the ISI using the C language and is the first implementation of the RSVP protocol. The second one, the KOM RSVP engine [9], has been developed at the Darmstadt University of Technology using the C++ language. The ISI distribution thoroughly implements all the functionality described in the RFC2205 while the KOM one lacks some features (UDP encapsulation and IPv6 support) that would be necessary for a full implementation. Both are available under a number of Unix OSs like Solaris, FreeBSD and Linux. We chose to implement the RSVP2961 into the ISI distribution because it is the most complete release and it is the reference implementation. Anyway this is not the best implementation because it has been showed [8] that the KOM RSVP is better as it sustains a higher maximum number of RSVP sessions and poses a lower CPU load. In [8] a survey of other works related to RSVP performance analysis may be also found. The RSVP ISI distribution under FreeBSD maintains a maximum of 5000 sessions while an optimized version of the KOM RSVP is able to maintain up to 50000 sessions. 3.2 Experiment test-bed The performance experiments were carried out onto two standard PC-based workstations, running RedHat 7.0 Linux OS (kernel 2.2.16), which were configured to serve as routers and equipped as follows: Pentium III 700 Mhz PCs, 512Kb second-level cache, 128 Mbyte RAM, 100Mbps Ethernet links, 3Com 3c905C-TX interface cards.

Monitoring was made with an iMac DV equipped with EtherPeek 4 (network monitoring tool). Each test was run with a fixed number of sessions. To create a number of RSVP sessions with a single command a modified version of "rtap", a small utility included in the ISI distribution to allow sending commands to RSVP API was used. All the sessions are supposed to be long-term ones. We measured data over a 5 minutes large temporal window (the Refresh parameter is 30 seconds long as RFC2205 suggests.) In our topology one computer was considered to be the upstream router for all the sessions and the other one the downstream router. These two routers and the iMac were linked to a hub. As the IP packets are encapsulated into ARPA Ethernet frames the MTU is 1500 bytes. 3.3 Performance Three parameters are considered in our measurements: CPU load, throughput and signaling overhead. The CPU load is the CPU load of the rsvp daemon in the sending router. It is measured by periodically executing the “top” program that displays an ongoing sample of CPU utilization for each process in the system. The throughput represents the average number of bytes transmitted by the rsvp daemon and measured by an external computer connected by a hub. Throughput represents then the bandwidth waste for signaling purposes. Signaling represents the average number of packets transmitted by the rsvp daemon. At first, we tested the original RSVP daemon and then we tested the Bundle, Message ID and Summary Refresh extensions. Each test was run with a fixed number of sessions; for each test, we collected the CPU load, the throughput and the number of transmitted RSVP messages. Table 1 shows the results we got and, for each value, a ratio between it and the value obtained with the original RFC2205 daemon. It is shown that the use of the Bundle extension reduces the number of RSVP messages sent to a node of about 7 times. The Message ID extension has an opposite effect as it reduces the CPU Load and the throughput. Summary Refresh produced surprising results because it greatly reduces both packet and byte throughputs of about as much as 40 and 250 times, respectively. Moreover, in spite of the complexity of the mechanism, also the CPU load is reduced because such complexity is well balanced by the reduced load needed to pack a lower number of RSVP objects, messages and packets. This is one of the more interesting results of this study. Figures 1 and 2 trace the temporal behavior of the instantaneous throughput and signaling for 500 sessions. From these figures it is evident how the Summary Refresh messages synchronize the transmission of RSVP session’s information (the frequency of the peaks being equal to the RSVP Refresh time, 30 seconds.) Furthermore, it is easy to see how the soft state’s information is limited to a minimal amount. We then compare the scalability of the original RSVP with that of the described extensions. Figure 3 uses values derived from Table 1 to show the scalability properties

of the named extensions. Notice that in all the conditions such plots are very close to a linear function but with very different slopes. Table 1 . CPUload, throughput and signalling utilization are shown for different RSVP extensions and a different number of sessions. Each value obtained from an extension i s compared with that of the original RSVP in the form of a ratio sessions CPU load (values in percentage)

100 200 500 1000 2000

Throughput (values in byte/sec)

Signalling (values in packet/sec)

RFC2205 Bundle value ratio value 2.1 6.3 17.4 32.3 70.2

MessageID SRefresh value ratio value ratio

2.8 3.3 13.3 26.2 41.2

0.75 1.91 1.31 1.23 1.70

1.3 3.2 8.7 21.3 38.4

1.62 1.97 2.00 1.52 1.83

2.7 4.2 5.2 13.1 17.5

0.78 1.50 3.35 2.47 4.01

100 970 200 1941 500 4855 1000 9532 2000 19013

1 842 1 1633 1 4179 1 9010 1 18101

1.15 1.19 1.16 1.06 1.05

291 602 2025 4083 8021

3.33 3.22 2.40 2.33 2.37

29 51 133 220 423

33.45 38.06 36.50 43.33 44.95

100 200 500 1000 2000

1 1 1 1 1

4.14 4.29 7.07 8.42 9.69

8.8 16.7 31.6 62.2 120.3

0.99 0.98 0.98 0.97 0.99

0.1 0.1 0.1 0.2 0.4

79.09 135.83 239.23 263.48 277.21

8.7 16.3 31.1 60.6 119.2

1 1 1 1 1

ratio

2.1 3.8 4.4 7.2 12.3

Bytes/sec

6000 5000

RFC2205 Bundle Msg ID SRefresh

4000 3000 2000 1000 0 0 10 20 30 40 50 60 70 80 90 100 110 120 130 140 150 160 170 180 190 200 210 220 230 240 250 260 270 280 290

sec

Fig. 1. Comparison of the track of the throughput for different RSVP extensions

Packets/sec

40 35 30

RFC2205 Bundle Msg ID SRefresh

25 20 15 10 5 0 sec

0 10 20 30 40 50 60 70 80 90 100 110 120 130 140 150 160 170 180 190 200 210 220 230 240 250 260 270 280 290

Fig. 2 . Comparison of the track of the signaling (IP packets transmitted for RSVP messages) for different RSVP extensions packet/sec

byte/sec

140

20000 18000

RSVP2205

120

Bundle

16000

RSVP2205 Bundle

Message ID SRefresh

14000

Message ID

100

12000

SRefresh

80

10000 60

8000 6000

40

4000 20

2000

sess

0

sess

0

0

500

1000

1500

2000

Throughput scalability

0

500

1000

1500

2000

Signaling scalability

percentage

80.0% 70.0%

RSVP2205 Bundle Message ID

60.0%

SRefresh

50.0% 40.0% 30.0% 20.0% 10.0% sess

0.0% 0

500

1000

1500

2000

CPU load scalability Fig. 3. Scalability of the throughput, signaling and CPU load

Conclusions We have shown in this paper the results of some measurements about the RSVP extensions defined in RFC2961 that result in a reduction of the protocol's overhead. The results justify the effort put in this analysis by clarifying the impact of the extensions at hand in some crucial areas for the Internet like QoS and traffic engineering.

We have briefly described the extension of the most widespread implementation of the protocol with the most meaningful unicast extensions of this RFC. We have then measured the performance of these extensions with regard to the variations of three parameters, CPU load, throughput and signalling messages usage. We have demonstrated that the use of the RFC2961 extensions is useful to significantly reduce the bandwidth waste and OS load of RSVP unicast sessions but does not modify the RSVP per-flow nature and thus its scalability. While measurements are valid for one specific implementation and one combination of hardware and software only, our conclusions are not mainly based on the absolute values but they point to the improvement obtained by the described implementation compared with the original RSVP. In the 1000 sessions scenario, RFC2961 reduces Signaling and throughput respectively 250 and 40 times. It can then be concluded that its introduction can provide a significant improvement of RSVP behavior. Furthermore, in spite of the fact that RFC2961 augments the complexity of the RSVP daemon it decreases the CPU load because such complexity is well balanced by the reduced load needed to pack a lower number of RSVP objects, messages and packets. We don't expect that the use of RFC2961 will increase the usage of RSVP into core areas of the Internet, because it doesn’t modify the per-flow nature of the protocol, but RFC2961 has shown the capability to reach a great reduction of the RSVP load; hence it encourages the deployment of RSVP in larger networks than believed. The use of the modern engineering of the protocol, that is a combination of RSVP overhead reduction extensions with performing implementations and improved hardware will allow the use of the RSVP in large the Internet.

References [1] Berger L., “Generalized MPLS Signaling - RSVP-TE Extensions”, Work in Progress, draft-ietf-mpls-generalized-rsvp-te-09.txt, September 2002. [2] Awduche D., Berger L., Gan D., Li T., Srinivasan V., Swallow G., “RSVP-TE: Extensions to RSVP for LSP Tunnels”, RFC3209, December 2001 [3] Awduche D., Chiu A., Elwalid A., Widjaja A., Xiao X., “A Framework for Internet Traffic Engineering”, draft-ietf-tewg-principles-02.txt, May 2002. [4] Awduche D., Chiu A., Elwalid A., Widjaja I., Xiao X., “Overview and Principles of Internet Traffic Engineering”, RFC3272, May 2002. [5] Awduche D., Hannan A., Xiao X., “Applicability Statement for Extensions to RSVP for LSP-Tunnels”, RFC3210, December 2001. [6] Berger L., Gan D., Swallow G., Pang P., Tommasi F., Molendini S. , “RSVP Refresh Overhead Reduction Extensions”, RFC2961, April 2001. [7] Braden R., Zhang L., Berson S., Herzog S., Jamin S., “Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification”, RFC2205, September 1997. [8] Karsten M., Schmitt J., Steinmetz R., “Implementation and Evaluation of the KOM RSVP Engine”, Proceedings of the 20th Annual Joint Conference of the IEEE Computer and Communications Societies (INFOCOM'2001). [9] KOM RSVP engine, http://www.kom.e-technik.tu-darmstadt.de/rsvp/ RSVP ISI distribution, http://www.isi.edu/rsvp/release.html