Performance evaluation of RSVP using OPNET Modeler

Simulation Modelling Practice and Theory 49 (2014) 85–97

Contents lists available at ScienceDirect

Simulation Modelling Practice and Theory journal homepage: www.elsevier.com/locate/simpat

Performance evaluation of RSVP using OPNET Modeler Flavius Pana ⇑, Ferdi Put Leuven Institute for Research in Information Systems, Katholieke Universiteit Leuven, Naamsestraat 69, 3000 Leuven, Belgium

a r t i c l e

i n f o

Article history: Received 25 November 2013 Received in revised form 12 August 2014 Accepted 13 August 2014

Keywords: RSVP Performance evaluation Scalability Implementation Quality of service OPNET

a b s t r a c t RSVP represents one of the most discussed network protocols in the last decade. Although there are a large number of papers that refer to the scalability problem of the protocol, only a very limited subset of those analyze the performance of RSVP. Up to this point no real evaluation exists on the efficiency and applicability of the scalability extensions proposed for RSVP. This paper presents a simulation study of RSVP and its scalability extensions in OPNET Modeler. The results obtained are put in context of the previous work done on the scalability of RSVP. It is found that the Summary Refresh extension considerably improves the performance of the protocol both in terms of message processing and message generation. An important finding of the present paper is that the scalability of RSVP is not directly linked to the specifications of the protocol and its extensions as such, but rather to the design choices of the actual implementation under evaluation. Ó 2014 Elsevier B.V. All rights reserved.

1. Introduction The Resource Reservation Protocol (RSVP) is one of the most important signaling protocols ever developed for the Internet. Apart from the core Internet protocols (IP, TCP, HTTP, etc.) RSVP represents one of the most discussed propositions and serves as a significant protocol in terms of Quality of Service (QoS). Extensions have been introduced such that RSVP can cooperate with all major QoS mechanisms introduced by the Internet Engineering Task Force (IETF) [1]. RSVP has proven in this aspect that it represents the most relevant option for assuring good QoS to inelastic traffic [1]. The same design principles used by RSVP also have been used as a foundation for the General Internet Signaling (GIST) protocol developed under the Next Steps in Signaling working group of the IETF [2]. Moreover, RSVP plays a major role in the current Internet architecture, as the traffic engineering extension of this protocol (RSVP-TE) is used as a label distribution protocol in Multiprotocol Label Switching (MPLS) networks [3]. A detailed description of the evolution of RSVP and the functionality introduced by each of the standards that modified the original RSVP specifications [4] can be found in [1]. A major concern regarding RSVP is the fact that it suffers from a severe scalability problem. Because RSVP uses a soft state approach in maintaining reservations, messages have to be retransmitted within a certain period so that reservations do not time-out. This periodic retransmission of messages and state lookup introduces considerable processing overhead and causes the scalability problem of the protocol. The main goal of this paper is to present a performance evaluation of RSVP from a scalability point of view. We will present a simulation study in OPNET [5] of the RSVP protocol and of the scalability extensions proposed in RFC 2961. Although other network simulation tools are available on the market (ns-3, OMNeT++), OPNET Modeler was identified as one of the most suitable and feasible simulation tools that can be used in this context. It is out of the scope of this paper to argue about ⇑ Corresponding author. E-mail addresses: [email protected] (F. Pana), [email protected] (F. Put). http://dx.doi.org/10.1016/j.simpat.2014.08.005 1569-190X/Ó 2014 Elsevier B.V. All rights reserved.

86

F. Pana, F. Put / Simulation Modelling Practice and Theory 49 (2014) 85–97

the qualitative positioning of this simulation tool. Among some of the key features of OPNET Modeler are its hierarchical modeling environment, hybrid simulation and integrated, GUI-based debugging and analysis. Moreover, the fact that a large number of protocols and vendor device models are already defined in the OPNET environment represents a huge advantage. An overview of the most important network simulation tools is presented in [6]. The simulation study should not be seen as a substituent of previous results, but rather as another piece of the puzzle that completes the understanding of the scalability problem of RSVP. Insights about the performance capabilities of RSVP and its extensions are revealed and situated in the context of related work [7,8]. Different pitfalls encountered in conducting this simulation study are also illustrated. The rest of the paper is structured as follows. Section 2 summarizes previous related work. Section 3 presents functional specifications of RSVP and associated scalability extensions, together with the relevant components of the already implemented RSVP model and the implemented RSVP scalability extensions. In Section 4 we describe the approach used in conducting the simulation study. In Section 5 we discuss the obtained results and situate them in the context of previous research. And finally, in Section 6 we conclude our work. 2. Related work There are many papers that mention the scalability problem of RSVP [9–14] but only a few actually analyze this issue [15,7,16]. To our knowledge, at this point there is no simulation study of the RSVP scalability problem. The papers that discuss the scalability issue of RSVP are based on a very limited test case and a very simple topology, and do not use simulation. We do not argue the utility of the results obtained using such a real case scenario, but a series of limitations and drawbacks emerge from this approach [17]. Some of the drawbacks that we can enumerate for the real case scenario presented in [7]: the observation nodes can introduce inaccuracies in the obtained results, only two sources and two destination nodes are used, thus introducing a simplification of the lookup procedure in the state blocks (the IP addresses do not need to be matched in this case) and third, because this case is dealing with a specific configuration of the nodes, repeatability of the results is not guaranteed. Moreover, previous work that assesses the performance or the scalability of RSVP concentrates mainly on the core design of the protocol. In the mean time the IETF has introduced a number of extensions specially focused on improving the scalability of the protocol [18,19]. The most notable scalability extensions are the Bundle and the Summary Refresh (Srefresh) extension [18]. Currently, the two main publicly available implementations of RSVP, the ISI [8] and the KOM [7] implementations do not have the Bundle extension integrated, and only the KOM implementation has a running version of the Summary Refresh extension. However, the evaluation presented in [7] of the KOM RSVP concentrates more on the implementation details of the protocol and does not discuss the applicability and efficiency of the scalability extensions. Other papers evaluate various aspects of RSVP performance, e.g. control message delivery [20,21], the authentication mechanism of the protocol [22], the interaction with the timing parameters of the protocol [23,24]. However, none of them focuses on the actual scalability of the protocol. A more complete list of papers that analyze distinct enhancements of RSVP can be found in [1]. Our previous work on RSVP and the simulation of RSVP in OPNET concentrates either on analyzing the QoS obtained by utilizing the protocol, or on presenting some practical consideration in order to implement the extended functionality of the protocol in OPNET. The implementation of the RSVP Summary Refresh and Bundle extension implementation in OPNET are presented in [25,26]. The QoS obtained by utilizing RSVP as a capacity admission procedure under a new proposed service differentiation model is presented in [27,28]. However, these papers do not analyze in any way the scalability of RSVP or of the extensions under consideration. 3. RSVP functional specifications and implementation in OPNET In this section we summarize the main specifications of RSVP and the scalability extensions introduced by IETF, followed by an informal discussion of the relevant components of OPNET. A more thorough analysis of these specifications can be found in [1]. If however, an exact description of the scalability extensions is desired, then the original RFC can be consulted [18]. The major goal of this section is to present the general characteristics and functions of the RSVP model and the implemented extensions, such that results obtained from the simulation study can be interpreted properly. Further details of the proposed OPNET implementations of the Summary Refresh and Bundle extensions can be found in [25,26]. 3.1. Original RSVP design and implementation details RSVP is a receiver-oriented reservation protocol that operates on a session level providing uni-directional reservations. RSVP uses different types of messages (Path, Resv, PathError, ResvError, PathTear, ResvTear, ResvConf) in order to deliver information from one node to another and uses a soft-state approach in maintaining reservations, such that the protocol can easily adapt to new network conditions (routing update, node failure) and can easily modify the QoS parameters of a reservation. In this context, the Path and Resv messages are used to create but also to refresh reservations and path states in nodes. The path and reservation states are the states that are created in a node when a new Path or respectively a new

