Overview of the RSVP-TE Network Simulator: Design and ...

Overview of the RSVP-TE Network Simulator: Design and Implementation
D. Adami, C. Callegari, S. Giordano, F. Mustacchio, M. Pagano, F. Vitucci
Dept. of Information Engineering, University of Pisa, ITALY
E-mail: davide.adami@cnit.it,{christian.callegari, s.giordano,
fabio.mustacchio, m.pagano, fabio.vitucci}@iet.unipi.it
Abstract
In a multi-service IP network, it is a key challenge to
provide Quality of Service (QoS) to end-user applications
while effectively using network resources. In the last
years, the DiffServ architecture has emerged as a
scalable solution to provide QoS in IP networks, but, in
order to optimize the use of transmission resources, this
architecture must be complemented with efficient Traffic
Engineering (TE) mechanisms. The MultiProtocol Label
Switching (MPLS) technology is a suitable method to
provide TE. The integrated use of MPLS and DiffServ is a
hot topic in next generation networks. In such context, a
full comprehensive simulation environment could be
useful to speed up the design and the validation of new
functionalities. In particular, a key issue towards the
effective deployment of DiffServ/MPLS networks is
represented by the enhancement in the MPLS
architecture signalling protocol. In this paper, the design
and the development of a new software module to
simulate the RSVP-TE protocol in the Network Simulator
2 (NS2) is presented.
1. Introduction
The explosive growth of the Internet and the
convergence of communication services, such as IP
telephony or VoIP, to IP-based networks, brought to life
new issues in the design of next generation networks.
These issues strictly depend on the side in which the
interaction users–network is observed.
From the user perspective, end-to-end Quality of
Service (QoS) should be provided to fulfil multimedia
applications requirements. The basic QoS requirements
are the dynamism (e.g. the service should last as long as
the user needs), the tailoring (e.g. the network resources
allocated for the service should exactly fulfil the end-user
1
requirements) and a seamless integration (e.g. the
mechanisms involved in QoS support should be
transparent to end-users applications).
From the Service Providers perspective, requirements
concern the operative traffic engineering (TE)
functionalities so as to manage in an optimized way the
available resources and to assure service survivability,
even in case of faults or dynamic network topology
changes.
IP networks, designed to provide a best-effort service
according to a connectionless approach, are not able to
meet these requirements. Hence, in the last years, many
research efforts have been focused on the development of
enhanced network architectures to address and solve
these issues [1][2][3].
The combined use of the Differentiated Services
(DiffServ) [4] and MultiProtocol Label Switching
(MPLS) [5] architectures seems to be an attractive
solution to provide guaranteed QoS for multimedia traffic
while effectively using network resources.
Some MPLS architectural features, which make it
appealing to support QoS and TE [6][7][8]
functionalities, are the following:
• separation of control and forwarding planes,
which assures scalability;
• constraint-based routing and explicit path
forwarding, which allow an effective
management of the available resources;
• recovery mechanisms, which guarantee service
survivability in case of faults.
However, as MPLS by itself cannot provide service
differentiation, there is the need to complement it with
another technology capable of providing such a feature.
The DiffServ architecture emerges as a scalable and
effective solution to address this issue [9].

