7 Narration & Description. Narration & Description Background.
Description
-
Upload
eancrimicri -
Category
Documents
-
view
218 -
download
2
description
Transcript of Description
-
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