F. Pana, F. Put / Simulation Modelling Practice and Theory 49 (2014) 85–97

87

Resv message is received. These states are stored in what is defined in RSVP terminology as blocks, the Path State Block (PSB) for path states and the Reservation State Block (RSB) for reservation states. A reservation that is not refreshed (i.e. that does not receive a matching refresh message for the installed state, within a cleanup timeout interval) expires. Because RSVP messages are sent in an unreliable way, the periodic refresh messages are used also for recovering from possible packet loss. The lifetime of a specific state (L) is determined by the refresh timer that depends on the refresh period (R) multiplied with a constant (K). K represents the number of refresh messages that can be lost before the state times out. The refresh timer represents the time between the generation of successive refresh messages of the previous RSVP hop (that sent the message which installed the state). The suggested values of these parameters are 30 s for R, 3 for the K constant and a random value between 0.5 R and 1.5 R for the refresh timer. OPNET Modeler is the simulation tool used. It provides a hierarchical modeling environment where the highest modeling domain is represented by the network model [5]. Each router, switch or workstation is represented by a separate node model at the second level of the modeling hierarchy. The node models are further elaborated in process models. The process model is the lowest level of the modeling hierarchy and here the actual protocols and functionality are implemented. In OPNET, the rsvp process model (lowercase to differentiate it from the actual RSVP protocol) represents the main process model of the RSVP protocol. This process is responsible for creating, processing and deleting different RSVP messages as well as creating and deleting RSVP states. The process receives requests from the application layer to start or end particular RSVP sessions and sends requests to the traffic control process in the IP layer to create, delete or modify resource reservations for a particular flow. A reservation is started by the rsvp process model with a down-call from the application layer. The call will install a Path state in the node and will generate a Path message that will be sent towards the destination of this session. Along the way this message is processed in the nodes on the communication path. In each node it is verified if the corresponding state is already installed, by looping through the PSB and searching for a matching session, for that particular sender and incoming interface. If a matching state is found, then the expiration time of the state is updated and the message is destroyed. If however, no state is found, a new state is created that corresponds to the information from the Path message. If the node is not the final destination of the message, the Path message is forwarded towards its destination. If the node represents the final destination of the message, the message is destroyed and an up-call towards the application layer is initiated (in order to make the reservation decision). The same procedure is followed also for the Resv messages. The procedure first checks for a matching Path state by looping through the PSB. If no Path state is found an error message is generated. In case a matching Path state is found it is verified if any Resv state exists in the RSB for the same session. If a matching reservation state is found, it is further verified if any sender or QoS parameters need to be modified within that state. If this is not the case then the expiration time of that state is simply updated. If no state exists (or the state needs to be modified) then this is created (modified), based on the received message, and a down-call to traffic control is invoked in order to establish (or modify) a reservation. If traffic control is successful (a reservation request can fail due to insufficient resources) the new state is inserted in the RSB and a Resv message is generated (based also on the matching Path state) and sent towards the previous hop. In OPNET, a single procedure is in charge of generating Path and Resv refresh messages. This procedure is invoked upon the expiration of a refresh timer in a specific node and a simple event sequence is followed for the procedure in that node. First, all the Path states (maintained by the node) are scanned, and the ones that are expired are deleted (expired means that current simulation time is bigger than the expiration time of the state). Afterwards, for each maintained Path state that is not expired a Path refresh message is generated. Second, the Resv states are scanned and the expired ones are deleted. The generation of the Resv refresh messages is started next. For each Path state from the PSB the RSB is searched for a matching reservation state. If a matching reservation state exists, then the reservation state is refreshed by sending a Resv refresh message towards the previous hop. This behavior is in concordance with the specifications presented in [4], stating that for each refresh interrupt received, all the (RSVP) states of a node are refreshed at the same time. 3.2. Bundle extension The RSVP Bundle extension consists mainly of a new RSVP message, the Bundle message that bundles multiple RSVP messages in the same Protocol Data Unit (PDU). A Bundle message contains a variable number of standard RSVP messages, but should contain at least one sub-message. All standard RSVP messages can be bundled, with the exception of the RSVP Bundle message itself. Bundle messages can only be sent between RSVP neighbors that support this extension. A node that supports the RSVP Bundle extension is not required to transmit every RSVP message in a Bundle message and should always be prepared to receive standard RSVP messages. Our implementation concentrates on RSVP refresh messages, because only refresh messages will be bundled, leaving RSVP trigger messages to be sent using normal RSVP procedures. In this implementation a Bundle message is created every time a refresh message is created for a particular interface and no Bundle message exists for that interface. In other words, irrespective of the time period that passed since the last bundle message was generated, a new Bundle message is created only when a RSVP refresh message needs to be bundled. The refresh procedure presented earlier for the original RSVP design will be the basis of our Bundle extension. After the path states that are not expired are identified, instead of generating Path messages directly it is verified if the outgoing interface of that message supports the Bundle extension (if the outgoing interface is Bundle capable) and if the RSVP neighbor is

88