Since a framework has been defined to integrate
MPLS and DiffServ technologies [10], this is an open
research field and improved mechanisms towards a fully
deployment of required functionalities have to be tested.
In this scenario a simulation environment is useful to
perform a functional assessment of the proposed
approaches and to compare different solutions, reducing
the complexity and the time needed to develop prototypal
network devices.
Unfortunately, a full comprehensive simulation
environment for MPLS/DiffServ networks has not been
developed yet. Therefore, our activity has been devoted to
the implementation of software modules that allow the
simulation of such a scenario. The starting point for our
implementation is represented by the Network Simulator
version 2.26 (NS2) [11], along with the MPLS Network
Simulator version 2 (MNS) [12][13] and RSVP Network
Simulator (RSVP\ns) modules [14][15].
The focus of the paper is on the implementation of a
RSVP-TE protocol module, named RSVP-TE\ns, to be
used as label distribution protocol in MNS. Indeed,
RSVP-TE is the most commonly implemented signalling
protocol in commercial routers and several research
activities, as well as IETF working groups [16][17],
address the issues related to the extensions of this
protocol to support enhanced functionalities in
MPLS/DiffServ networks. Moreover, several
experimental test-beds, equipped both with Linux
platforms and commercial routers, adopt this solution
[18][19].
The paper is organized as follows. Section 2 describes
the MPLS node architecture in the NS2 environment,
with emphasis on the RSVP-TE control plane
characteristics. Section 3 discusses our implementation of
the RSVP-TE\ns module along with the LSP management
functionalities available in the simulator. Section 4
provides a description of the tests performed for a
functional validation of the developed module. Section 5
concludes the paper with some final remarks.
2. MPLS node architecture
The basic idea behind MPLS is to append a short
fixed-length label to packets at the ingress router of an
MPLS domain. Packet forwarding is then based on the
assigned label and not on longest prefix address
matching, as in traditional IP forwarding mechanisms.
When a packet is received by an edge router of the MPLS
domain, named Label Edge Router (LER), it is associated
to a label on the basis of a Forwarding Equivalence Class
(FEC). The packets associated to the same label traverse
the MPLS network along the same path, identified as
Label-Switched Path (LSP). Interior routers that perform
label switching and label-based packet forwarding are
called Label Switching Routers (LSRs).
2
In order to establish, maintain and tear-down LSPs a
signalling protocol, such as the Label Distribution
Protocol (LDP) or the RSVP-TE protocol, has to be used.
An LDP implementation is integrated in the NS2 MNS
module. Since RSVP-TE is widely deployed in
experimental and working MPLS networks and several
research activities are focused on enhancing such a
protocol in an MPLS/DiffServ scenario, we decided to
replace the CR-LDP signalling protocol module with our
own implemented RSVP-TE\ns module. The reference
model of an MPLS node is sketched in figure 1.
Note that in the MNS implementation a strict
distinction between control plane and forwarding
functionalities can be found. Such a feature reflects the
separation between control and data planes in the MPLS
architecture. For this reason, our work concerns only
control plane mechanisms.
RSVP-TE
Messages
Routing
Information
Packets
IN
Control Plane
Data Plane
Routing Protocol
Address Classifier
Resource
Manager
RSVP-TE
MPLS Classifier Service Classifier
Label
Info
Base
Explicite
Route
Base
Admission
Control
Packet Scheduler
Packets
OUT
Figure 1. Reference model of an MPLS node
In particular, in our simulator environment, labels
distribution and allocation are performed by the RSVP-TE
agent we implemented. The agent supports downstream
on demand label allocation and upstream distribution.
The RSVP-TE agent receives the labels by the
downstream LSRs and passes them to the MPLS
classifier, so that it can create the tables used for label
switching.
The data plane operations are the following: at first,
when a packet is received by an LSR, the MPLS classifier
checks if the packet is labelled. If the packet has a label
or may be associated to an FEC, the MPLS classifier
executes label-based forwarding, otherwise it transfers
the packet to the address classifier which forwards it
according to the Layer 3 routing protocol.
To perform label switching, an MPLS node in the
MNS implementation handles three tables:
• the Label Information Base (LIB), whose entries
contain incoming label, incoming interface,
outgoing label and outgoing interface;

