A. Archive Description

The following elements are included in the present archive:

1. A document: Description.pdf illustrates the extensions that are included in the present archive 2. An OPNET Archive: RSVP Refresh Overhead Reduction.ocfpa includes all the process models and

necessary dependencies files in order to run the models and the included scenarios

3. A folder: f.pana includes the header files (of the rsvp_sr model) that are necessary if the model has to be recompiled.

B. Model Description

The following extensions are included in the archive:

I. The process model included in this archive: rsvp_sr represents an extension of the original rsvp process model of OPNET modeler:

1) This new process model includes the RSVP Refresh Overhead Reduction Extensions as presented in RFC 2961:

i. RSVP Bundle Extension; ii. Partial implementation of the RSVP Message ID extension for support of the Summary

Refresh Extension;

iii. RSVP Summary Refresh Extension.

2) Improvements of the original rsvp process model :

i. Less memory leaks; ii. Correct initialization of the path state generation;

C. Files in the OPCFA Archive

The files that are included in the opcfa archive are all the files that are necessary (all the dependencies necessary to

run the included scenarios)

Three new node models are included in the archive :

- Device Name: wkstn_eth_adv_rsvp_sr_fpana / end node

- Device Name: router_CS_7500_adv_RSVP_sr_fpana_adv / backbone router

- Device Name: router_CS_4500_adv_RSVP_sr_fpana_adv / distribution router

All the extensions associated with the functionalities of the rsvp_sr process model are included in these models.

D. Detailed Model Description

1.i. The RSVP Bundle Extension:

- New attributes are included in the rsvp_sr process model for each interface under Refresh Message Configuration

and Refresh Reduction :

- Status (enable/disable) it is used to specify if that interface will use the RSVP Bundle extension or not - Max RSVP Bundle Size specifies how big is the RSVP Bundle message allowed to be on that interface

- Max RSVP Bundle Hold Time- specifies the maximum time a message is allowed to be kept in order to

be bundled

- In this implementation:

- only the RSVP Refresh messages are bundled (Resv and Path)

- a bundle message is created only when a message is received so as to be bundled for a particular interface

and no bundle message exists on that interface. In other words irrespective of the period of time that passed

from when the last bundle message was sent, a new bundle message is created only when a RSVP resfresh

message needs to be bundled.

- the implementation is done only for RSVP unicast communications (multicast is not fully supported for

the RSVP Bundle Extension)

- New statistics are introduced:

- Packets per bundle message sent captures the number of packets sent in bundle message by a node - Total RSVP traffic sent (bytes) this statistic illustrates each RSVP message sent by the process model at

a certain time (horizontal axis) and having a certain size (vertical axis)

1.ii The Message ID extension + 1.iii The Summary Refresh extension

- New attributes are included in the rsvp_sr process model for each interface, under the Refresh Message

Configuration and Refresh Reduction:

- Summary Refresh (enabled/disabled) it is used to specify if that interface will use the RSVP Summary Refresh or not

- Summary Msg size (in bytes)- specifies how big is the RSVP Srefresh message allowed to be on that

interface

In this implementation:

-The functionality of the Epoch and Ack_desired flag are not considered (they exist so as to have correct

message sizes)

- The Message ID extension is implemented only for Resv and Path messages

- The acknowledgment objects of the Message ID extension (ACK and NACK) and the Ack Message are

not implemented

- The implementation is done only for unicast RSVP reservations (nu multicast support)

- A distinction is made between ID objects designed for the Resv state block and ID for the Path state block

(they have a different format, for PSB n0 (the last digit is 0) and for RSB m1(the last digit is 1)) - The Srefresh messages of a node are sent according to the node refresh sequence (this is done as for the

normal rsvp process model, but instead of sending Resv and Path messages Srefresh messages are sent)

- The time parameters sent in the trigger RSVP messages are stored now in the associated state so as to

allow that state to be refreshed according to the refresh timer of the neighboring node

The statistic introduced earlier for the Bundle extension can be used here - Total RSVP traffic sent (bytes)

For debugging and validation purposes we modify also the function (rsvp_pstate_print and rsvp_rstate_print) that

are used to print the content of the PSB and RSB of a particular node so as to illustrate also the value of IDs

associated with different states. These functions can be used when running OPNET simulation in the Development