F. Pana, F. Put / Simulation Modelling Practice and Theory 49 (2014) 85–97

RSVP Bundle capable. If a Bundle message already exists for that interface the Path message is created and bundled as a submessage. If no bundle message exists then this is generated and the corresponding Path message is bundled as the first submessage within this Bundle message. The same process will be used by the Resv refresh messages as well. The maximum theoretical size allowed for a Bundle message is the maximum size of one IP datagram such that the datagram is not fragmented by IP. Before a new sub-message is included within the Bundle message it is verified if the total length of the Bundle message (including the new sub-message) will exceed the maximum Bundle size for that interface. In that case, the Bundle message is sent towards the next hop, and the sub-message becomes the first sub-message of a new Bundle message. Bundle messages are also sent when the hold timer of the message expires. Bundle messages are sent hop-by-hop as raw IP datagrams. Each time a Bundle message is received by a node, the respective node processes every individual sub-message bundled within as if normal Resv and Path messages were received. 3.3. Summary Refresh extension The Summary Refresh extension proposed in RFC 2961 [18] is built on another addition suggested by the same standard, the Message ID extension. Basically the Message ID extension provides a way through which each RSVP (refresh) message and the state information it represents can be simply identified by the Message_Identifier value and the IP address of the node that generated the message. When a node fully processes a message (Path or Resv) this Message_Identifier value should be stored as a part of the relevant state. The Summary Refresh extension allows refreshing of Path and Resv states without the full retransmission of standard Resv and Path messages. The extension is designed only for refresh messages (Path and Resv). The Srefresh message carries a list of Message_Identifier fields, corresponding to the states that have to be refreshed. In our implementation two new fields are introduced in both the Path and Resv state blocks. These fields are the input identifier (IN ID) and output identifier (OUT ID). Each state has associated an IN ID based on which the state will be refreshed and an OUT ID that will be used to refresh the state of the next RSVP capable node for that state. When a new state is installed, either in the PSB or in the RSB, and the message that triggered the creation of the state has an ID field set and the incoming interface of the message supports Summary Refresh then we initialize the IN ID of the new created state with the value of the ID field included in the message. If the outgoing interface has the Summary Refresh enabled, then the OUT ID is assigned a value. Whenever a Path or Resv messages is generated, it is verified if the OUT ID exists for that state. If this is the case then the value of the OUT ID is included in the ID field of the newly created message. The Summary Refresh implementation will use the same approach in generating refresh messages as the existing RSVP implementation in OPNET. Each time the refresh timer expires, Srefresh messages are generated and sent for each interface that has RSVP Summary Refresh enabled. For each Path state that has not expired and has no OUT ID initiated, normal RSVP processing will be done. However, if the OUT ID field is initialized, it is verified if on the outgoing interface of that message a Srefresh message exists. If this is not the case a new Srefresh message is generated for that interface, and the OUT ID is included as the first element in the message. If however, the message already exists it is verified if the length of the resulting message is smaller than the maximum length allowed for Srefresh messages for that interface. If so, the ID is simply added to the list of message identifiers that have to be sent. However, if the value is greater, then that Srefresh message is sent, and a new Srefresh message is generated for the current ID. The process described above is done for all the Path and Resv states of the node. Each time a Srefresh message is received this is processed by looping through all the ID fields of the message. The matching of the state is based on the ID and on the source address of the Srefresh message by searching through all the existing states. The expiration time of the matching state is updated as if a normal Resv or Path refresh message was received. 4. Simulation approach The main focus of our simulation study is concentrated on the evaluation of simple RSVP, the RSVP Bundle extension and the RSVP Summary Refresh extension regarding the scalability of the protocol. In this section we present the most important aspects of our simulation study. 4.1. Network topology Two important requirements must be taken into consideration when designing the network topology. First, because we focus on analyzing the scalability of RSVP, the topology should allow an observation point to capture the performance of RSVP. Second, the topology should support without important alterations a varying number of unicast RSVP reservations. This implicitly means that a large number of end-nodes on which the reservations are initiated/terminated should be easily incorporable in the topology. The approach followed in our simulation is that each simulated workstation will initiate and generate messages for a distinct reservation. This approach will guarantee the correct generation and processing of RSVP reservation messages. More details about reservation setup will be explained in Section 4.2. Fig. 1 presents the topology that will be used in the simulation. Following a general topology design, three layers can be identified. The core layer is composed of three routers in the

89

F. Pana, F. Put / Simulation Modelling Practice and Theory 49 (2014) 85–97

C1 subnet 1

S1 subnet 1

C1 subnet 2

S1 subnet 2 S1 subnet 3

4000 S1

4000 C1

C1 subnet 3 C2 subnet 1

S2 subnet 1

C2 subnet 2

S2 subnet 2

4000 S2

S2 subnet 3

4000 C2

C2 subnet 3

S3 subnet 1

C3 subnet 1

S3 subnet 2

C3 subnet 2

S3 subnet 3

4000 Router S

4000 S3

S4 subnet 1 S4 subnet 2

4000 Router C

7500 Router Core

4000 C3

C4 subnet 1 C4 subnet 2

Core Layer

4000 S4

S4 subnet 3

C3 subnet 3

4000 C4

C4 subnet 3

S5 subnet 1

C5 subnet 1

S5 subnet 2

C5 subnet 2

S5 subnet 3

4000 S5

4000 C5

C5 subnet 3

Access Layer

Distribution Layer

Distribution Layer

Access Layer

Fig. 1. Network topology.

center of the topology. The distribution layer is composed of 10 routers, five routers connected to Router C, and five routers connected to Router S. Each router from the distribution layer is connected to a varying number of subnets from one scenario to another (as will be explained in Section 4.3). Each subnet is composed of an Ethernet switch that is connected to 100 workstations. Fig. 2 illustrates the topology of a subnet. All links from the access layer are 100 BaseT duplex links operating at 100 Mbps. This includes the links connecting every workstation to the switch in a subnet, but also the connection of the switch to the corresponding distribution router. The links between routers from the distribution layer and the routers in the core layer are 1000 BaseX duplex links operating at 1 Gbps. The links in the core layer are 10 Gbps Ethernet links. Traffic will always flow through all three layers of the topology, meaning that every RSVP reservation will pass through the Router Core in the center of the topology. All the statistics that we will discuss in the Results section will be collected at the Router Core node. The presented topology is easily extendable, in the sense that more subnets or workstations can be included in the access layer without modifying the core and distribution layer of the network.

4.2. Traffic specifications

10

ro

ws