• the Partial Forwarding Table (PFT), which
contains a subset of the information written in
the LIB;
• the Explicit Route information Base (ERB),
which contains information about the Explicit-
Route LSP (ER-LSP).
More in detail, when a labelled packet is received by
an LSR, the node retrieves the incoming label, then a
table look up is performed to find the corresponding entry
in the LIB. At this point, the LSR may execute two
different operations. If it is an egress LER, it removes the
label from the packet and then forwards it according to
the Layer 3 routing protocol, passing it to the address
classifier. Instead, if it is an LSR, it replaces the incoming
label with the outgoing one (Label Swapping) and then
performs label-based forwarding.
If the packet has to be forwarded on an explicit path,
the MPLS node also uses the ERB, which is managed by
the service classifier to map a flow into an ER-LSP.
The PFT is used in packet forwarding only by the
ingress LER. In this case, the node receives an unlabelled
packet and uses the PFT to associate a label to the packet
itself, which is then forwarded according to label
switching mechanisms.
The RSVP-TE agent we added in the MPLS node is
able to perform two additional procedures: the Label
Stacking and the Penultimate Hop Popping. The first one,
which consists in managing multiple labels in a packet, is
used to create a level of hierarchy in large networks,
improving traffic flows scalability. Instead, Penultimate
Hop Popping is used to simplify the operations executed
on a labelled packet by the egress LER. This means that
the penultimate LSR of the LSP executes label popping,
instead of label swapping. Then it forwards an unlabelled
packet towards the egress LER. To enable such a feature,
the LIB contains additional information about the
operation the node has to execute for a specific LSP.
Path Messages
LIB
ERB
MPLS Node
Link
Admission
Control
Policing
RSVP-TE
Resource
Manager
Packet Scheduler WFQ
Resv Messages
Figure 2. Resource reservation process
3
In order to support QoS, the developed module is also
able to perform resource reservation for the LSP itself.
The RSVP-TE agent is responsible for this action too.
The resource reservation process, shown in figure 2, can
be summarized as follows. When a Path message is
received at the ingress interface of the LSR, the RSVP-
TE agent performs Admission control and Policing
functions. If there are enough available resources it
forwards the Path message to the downstream LSR.
After Admission control and Policing operations have
been performed all along the LSP, a Resv message is
generated and forwarded upstream along the LSP. An
LSR, when processing a Resv message, allocates
resources and calls the resource manager to properly
configure the queues in the packet scheduler. The
scheduler used with the RSVP-TE module is the
Weighted Fair Queuing (WFQ), which is already
implemented in NS2. Moreover, the RSVP-TE agent calls
the MPLS classifier to create the corresponding entries in
the LIB and PFT tables used for label switching.
3. RSVP-TE\ns module
In this section, we illustrate the main functionalities of
the developed module. RSVP-TE\ns has been
implemented in compliance with the standard defined in
[20].
The simulator functionalities can be divided in two
distinct sets:
• the first one (see section 3.1) concerns LSPs
establishment;
• the second one (see section 3.2) is about LSPs
tear-down.
3.1. LSP Establishment
Two different commands may be used to establish an
LSP: the first one is used when the ingress LER wants to
establish an ER-LSP, while the second one is used when
it wants to create an ER-LSP with a reserved bandwidth.
create-erlsp-rsvpte
create-erbwlsp-rsvpte
In both cases, the Path message sent by the ingress
LER contains, in addition to the classical RSVP objects, a
LABEL_REQUEST object, used for requesting to the
downstream nodes the allocation of the labels.
The simulator allows to create an LSP that follows an
explicit path by specifying in the option a sequence

of nodes addresses. This field, if not empty, is used to
create an EXPLICIT_ROUTE_OBJECT (ERO), which is
added to the Path message.
When an LSR receives a Path message, it performs
several operations; the first ones are related to admission
control and policing. Then the node processes the ERO: it
inserts the ERO contents in its Path State Block (PSB)
and then it looks for the next abstract node, to forward the
Path message to. The insertion of the ERO value in the
PSB is needed in order to assure that Resv messages
follow, in the upstream direction, the same route of the
Path ones. Once the egress LER has received and
processed the Path message, it generates a Resv message
that contains, in the LABEL object, the label value to be
used by the upstream node.
When an LSR receives the Resv message, the node
sets a new label value to be suggested to the upstream
node. Moreover, if the issued command is for an ER-LSP
with bandwidth reservation, the LSR calls the Resource
manager which, in turn, executes the resource allocation
Subsequently, it passes the label contained in the Resv
message (outgoing label) and the new label (incoming
label) to the MPLS classifier, which uses them to create
the corresponding entry in the label switching tables.
Finally, the LSR generates a Resv message, with a
LABEL object containing the value of the suggested
label, and forwards it to the previous node as stored in the
PSB.
When the ingress LER processes the Resv message the
LSP is established. Another command may be used to
bind a flow to the LSP.
3.2. LSP Tear down
The second set of functionalities allows to tear down
an LSP when a failure occurs. The following command
drives the simulation of a link failure
break-link
The following subsequent actions, related to the
handling of this event, are automatically performed:
• the link between the
and the fails;
• the rsvp-agent of the
sends, for each LSP that is established on the
broken link, a PathErr message upstream, so as
to notify the ingress LER of the failure;
• the rsvp-agent of the
sends, for each LSP that is established on the
broken link, a ResvErr message downstream, so
as to notify the egress LSR of the failure;
4
• the egress LSR, after processing each ResvErr
message, sends to the
a ResvTear message, in order to release the
previously allocated resources;
• the ingress LER, after processing each PathErr
message, sends to the a
PathTear message, in order to release the
previously allocated resources;
• the ingress LER delete the corresponding entry
in the LIB, PFT and ERB tables.
After these operations, all the flows bound to an LSP
that has been torn down are forwarded according to a
Layer 3 routing protocol. This allows applying different
rerouting techniques.
4. Functional validation tests
In this section we present some of the tests carried out
to validate the new functionalities added to the simulator.
The network topology (figure 3) is quite simple, but
appropriate to highlight the most important functionalities
of RSVP-TE\ns.
0
2
2
0
2
3
10
0
2
1
9
1
11
0
1
Figure 3: Network topology
In this network scenario, nodes 3-11 are MPLSenabled,
whereas nodes 0, 1 and 2 act as traffic sources,
that send a data traffic stream to the nodes 12, 13 and 14
respectively. Moreover, the bandwidth assigned to each
link is 1 Mbps.
In figures 3-9, the packets belonging to each flow are
identified by the source node number.
The first test is performed to verify the resources
allocation mechanism along an LSP.
A Constant Bit Rate (CBR) data traffic at 400 Kbps is
generated by the node 2 and received by the node 14; the
links 11_4 and 4_5 are congested due to the traffic
generated by the nodes 0 and 1.
According to the Layer 3 routing protocol (OSPF) all
the flows are forwarded along the same path, so that each
flow experiments packet losses on the congested links.
8
0
4
2
1
7
5
1
0
6
12
2
13
14