Mode.

E. OPNET(opcfa) Scenarios descriptions

Open the scenarios from the expanded archive

Select File->Open (from the directory where you expanded the archive) select Refresh Overhead Reduction (project)

You are now in the Refresh overhead Reduction Project - in the SRefresh RSVP Scenario.

There are 4 different scenarios included in this project:

1. No RSVP a scenario where RSVP is not used for reservations of voice communication

2. Simple RSVP in this scenario the basic version of RSVP is used (RFC 2205 and RFC 2210)

3. Bundle RSVP in this scenario the Bundle extension of RSVP is used (RFC 2961)

4. SRefresh RSVP this scenario uses the Summary Refresh (with a partial implementation of the ID extension ) (RFC 2961)

The scenarios can be seen in:

Scenarios->Manage Scenarios

View Results

All the results (statistics) of the four scenarios are included in the archive.

Press with the mouse (right button) on a free space(where there is no object) in the main window (the window that shows the network topology)

A window appears that can present different statistics of the Simulation

Click on the drop box from the upper left (Current Scenario) and select Current Project (this will enable the statistics from all the 4 scenarios )

o Click now on each of the scenarios to make the statistics available : No RSVP Simple RSVP Bundle RSVP SRefresh RSVP

Select now the statistics to be displayed:

From the Object Statistics (Left side):

o Select: Router Core-> RSVP Now we see all the statistics that are associated with the RSVP process for the node (Router Core)

in the center of the topology

Obs: not all the statistics that are available here are relevant for all the simulation scenarios.

For example: The packets per Bundle statistic sent will show only one graph in the right part of

the screen, because this statistic is used only for the Bundle extension. However the Number of

Path states statistics will open 4 graphs on the right part of the screen, corresponding to all of the

scenarios.

Another statistic that can be interesting for all of the four scenarios is the Total RSVP traffic sent

(bytes). This statistic displays in bytes the traffic sent by the RSVP module of a node.

Every point presented by the statistic represents the size (in bytes) of a RSVP message sent by the

node at a certain time.

Obs: If the node sends many messages of the same size at exactly the same moment in time, then

this will be displayed by the statistic as only one dot (actually there are many dots which are

overlapping because the messages are sent at exactly the same time ). However the statistic can

represent also this information. If we change the presentation (right hand side of the screen bellow

the graphs) from As is to Sample Sum the total size of the messages sent by RSVP is displayed.

For example if we select only the Simple RSVP and Srefresh scenarios, and we look at this

statistic (changing the Presentation to Overlaid Statistics/As Is) it will appear that the Srefresh

extension is consuming more bandwidth than the simple RSVP implementation. However if we

change the presentation to Sample-Sum we can clearly see the total traffic sent by the RSVP module in the two scenarios.

Running Simulations

All of the compiled code is already included in the ofpca archive so all the simulation can be Run.

This will allow for each scenario to change different parameters in the network (modify topology/add traffic/

increase decrease simulation time/ add or subtract statistics. )

Select Scenarios->Manage Scenarios o For each scenario (row) select under the Results Column /or (for the Srefresh

scenario )

o Press Ok This will trigger simulation runs for all of the simulation scenarios with a default period of time preselected

for 1 hour.

If we want to modify the code (add or subtract functionalities), we will have to recompile the source code

Recompile Source Code

Copy the f.pana folder in the C:\Program Files\OPNET\16.0.A\models\std\include folder or equivalent (the folder where all the header files are stored) OR copy the folder f.pana (not only the content but the actual

folder) in the folder where you have uncompressed the opcfa archive.

The ideea is that the modified files have declared in the header include directives of the form

#include "f.pana/rsvp_sr.h"

So the f.pana folder should be included in a file that appears in the model directories attribute of OPNET (but not included

directly!!!)

Restart OPNET MODELER

Reopen the Refresh overhead Reduction Project

Select File-> Manage Model Files->Refresh Model Directories

The simulation will now be able to recompile the source code.

Select a scenario:

Scenarios ->Switch to Scenario->Srefresh RSVP

Reconfigure the simulation to recompile code:

DES->Configure/Run Discrete Event Simulation o (Left Side) expand Execution-Advanced- Compilation

Select from the right:

Force model recompilation

Press Run