In order to initiate RSVP reservations, an application must be configured first to require the support of RSVP and to send a request to the rsvp process model. The node that initiates the RSVP signaling (by generating the first Path message) will represent the (traffic) source of the application. The node that sends the first RESV message will be in this case the destination of the actual application.

C1 node 1

node 2

node 3

node 4

node 5

node 6

node 7

node 8

10 nodes / row

node 9

node 10

Subnet Switch

100 links 1 link / node <---> Switch Fig. 2. Subnet topology.

90

F. Pana, F. Put / Simulation Modelling Practice and Theory 49 (2014) 85–97

In this simulation voice communication is used as the application since it uses a clear sender and destination configuration (for a one-to-one voice communication) and has clear bandwidth requirements. The topology presented earlier has the property of being symmetrical, meaning that the number of end-nodes at the left hand side is equal to the number of endnodes on the right hand side. A voice communication is initiated for each end-node of the left hand side with the corresponding or equivalent end-node on the right hand side. This will create a total of n voice communications, where n represents half of the number of end-nodes included in the topology. The number of reservations in this case will equal to 2n or to the total number of simulated end-nodes, since RSVP reservations are unidirectional and 2 reservations are necessary for each one-toone voice communication. Each of the simulated end-nodes will be in charge of creating a reservation and maintaining that reservation. The Discrete Event Simulation (DES) engine used by OPNET explicitly processes every packet and provides very accurate simulation results. However, running a DES for a very large network with thousands of voice communication pairs is extremely processing intensive. Because the actual voice traffic and the processing associated with each voice packet is not a direct concern of our study (only the processing of the RSVP messages is of interest), the actual voice traffic will not be simulated using DES but using the hybrid simulation capability of OPNET. Hybrid simulation combines DES and analytical methods in order to take advantage of both [29–31]. In our case all the RSVP messages will be simulated explicitly and modeled at a detailed level, while the voice traffic will be simulated as background traffic produced by analytical modeling. Background traffic will influence the available capacity of a link, but nodes will not process this traffic. This approach allows us to concentrate on evaluating the performance of RSVP while reducing the computing power and simulation runtime required in order to run the simulation. 4.3. Simulation sequence Using the network topology and traffic specifications described earlier, three simulation sets are constructed, one for each RSVP flavor under analysis: simple RSVP, the RSVP Bundle extension and Srefresh RSVP. The simulation sets created and the associated RSVP parameters are presented in Table 1. For each simulation set six scenarios are considered. The first scenario includes a total of 10 subnets or 1000 end-nodes (workstations) in the access layer. This number of nodes is increased progressively with 1000 nodes in each of the following scenarios by connecting an additional subnet to each router from the distribution layer. The maximum number of 6000 workstations (reached in the sixth scenario), and implicitly the number of RSVP reservations, is not an indication of the limitations of the RSVP protocol, but is rather linked to the limited resources available in order to run the simulation. The main bottleneck in our case was the available memory that could be used by the simulator engine. Total memory consumption for 6000 nodes in the simple RSVP simulation set is around 95% of available memory (8 GB). Increasing the number of nodes even further will cause the exhaustion of RAM and will lead to a dramatic increase of the simulation runtime, thus affecting also the obtained results. All the simulations will be run for 10 min (simulated time). RSVP reservations are started after 30 s of simulated time. The RSVP parameters that are used for the Srefresh and Bundle extensions are presented in Table 1. A common feature of all the simulations is that the refresh period configured for all the nodes is 30 s, the default value as it is specified in [4]. The actual refresh timer used by an individual node is a random value between 15 s and 45 s. Because voice traffic will be simulated using hybrid simulation, this traffic will not be modeled explicitly, but will be reflected in the available bandwidth of a link. In Table 2 we present the bandwidth consumed by the voice traffic for the various links in our topology. The maximum link utilization, of around 30% for the links between the access and the distribution layer, demonstrates that the RSVP messages will not be affected in any way by this background traffic. Up to this point no real mechanism exists that can be used in order to analyze the performance or scalability of a protocol using simulation. Moreover, no reference to this problem can be found in the broader literature of network simulation. For this reason, new statistics must be introduced that can provide an estimation of the processing that has to be done by a node to support the RSVP protocol. According to the functional and implementation specifications of RSVP presented in Section 3, the execution overhead of RSVP can be divided in two main parts. The first part represents the effort to process incoming RSVP messages and update the corresponding states. Secondly, there is the processing effort necessary in order to inspect states and to generate RSVP messages. For that purpose two new statistics are introduced, one that measures the time it takes to process an RSVP message, and another that measures the time it takes to process the complete RSVP refresh sequence of a node. These statistics will be used in order to get an indication of the relative effort a node has to do while increasing the number of RSVP reser-

Table 1 Simulation sets and RSVP parameters. Simulation set

RSVP flavor used

RSVP parameters

1 2

Simple Bundle

3

Srefresh

Refresh period: 30 s Max. (Bundle) message size: 4096 (Bytes) Max. (Bundle) hold time: 15 (s) Max. (Srefresh) message size: 4096 (Bytes)

F. Pana, F. Put / Simulation Modelling Practice and Theory 49 (2014) 85–97

91

Table 2 Bandwidth consumed by background traffic. Link location (example)

Link capacity

Bandwidth consumed

Access link (node 1 $ Subnet Switch) Access – Distribution link (Subnet Switch $ C1) Distribution – Core link (C1 $ Router C) Core link (Router C $ Router Core)

100 Mbps 100 Mbps 1 Gbps 10 Gbps

31.2 Kbps (including the IP, UDP, RTP and Ethernet headers) 31.2 Kbps  100 flows = 31,2 Mbps 31,2 Mbps  6 subnets (6th scenario) = 0.1872 Gbps 0.1872 Gbps  5 Distribution Routers = 0.936 Gbps