Indeed, as shown in figure 4, the throughput of the
flow 2 is about 200 Kbps when no LSP is established. An
LSP is then set-up (t=46 sec) with a reserved bandwidth
equal to 400 Kbps, between the nodes 10 and 5. The
binding of the flow to the LSP is completed at 50.0
seconds and the throughput rises at 400 Kbps as a
consequence of a proper resource allocation process.
Figure 4: Flow rate (src 2) on link 4_5
The second test is performed to assess label
distribution and fault recovery functionalities. The
network topology is the same as in the previous test and
all the sources generate CBR traffic at 400Kbps.
After 5.0 seconds of simulation, three ER-LSP are
established:
• LSP0 includes nodes 3, 10, 9, 8, 7, 6, 5 and it is
associated to flow 0;
• LSP1 includes nodes 11, 4, 5 and it is associated
to flow 1;
• LSP2 includes nodes 3, 10, 9, 8, 7, 5 and it is
associated to flow 2.
0
2
2
0
3
2
10
2
1
0
9
1
11
2 0
Path Message
1
Figure 5: Path message for flow from 2 to 14
8
2
4
0
7
1
5
2
6
0
1
12
13
14
5
In figure 5 the Path message for the ER-LSP
establishment through 3, 10, 9, 8, 7, 6, 5 nodes is shown.
At 8.0 seconds the binding of the flows to the LSP is
completed and the flows are forwarded according to label
switching (figure 6).
The subsequent phase aims at testing the fault
notification mechanisms. In order to test this aspect, a
fault is forced on the link 7_5, so that node 7 sends a
PathErr message (figure 7).
0 0
0
2
2
2
2
0
2
3
3
10
0
0
0
10
0
2
1
0
9
11
0
Figure 6: Label switching
2
1
1
1
2
1
1
11
0 2 0
9
Figure 7: Failure and PathErr message
After receiving the PathErr message, node 10 sends a
PathTear message downstream to release the previously
allocated resources and to delete the label switching table
entries associated to the LSP. As a consequence, flow
from node 2 to node 14 is now forwarded according to
the Layer 3 routing protocol, as shown in figure 8.
Figure 9 shows the throughput at node 14.
From t = 15 seconds to t = 15.6 seconds, no packet is
received. Then, traffic flows are forwarded according to
Layer 3 routing protocol. No decrease in the received
throughput can be observed, since no congestion occurs
along the new path.
8
8
2
4
1
4
2
1
0
0
7
7
2
5
0
0
1
5
2
0
0
1
6
6
0
PathErr Message
0
2
12
13
14
1
13
12
14