vations in the different simulation sets. Both statistics reflect the actual time (and not simulation time) it takes in order to process a RSVP message or to process the refresh sequence. As we presented earlier, multiple scenarios are considered for each of the three RSVP flavors under analysis. For each scenario 10 replications will be executed. The reason why we run 10 replications for a scenario is twofold. First, the value of the refresh timer is randomly selected for each node at the beginning of the simulation. In order to be sure that the obtained results do not represent a particular outlier for a specific combination of refresh timer values, multiple replications of the same scenario are executed. Secondly, the actual results of the statistic that reflects the processing time of the RSVP message and refresh sequence can be influenced by other processes running on the same machine. In order to flatten out these influences, multiple independent replications are executed. 5. Results In this section we are going to analyze and evaluate the results obtained from the simulation study. First we present and interpret the obtained results. In the second subsection, based on these results, but also on the implementation details presented earlier, we evaluate the run time complexity of the RSVP extensions in order to get a better understanding of the execution overhead introduced by each of these extensions. The main goal of this subsection is to offer some form of quantifiable measure of the scalability problem of RSVP. In the last subsection we will situate the obtained results in the context of the existing research on the scalability of RSVP. 5.1. Obtained results Fig. 3 presents an indication of the execution overhead of RSVP necessary to process received RSVP messages for the different simulation sets and scenarios described in the previous section. The figure shows the total execution time required by the Router Core to process all received RSVP messages in the 10 simulated minutes for the three different analyzed flavors of RSVP. Each point (6 points per simulation set) represents an average of the results obtained in 10 replications for that scenario. As we can see from Fig. 3 the Summary Refresh extension considerably outperforms both the Bundle and the Simple RSVP flavors. Even if the Bundle extension uses a new message type, all the sub-messages that are included within are processed using the same procedures and the same functions as in the simple RSVP case leading to an almost identical behavior as in the Simple RSVP case. On the other hand, the Srefresh message is processed using new and simpler procedures. This translates in a lower processing effort for the Srefresh case when compared to the Bundle and Simple RSVP flavors. The only significant processing required by the Srefresh message is a search in the corresponding state block for each of the received IDs. The coupling in this case is based only on the sender IP address and the received ID. The simple RSVP and Bundle extensions on the other hand, also use a linear search strategy in the corresponding state blocks, but using more complicated procedures. Another clear advantage of the Summary Refresh extension is the fact that from the start the receiving node knows that the received message represents a refresh message. This implies that no further processing is required in

Simple RSVP

Bundle

Srefresh

Time (seconds)

70 60 50 40 30 20 10 1000

2000

3000

4000

5000

Fig. 3. Execution overhead for message processing.

6000

F. Pana, F. Put / Simulation Modelling Practice and Theory 49 (2014) 85–97

Time (seconds)

92

5.0 4.5 4.0 3.5 3.0 2.5 2.0 1.5 1.0 0.5 0.0

Simple RSVP

1000

2000

Bundle

3000

4000

Srefresh

5000

6000

Fig. 4. Execution overhead for message generation.

order to deduce if the matched state needs to be modified, and only the value of the expiration time of that state has to be updated. In Fig. 4 we present the execution overhead induced by the refresh sequence that includes the processing necessary for generating RSVP messages for all the RSVP maintained states. The figure illustrates the actual processing time (in seconds), required by the Router Core node in order to process the refresh sequence for the three simulation sets and for different numbers of reservations. The value of each data point included in the figure is calculated as the average time required to process a single refresh sequence, averaged over 10 replications. As in the message processing case, it can be observed that the processing effort is almost identical for the Bundle and simple RSVP case. This can be explained by the fact that the refresh sequence is processed in almost the same way in the two cases. On the other hand, the Summary Refresh extension introduces an important gain in terms of processing effort necessary to process the refresh sequence. Although all the RSVP flavors use the same refresh strategy, the Summary Refresh extension only needs to include the value of the OUT ID associated with a specific state that must be refreshed. This represents a considerable decrease of processing when compared to the simple RSVP message generation procedures that have to create all the relevant RSVP objects corresponding to that state. Up to this point no real benefits can be noticed for the Bundle extension compared with the simple RSVP case. As we explained, this is the expected behavior since the procedures that process and generate the Resv and Path messages (submessages for the Bundle case) are the same. The only advantage of using the Bundle message is reflected in the bandwidth consumption associated with the RSVP messages. In Fig. 5 we present the total volume of traffic sent during the 10 simulated minutes by the Router Core at the IP layer averaged over 10 replications. In this case, the Bundle extension considerably outperforms simple RSVP. The difference in bandwidth comes from the overhead induced by the IP header. Each single RSVP message has to be associated with an IP header in the simple RSVP while the Bundle extension associates an IP header only with a Bundle message. However, the benefits of the Bundle extensions can be regarded as marginal at best when compared to the bandwidth consumed by the Summary Refresh extension. 5.2. Evaluation of run-time complexity In order to get a better understanding of the execution overhead introduced by each of the RSVP flavors, and to be able to offer a quantifiable measure of the scalability of RSVP, we will evaluate the run-time complexity of the associated procedures for each of the RSVP flavors. Let us consider a function T p ðnÞ that expresses the processing effort of a node in order to process a single RSVP message when n states are maintained by that node. If we consider the most important (computational expensive) elements from the description presented in Section 3, the function T p ðnÞ will have the form:

T p ðnÞ ¼ ci ni þ cu

ð1Þ

where ni – is the number of iterations necessary in order to associate the received message with a state. In a worst case scenario this is actually n (number of states maintained by that node); ci – is the effort to identify a particular state using specific identifiers (cost of an iteration); cu – is the processing effort to modify a state after this is associated with the received message. The presented function is equally applicable for simple RSVP, the Bundle extension and the Summary Refresh extension. However, as we presented earlier, the value of the constants cu and ci is considerably lower in the last case. In all three cases we can see that the expected processing effort is linearly proportional with the number of maintained states. However, the results presented in Fig. 3 demonstrated a polynomial increase of the execution overhead rather than a linear one. This is due

F. Pana, F. Put / Simulation Modelling Practice and Theory 49 (2014) 85–97

Simple RSVP

Size (bytes x 10 6)

40

Bundle

93

Srefresh

35 30 25 20 15 10 5 1000

2000

3000

4000

5000

6000

Fig. 5. Total traffic sent by the Router Core at the IP layer.

to the fact that the graphic presents the processing required by the Router Core node for all the messages received during the 10 min of simulated time, and not the processing time of an individual message. If however, we analyze the evolution of the processing effort for a single RSVP message in the simple RSVP scenario illustrated in Fig. 6 we can see that the execution time (expressed in microseconds) increases approximately linearly with the number of maintained reservations. An observation that has to be made here is that in the 6000 reservations scenario, the available memory (RAM) of the machine that runs the simulation is on the edge of being exhausted and this slightly affects the processing time of an RSVP message in this case. This is represented as a distinct data point in Fig. 6. In order to understand the results presented in Fig. 3 let us consider a function T tp ðm; nÞ that captures the processing effort in a node in order to process a number of m incoming messages. When the node maintains a total of n states the function T tp ðm; nÞ has the form:

T tp ðm; nÞ ¼

m X ðci ni þ cu Þ

ð2Þ

1

If we limit the function only to the messages received by a node in a single refresh interval (R), and if we assume that the RSVP neighbors connected to that node have the same value for R, then the number of RSVP refresh messages received by a node becomes equal to the number of states maintained by that node. In this case we also assume that we have stable network conditions and that all the installed states are maintained. We use the notation nm in order to express the number of messages that have to be processed by a node in a refresh interval since this number is dependent on the number of n states maintained by that node. Then the function T tp ðm; nÞ becomes T tp ðnm ; nÞ:

T tp ðm; nÞ ¼ T tp ðnm ; nÞ ¼

nm X ðci ni þ cu Þ ¼ nm ðci ni þ cu Þ

ð3Þ

1

If we consider nm ¼ n, and take the worst case scenario in consideration (ni ¼ n), then T tp ðnm ; nÞ becomes T tp ðn; nÞ or T tp ðnÞ:

T tp ðnÞ ¼ nðci n þ cu Þ ¼ n2 ci þ ncu ! Oðn2 Þ

ð4Þ

The obtained function depicts a polynomial growth rate of the second degree, being equivalent to a Oðn2 Þ complexity. This type of growth rate of the processing effort for all incoming messages can be observed in Fig. 3 for all RSVP flavors. In this case, the fact that we collect the statistics for the duration of the whole simulation instead of a single refresh interval does

Time (microseconds)

Simple RSVP

Simple RSVP 6000 flows

250 200 150 100 50 0

1000

2000

3000

4000

5000

Fig. 6. Processing time of a single RSVP message.

*6000

94

F. Pana, F. Put / Simulation Modelling Practice and Theory 49 (2014) 85–97

not affect the nature of the processing effort function. If we would consider the total T tp ðnÞ processing effort required by a node in order to process all the incoming messages in a certain time period ‘t’ received from RSVP neighbors assuming a common refresh period R then T tp ðnÞ becomes:

T tp ðnÞ ¼ ðn2 ci þ ncu Þt=R

ð5Þ

where the t=R term represents a constant in the equation that is not affected by the number of maintained states. Of course increasing the refresh period would decrease the overall processing required by the node, but will not affect the growth rate of the execution runtime. If we detail the processing effort when ‘k’ nodes are sending refresh messages to the processing node we obtain:

T tp ðnÞ ¼

k X tnmj j¼1

Rj

ðnci þ cu Þ

ð6Þ

where nmj represents the number of refresh messages sent by a certain RSVP neighbor in order to be processed within a certain refresh period Rj . In our simulation case since the Router Core is connected to two RSVP neighbors ðk ¼ 2Þ that contribute equally to the number of refresh messages sent towards the Router Core ðnmj ¼ n=2Þ we obtain:

n t n t ðnci þ cu Þ þ ðnci þ cu Þ 2 R1 2 R2   n2 ci þ ncu t t ! Oðn2 Þ þ T tp ðnÞ ¼ R1 R2 2

T tp ðnÞ ¼

ð7Þ ð8Þ

The second part of Eq. (8) represents a constant, depending on the values set for the refresh timers (R). In this case if the R1 and R2 values are equal, we obtain the previous Eq. (5). The processing effort illustrated in Fig. 3 follows Eq. (8) or (6), rather than the one presented in (4). However, for simplicity of the presentation and because the t=R term represents a deductible constant that does not change the complexity of the execution effort, we will use versions (3) and (4) of the equations further, rather than referring to the more general formulation (6). Regarding the processing effort for generating refresh messages for ‘n’ maintained states, we can define a function T ref ðnÞ taking into consideration the implementation details presented in Section 3. The T ref ðnÞ function will have the form:

T ref ðnÞ ¼ np1 cp þ np2 ðnr cir þ cr Þ

ð9Þ

where cp – is the processing cost of generating a message so as to refresh a Path state; np1 – is the number of iterations, so as to refresh all the maintained Path states; cr – is the processing cost of generating a message so as to refresh a reservation state; np2 – is the number of iterations, so as to refresh all the maintained Resv states; cir – is the processing cost of identifying the reservation state corresponding to the path state used in order to create the Resv reservation message; nr – is the number of iterations, in order to find the Resv state that corresponds to a Path state for which the Resv message has to be generated. The values of np1 and np2 in essence are identical and equal to the number of maintained Path states, the size of the PSB. We present these variables with different indexes in (9) just to illustrate the different functionality associated with the evaluated implementation. The value of nr in the worst case scenario is equal to the number of maintained Resv states or the size of the RSB. Because we assume stable network conditions where all the installed states are maintained, the size of the PSB will be equal to the size of RSB. In this case (9) becomes:

T ref ðnÞ ¼ n2 cir þ nðcp þ cr Þ ! Oðn2 Þ

ð10Þ

We can see from the obtained function that just like the message processing case, the processing effort associated with refreshing all maintained states in a refresh period is also a polynomial function of the second degree. In this case the only difference that exists between the three flavors of RSVP is the values of the ‘c’ constants for the Summary Refresh extension. Taking into consideration both Eqs. (10) and (4) we can define a function T RSVP ðnÞ that expresses the total processing overhead experienced by a node that maintains ‘n’ states (reservations) within a refresh interval. The function T RSVP ðnÞ has the form:

T RSVP ðnÞ ¼ T tp ðnÞ þ T ref ðnÞ ¼ n2 ci þ ncu þ n2 cir þ nðcp þ cr Þ ! Oðn2 Þ

ð11Þ

From (11) we can observe that the overall run-time complexity of RSVP increases following a second degree polynomial function ðOðn2 ÞÞ. It is important to notice that this equation captures the processing effort of a node within a single refresh period R. However, as we have demonstrated in Eqs. (5)–(8), considering multiple refresh periods does not modify the nature

F. Pana, F. Put / Simulation Modelling Practice and Theory 49 (2014) 85–97

95

of Eq. (11). Another observation that can be made here is that the presented equations are capturing solely the processing and generation of RSVP refresh messages and not trigger messages. This distinction between trigger and refresh messages was important because the scalability extensions of RSVP are implemented only for RSVP refresh messages. However, since RSVP messages are idempotent, the complexity of the expressed equations does not change. This can also be seen from the implementation of the original RSVP design presented in Section 2, where similar operations are performed for RSVP trigger and RSVP refresh messages. 5.3. Positioning in the context of related research Eq. (11) is inferred from the basic implementation of RSVP in OPNET Modeler and the design choices made in this implementation. However, as it was demonstrated in Section 2, the design choices for the RSVP implementation in OPNET chart very closely the specifications presented in [4]. The same type of ad litteram RSVP implementation can be seen in the ISI implementation [8] and in the basic KOM RSVP implementation [7]. A similar evolution of the processing effort ðOðn2 ÞÞ for RSVP in rapport with the number of reservations can also be observed in both [8,7]. A special case is the tuned KOM RSVP implementation that manages to obtain a linear increase of the CPU load as a function of the number of sessions [7]. This tuned version of RSVP uses an optimized implementation, still following the main specifications presented in [4], but tailored to accomplish certain operations more efficiently. Two of the most important characteristics of this optimized RSVP implementation are the use of hash-based containers for session objects that identify a particular state [7] and the fact that relationships between different states are explicitly stored. These relationships are possible because the overall implementation is based on an object-oriented design. If we would reconsider Eq. (11) for T RSVP ðnÞ and write a more general equation according to (3) and (9) we would obtain:

T RSVP ðnÞ ¼ nm ðci ni þ cu Þ þ np1 cp þ np2 ðnr cir þ cr Þ

ð12Þ

In an optimized version of RSVP as the one presented in [7] two important simplifications are possible. First, because of the hash-based container, the processing of incoming messages does not depend any longer on the number of maintained states. In this case the term ci ni become a simple constant hc that represent the processing cost of the hash-based container in order to identify a state. Secondly, because relations between different states are maintained, it is not necessary anymore to go through all the path states in order to send Resv refresh messages. In this case the whole np2 ðnr cir þ cr Þ part of Eq. (12) can be simply replaced with nr cr that represents the number of maintained reservation states multiplied with the cost of creating one reservation message. Taking all this in consideration, Eq. (12) becomes:

T RSVP ðnÞ ¼ nm ðhc þ cu Þ þ np cp þ nr cr

ð13Þ

If we consider stable conditions, meaning that the number of maintained path states equals the number of reservations states ðnp ¼ nr ¼ nÞ, then we obtain:

T RSVP ðnÞ ¼ nm ðhc þ cu Þ þ nðcp þ cr Þ

ð14Þ

If we further simplify Eq. (14) including the fact that the number of received messages nm is dependent on the number of maintained states we obtain:

T RSVP ðnÞ ¼ nðhc þ cu Þ þ nðcp þ cr Þ ! OðnÞ

ð15Þ

Eq. (15) demonstrates that a linear increase of the processing complexity can be obtained by a RSVP implementation if efficient design choices are made. These results are conform to the overall execution overhead of RSVP presented in [7]. Eq. (15) illustrates also a lower bound for the execution overhead of RSVP. This limit is a consequence of the fact that RSVP treats each session separately. Messages have to be generated and processed for each maintained reservation. A further decrease below ðOðnÞÞ would imply the modification of the actual behavior of the protocol and so departing from the specifications presented in [4,18]. It is interesting to notice that in [7] a ‘per state’ refresh procedure was adopted instead of refreshing all the states at once (on a per node basis), as it was presented in the previous section of this paper. The generation of refresh messages is done for each state individually using a rather complicated timer management structure. This type of approach has the advantage of not generating traffic spikes in the network due to RSVP refresh messages. However, maintaining a timer container to trigger the generation of a refresh message for a certain state represents a rather computational expensive operation. Furthermore, this type of approach does not reduce the overall complexity associated with the generation or RSVP refresh messages, since in a refresh interval ‘R’, still the same number of ‘n’ refresh messages equal to the number of maintained states have to be generated. Another possible solution of reducing the execution overhead of the protocol could be the use of Aggregated RSVP, standardized in [19]. This extension of the protocol maintains reservations for aggregates of flows rather than for individual flows, by using Differentiated Service Code Points (DSCPs) [32]. Other approaches for coupling the Differentiated Service (DiffServ) mechanism [33] with RSVP can be found in [34,27,28]. However, even if these approaches demonstrate the flexibility and modularity of RSVP, they are not of immediate interest since they do not discuss the scalability of the protocol. Up to this point no detailed analysis on the scalability of this extension can be found in the literature. A notable exception is given by [35] where an empirical analysis is provided for Aggregated RSVP. However, as in [7] for the original RSVP design,

96

F. Pana, F. Put / Simulation Modelling Practice and Theory 49 (2014) 85–97

the repeatability of the results is rather limited and the prototype code used for evaluation allows only a few hundred endto-end reservations on a test bed of low power machines. Further particularities and limitations of the Aggregated RSVP extension are discussed in [36], where a simulation model is proposed in order to evaluate the protocol. However, this evaluation concentrates on standard QoS parameters under various bandwidth management policies, while scalability is not analyzed since the authors find the simulation tool unsuitable to evaluate the actual processing time [36].

6. Summary and conclusions This paper presents a simulation study of the original RSVP design, of the Bundle extension and of the Summary Refresh extension in OPNET Modeler. Both extensions are publicly available in the Riverbed OPNET Modeler space [37], allowing researchers to elaborate further on this model and to incorporate other RSVP extensions or proposals. Regarding the actual performance evaluation of RSVP, it is found that the Summary Refresh extension considerably outperforms both the original RSVP design and the Bundle extension. The only noticeable difference between the Bundle extension and the original RSVP design can be seen in the total bandwidth consumed (including IP overhead). The results obtained should be seen as complementing the overall understanding of the scalability problem of RSVP. Furthermore, on the basis of the simulation results and implementation details, the run-time complexity of RSVP is evaluated and represented as a function of the number of reservations maintained. It is found that a straightforward RSVP implementation is expected to have a quadratic increase of the processing effort in rapport with the number of maintained reservations. However, a more tailored or optimized implementation could obtain a linear increase of the processing effort, as has been shown in [7]. It is clear from the obtained results that the scalability of RSVP cannot be judged in general from the specifications and message processing rules specified in various RFCs, but has to be analyzed for each particular implementation separately. The design choices during an implementation heavily influence the execution overhead of RSVP and are responsible for offering a more scalable version of RSVP or not. It has been demonstrated however that the minimum expected increase of the execution cost is a linear function that depends on the number of reservations. This is a consequence of the per flow behavior associated with RSVP.

References [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26] [27]