0
2
2
0
3
2
10
Figure 8: Situation after link failure
Figure 9: Flow rate (src 2) on link 5_14
Finally, we assess the simulator behaviour, when a
link, on which several LSPs are established, fails. In order
to test this aspect, a link failure is forced on link 6_7. As
supposed, nodes 7 and 5 send respectively a PathErr and
a ResvErr message. After processing the corresponding
PathTear and ResvTear messages, the two LSPs (which
are established on the broken link) are released and the
corresponding flows are, once again, forwarded
according to the Layer 3 routing protocol.
5. Conclusions
0
1
0
1
11
2
9
0
1
In this paper, we discuss the development and validate
the functionalities of a new software module that
implements the RSVP-TE signalling protocol in the NS2
simulation tool. The new module provides a complete
implementation of the control plane mechanisms needed
for label distribution and label binding as well as link
failure handling in MPLS networks. It is relevant to
emphasize that this module has been developed taking
into account extensibility and flexibility issues, so that
enhancements to the signalling protocol (i.e. definition of
new objects) could be easily introduced. Hence, the
8
2
4
0
7
1
2
5
0
0
6
0
1
12
13
14
6
module we implemented could be useful to plan and
assess new functionalities in MPLS/DiffServ or GMPLS
networks.
6. Acknowledgments
This work was partially supported by the Euro-NGI
Network of Excellence funded by the European
Commission
References
[1] X. Xiao, L.M. Ni, Internet QoS: A Big Picture, IEEE Network
Magazine, March 1999
[2] Trimintzios, P. Andrikopoulos, I. Pavlou, G. Flegkas, P. Griffin, D.
Georgatsos, P. Goderis, D. T'Joens, Y. Georgiadis, L. Jacquenet,
C.; Egan, R., A management and control architecture for providing
IP Differentiated Services in MPLS-based Networks, IEEE
Communications Magazine, May 2001
[3] Engel, T. Granzer, H. Koch, B.F. Winter, M. Sampatakos, P.;
Venieris, I.S. Hussmann, H. Ricciato, F. Salsano, S., AQUILA:
Adaptive resource control for QoS using an IP-based layered
architecture, IEEE Communications Magazine, January 2003
[4] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. Weiss.,
An Architecture for Differentiated Services, IETF RFC 2475,
December 1998
[5] E. Rosen, A. Viswanathan, R. Callon., Multiprotocol Label
Switching Architecture, IETF RFC 3031, January 2001
[6] D. Awduche, J. Malcolm, J. Agogbua, M. O'Dell, J. McManus.,
Requirements for Traffic Engineering over MPLS, IETF RFC 2702,
September 1999
[7] G. Swallow MPLS Advantages for Traffic Engineering, IEEE
Communications Magazine, December 1999
[8] X. Xiao, A. Hannan, B. Bailey, L. Ni, Traffic engineering with
MPLS in the Internet, IEEE Network Magazine, March 2000.
[9] B. Carpenter, K. Nichols Differentiated Services in the Internet,
Proceedings of the IEEE, September 2002
[10] F. Le Faucheur, L. Wu, B. Davie, S. Davari, P. Vaananen, R.
Krishnan, P. Cheval, J. Heinanen, MPLS support of Differentiated
Services, IETF RFC 3270, May 2002
[11] The Network Simulator vers.2.26 (NS2) Home Page
www.isi.edu/nsnam/dist/
[12] The MPLS Network Simulator version 2 Home Page
http://flower.ce.cnu.ac.kr/~fog1/mns/
[13] G. Ahn, W. Chun Design and Implementation of MPLS Network
Simulator (MNS) Supporting QoS, ICOIN- 2001
[14] The RSVP module for NS2 Home Page http://titan.cs.unibonn.de/~greis/rsvpns
index.html
[15] M. Greis RSVP\ns: An Implementation of RSVP for the Network
Simulator ns-2
[16] IETF MPLS WG http://www.ietf.org/html.charters/mplscharter.html
[17] IETF CCAMP Working Group
http://www.ietf.org/html.charters/ccamp-charter.html
[18] G. Carrozzo, N. Ciulli, S. Giordano, G. Giorgi, M. Listanti, U.
Monaco, F. Mustacchio, G. Procissi, F. Ricciato,. Architecture and
protocols for the seamless and integrated next generation IP
networks, QoS-IP 2005
[19] D. Adami, N. Carlotti, S. Giordano, M. Pagano, M. Repeti,
Performance analysis of the Control and Forwarding plane in a
MPLS router, OpNeTec 2004
[20] D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, G. Swallowl.
RSVP-TE: Extensions to RSVP for LSP Tunnels, IETF RFC 3209,
December 2001