F. Pana, F. Put, A survey on the evolution of RSVP, IEEE Commun. Surv. Tutorials 15 (2013) 1859–1887. H. Schulzrinne, R. Hancock, GIST: General Internet Signalling Transport, 2010. . E. Rosen, A. Viswanathan, R. Callon, Multiprotocol Label Switching Architecture, 2001. . R. Braden, L. Zhang, S. Berson, S. Herzog, S. Jamin, Resource ReSerVation Protocol (RSVP) – Version 1 Functional Specification, RFC 2205 (Proposed Standard), 1997. . Riverbed Technology, The Riverbed Webpage, 2013. . M.A. Rahman, A. Pakstas, F.Z. Wang, Network modelling and simulation tools, Simulat. Model. Pract. Theory 17 (2009) 1011–1031. M. Karsten, Collected experience from implementing RSVP, IEEE/ACM Trans. Netw. 14 (2006) 767–778. USC Information Sciences Institute (ISI), The RSVP project of the Information Sciences Institute, 2013. . W. Zhao, D. Olshefski, H. Schulzrinne, Internet Quality of Service: An Overview, Technical Report, Columbia University, 2000. A. Meddeb, Internet QoS: pieces of the puzzle, IEEE Commun. Mag. 48 (2010) 86–94. D. Vali, S. Paskalis, L. Merakos, A. Kaloxylos, A survey of internet QoS signaling, IEEE Commun. Surv. Tutorials 6 (2004) 32–43. X. Fu, H. Tschofenig, D. Hogrefe, Beyond QoS signaling: a new generic IP signaling framework, Comput. Netw. 50 (2006) 3416–3433. M. Welzl, M. Muhlhauser, Scalability and quality of service: a trade-off?, IEEE Commun Mag. 41 (2003) 32–36. R. Wójcik, A. Jajszczyk, Flow oriented approaches to QoS assurance, ACM Comput. Surv. 44 (2012) 5:1–5:37. T. Chiueh, A. Neogi, P. Stirpe, Performance analysis of an RSVP-capable router, in: Proceedings, Fourth IEEE, Real-Time Technology and Applications Symposium, 1998, pp. 39–48. F. Tommasi, S. Molendini, S. Zacchino, Measurements of the performance of the RSVP protocol, in: Proceedings, Art-QoS, Workshop on Architectures for Quality of Service in the Internet, 2003, pp. 24–25. A. Bazzi, G. Pasolini, On the accuracy of physical layer modelling within wireless network simulators, Simulat. Model. Pract. Theory 22 (2012) 47–60. L. Berger, D. Gan, G. Swallow, P. Pan, F. Tommasi, S. Molendini, RSVP Refresh Overhead Reduction Extensions, RFC 2961 (Proposed Standard), 2001. . F. Baker, C. Iturralde, F.L. Faucheur, B. Davie, Aggregation of RSVP for IPv4 and IPv6 Reservations, RFC 3175 (Proposed Standard), 2001. . O. Komolafe, J. Sventek, An evaluation of RSVP control message delivery mechanisms, in: Workshop on High Performance Switching and Routing, HPSR, 2004, pp. 43–47. M. Menth, R. Martin, Performance evaluation of the extensions for control message retransmissions in RSVP, in: Proceedings of the 7th IFIP/IEEE International Workshop on Protocols for High Speed Networks, PIHSN ’02, Springer-Verlag, London, UK, 2002, pp. 35–49. J. Zhi, C.-H. Lung, X. Xu, A. Srinivasan, Y. Lei, Securing RSVP and RSVP-TE signaling protocols and their performance study, in: 3rd International Conference on Information Technology: Research and Education, ITRE, 2005, pp. 90–94. P. Sharma, D. Estrin, S. Floyd, V. Jacobson, Scalable timers for soft state protocols, in: INFOCOM ’97. Sixteenth Annual Joint Conference of the IEEE Computer and Communications Societies, Driving the Information Revolution, Proceedings IEEE, vol. 1, 1997, pp. 222–229. O. Komolafe, J. Sventek, RSVP performance evaluation using multi-objective evolutionary optimisation, in: INFOCOM 2005, 24th Annual Joint Conference of the IEEE Computer and Communications Societies, Proceedings IEEE, vol. 4, 2005, pp. 2447–2457. F. Pana, F. Put, RSVP summary refresh extension in OPNET modeler: implementation and evaluation, in: WCMSS’2013 Proceedings of the World Congress on Multimedia and Computer Science, Hammamet, Tunisia, 2013a. F. Pana, F. Put, RSVP bundle extension in OPNET modeler: implementation and evaluation, in: Modelling Symposium (EMS), 2013 European, 2013b, pp. 623–628. doi:http://dx.doi.org/10.1109/EMS.2013.104. F. Pana, F. Put, Implementing RSVP-based capacity admission in OPNET modeler, in: Proceedings of the 46th Annual Simulation Symposium, ANSS 13, SCS, San Diego, CA, USA, 2013, pp. 3:1–3:6.

F. Pana, F. Put / Simulation Modelling Practice and Theory 49 (2014) 85–97

97

[28] F. Pana, F. Put, A QoS enabled two-stage service differentiation model for the Internet, in: 6th International Conference on Signal Processing and Communication Systems (ICSPCS), 2012, pp. 1–10. [29] OPNET Technologies Inc., Opnet Modeler Documentation Set, Version: 16.0, 2010. [30] Z. Lu, H. Yang, Unlocking the Power of OPNET Modeler, Cambridge University Press, 2012. [31] J. Liu, Y. Li, On the performance of a hybrid network traffic model, Simulat. Model. Pract. Theory 16 (2008) 656–669. [32] K. Nichols, S. Blake, F. Baker, D. Black, Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers, RFC 2474 (Proposed Standard), 1998. . [33] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. Weiss, An Architecture for Differentiated Service, RFC 2475 (Informational), 1998. . [34] F. Baker, J. Polk, M. Dolly, A Differentiated Services Code Point (DSCP) for Capacity-Admitted Traffic, RFC (Proposed Standard), 2010. . [35] I. Sebuktekin, J. Haluska, D. Chee, J. Giacopelli, Y.-Z. Lee, K. Adams, J. Pulliam, Aggregate RSVP implementation experience and performance analysis for applicability in tactical IP networks, in: Military Communications Conference, 2008, MILCOM 2008, IEEE, 2008, pp. 1–7. [36] R. Prior, S. Sargento, P. Brandao, S. Crisóstomo, Performance evaluation of the RSVP reservation aggregation model, in: High Speed Networks and Multimedia Communications, Springer, 2004, pp. 167–178. [37] Riverbed Technology, The Riverbed Splash Community, OPNET Modeler Space, the RSVP Refresh Reduction Extensions, 2013. .