Building an MPLS-TP Simulator

Vishal Negi, Umang Kumar, Tulika Pandey, Ashwin Gumaste

Dept. of Computer Science and Engineering, Indian Institute of Technology, Bombay, Mumbai, India 400076.
Ministry of Communication and Information Technology, New Delhi 110,003.
Email: {vishalng, umang}@cse.iitb.ac.in, [email protected]

Abstract: Service providers are experiencing a

challenge that is caused by the explosive growth in
demand for high-speed connections to and across
metropolitan, regional and core networks. Operators are
under pressure to increase the capacity of their networks
to meet these ever growing requirements. To improve
service agility and network efficiency and reduce costs
throughout their entire infrastructures, providers are
evaluating ways to use packet transport everywhere.
Carrier Ethernet is a new mechanism that is being
proposed to consolidate the packet optical transport Fig. 1. Major Constructs: Pseudowires and LSPs.
network. Multiprotocol Label Switching-Transport Profile
(MPLS-TP) – a variant of Carrier Ethernet offers a MPLS-TP transport paths are statically provisioned
potentially important addition within the packet transport via a Network Management System (NMS) or can be
toolset. Operations, Administration, and Maintenance dynamically provisioned through a distributed control
(OAM) functionality is central to this new standard. This plane. The control plane is mainly used to provide
helps service creation and assurance thus providing an restoration functions for improved network survivability
extension to packet transport capabilities within emerging in the presence of failures and it facilitates end-to-end
multi-layer infrastructure architectures. This paper aims path provisioning across network or operator domains.
at exploring the performance of MPLS-TP network using The operator has the choice to enable the control plane or
an extensive simulation model. to operate the network by means of an NMS.
In MPLS-TP ELINE services are set up as LSPs that
facilitate Ethernet transport using the MPLS forwarding
I. Introduction plane. Rather than use an automated control plane and
the IP based control plane, the MPLS-TP implementation
Carrier Ethernet is being proposed as the next works with an independent control plane that is
generation of data transport for operator networks. Two completely disassociated from the forwarding plane.
variants of Carrier Ethernet are being considered – from MPLS-TP further allows creation of service attributes that
the IEEE the 802.1Qay or PBB-TE and from the facilitate the operator to identify a service instance, as
ITU/IETF the MPLS-Transport Profile or MPLS-TP. The well as protect, restore the monitor the service instance.
Multiprotocol Label Switching − Transport Profile (MPLS- Shown in Fig. 1 is an example of MPLS-TP providing a
TP)[1-3] is a packet transport technology based on a service to customer edges CE1 and CE2 via the provider
subset of MPLS features [1] with additional transport edge LSRs (PE1 and PE2). The LSP created between the
functionalities such as comprehensive Operations, provider edges is considered as a service instance, and a
Administration and Maintenance (OAM)[5] capabilities, control plane called the Generic Associated Channel (an
restoration and survivability, data-plane/control-plane in-band control plane) is used to set up service identifiers,
separation, and static provisioning of bidirectional and perform OAM features. MPLS-TP traffic can be
services, all of which makes MPLS-TP a carrier class provisioned over LSPs, or over pseudo-wires (PW) or over
solution. The rich installed base of MPLS and the key Multi-Segment-Pseudo-Wires (MS-PWs).
MPLS functionalities such as Quality of Service (QoS),
scalability, traffic engineering and Layer 2 packet A. MPLS-TP OAM
forwarding give MPLS-TP a head-start with operators. MPLS-TP OAM [6, 9] is intended to reduce network
The result is the ability to provide network operators with operations complexity associated with network
full control over their packet networks meeting the performance monitoring and management, fault
demands of next generation services at unmatched price- management, and protection switching. These are
points – especially when considered against SONET/SDH required to operate without any IP layer functions.
transport. MPLS-TP is somewhat backward compatible Dedicated OAM packets are interspersed into the
with MPLS, thus giving operators an excellent associated user traffic flows. These OAM packets are
user/customer base that is already accustomed to created and processed by Maintenance End Point (MEPs).
provisioning such a technology in their networks. MPLS- MEPs are service end-points that define an MPLS-TP
TP allows the operator more control and monitoring tunnel ingress and egress nodes. In addition to MEPs that
facilities – both of which are quintessential to meeting the generate and sink OAM packets, Maintenance
demands of a carrier-class network. Further, from the Intermediate Points or MIPs can also process these OAM
perspective of end-to-end communication, MPLS-TP, packets and may collect data or raise alarms. The OAM
meets the user requirements at the edge, aggregation and features are as shown in Fig. 2.
core of the network, thus finding way to solve most Two important components of the OAM mechanisms
customer requirements. are the G-ACh and the Generic Alert Label (GAL). They
allow an operator to send any type of control traffic into a and Label operations (Push, Pop, or Swap) at each MPLS-
PW or an LSP. In the context of transport networks, ACH TP node. The strategy used for Label distribution in our
was generalized to enable the same associated control simulator is based on a variant of Downstream on
channel mechanism to be used for Sections, LSPs, and Demand. We argue that using downstream unsolicited
PWs. The associated control channel, thus generalized is strategies would make the network non-carrier-class.
known as Generic Associated Channel (G-ACh)[4]. Quality-of-Service (QoS) mechanisms are required in
the packet transport network to ensure the prioritization
of critical services. A transport network must provide the
means to meet the QoS objectives of its clients. The
simulator provides 8 priority levels and performs WFQ
scheduling to achieve this objective.
The above service guarantees depend on reliable and
efficient operation of a Transport Network. Thus MPLS-
TP requires OAM mechanism to monitor the integrity of
the transport paths and provide other network monitoring
and management features. Generic Associated Channel
(G-Ach) is used to carry OAM traffic and distinguish it
Fig. 2. LSP monitoring using OAM flows from normal data traffic thereby providing a full in-band
control plane. The simulator implementation provides in-
This generic function is capable of carrying user band OAM that shares fate with client traffic. Proactive
traffic, OAM traffic, and management traffic over either a Continuity Check Messages (CCM) are provided to
PW or an LSP. Using G-ACh, the same OAM mechanism monitor the integrity of the transport path. The CCMs
can be unified for LSPs and PWE, enabling the same generate triggers in case of failures or congestion. These
functionality for both and ease of implementation. triggers are then used to provide 1:1 restoration along the
Protection path using Automatic Protection Switching.

II. MPLS-TP Simulator A. Simulation Methodology

The simulator simulates the behavior of an MPLS-TP
Given the interests that operators have shown in network if the native service traversing the network is a
deploying MPLS-TP, we need tools that facilitate the MS-PW [7]. The simulation model assumes the presence of
statistical analysis of the MPLS-TP domains and their T-PEs and S-PEs in a MPLS-TP network. The T-PE is at
components as well as study their characteristics. A the Customer Edge (CE) of the network and sources or
simulator will hence allow us to evaluate the performance sinks customer traffic to or from an MPLS-TP network.
of an MPLS-TP network without the need to setup an The TPEs also act as Label Edge Routers (LERs) and
actual MPLS-TP network. What is intrinsic to such a provide as endpoints for LSPs and MS-PWs. These are
simulator is the carrier-class MPLS-TP LSR architecture also responsible for Label Distribution and Proactive
that facilitates the provisioning of MPLS-TP tunnels in a Pseudowire monitoring. The S-PEs are capable of
network. switching the tunnels of preceding and succeeding
The goal of this simulator is to model an MPLS-TP segments of a MS-PW [7].
node and to understand the behavior of MPLS-TP network The architecture of the MPLS-TP node used for the
under different traffic conditions. The simulator is purpose of simulation is described in Fig. 3. Each
implemented in C++ on a Linux platform. It provides individual block in the architecture represents a module
features that setup Label Switched Paths (LSPs) between and performs some functions. A node can be a T-PE or an
various pairs of nodes based on a traffic connection S-PE, depending on its role in the MPLS-TP network.
(adjacency) matrix. These LSPs are Co-routed The traffic arrival at each T-PE is modeled as a
bidirectional transport paths traversing an MPLS-TP Poisson process. After a packet arrives at a node, it goes
domain. The nodes that provide interface to an MPLS-TP through a series of functions, before it is sent back into the
network are called Terminating-Provider Edges (or T- network towards the next hop. This process continues at
PEs). every node, until the packet reaches its final destination
To emulate a service, a PW is setup between the CEs or is dropped in the process.
and data is transported on an MPLS-TP LSP. Switching- When the packet arrives at a node, it first goes
Provider Edges (or S-PEs) in the network allow for through the Edge Port Logic. This module is responsible
simulating the MS-PW. The MS-PW is thus the client of for frame classification, lookup and forwarding logic. It
underlying MPLS-TP service layer. The connection matrix also is also responsible for requesting the Memory Write
allows for setting up the transport paths based on Open Controller to store the frame in the Memory. Once the
Shortest Path First (OSPF) routing. forwarding decisions are made, the packet is forwarded to
Customer traffic is first encapsulated within the the Switch Fabric. The Switch Fabric then forwards the
transport-service layer network by the T-PE and then packet to appropriate Output port. At this point, the
forwarded along the appropriate transport path. The Output Port Logic is performed. At an individual output
requirement for MPLS-TP specifies that it must not port, the packet is placed at the appropriate Priority
modify the MPLS forwarding architecture and must be Queue based on the priority of packet.
based on existing PW and LSP constructs, thus facilitating A WFQ scheduler is responsible for serving the
good backward compatibility with MPLS/PW definitions. Priority Queues and aggregates the resultant frames. A
Therefore the MPLS-TP forwarding is based on the Labels request is then placed to the Memory Read Controller to
read the appropriate frames from the Memory. Once the The Forwarding Logic then performs LSP label pop,
frame is removed from the memory, processing is done on PW label swap and then LSP label push on the packet
the frame before it is forwarded to the output interface to header. From NHLFE, it identifies which output port the
be sent back into the network towards its intended
packet is destined to and forwards the packet header to
destination. The delay experienced by the packet at a node
is the summation of all the delays in each of the individual Switching Fabric.
modules.
C. Switching Fabric
The Switch Fabric forwards the packet header from
the input port to appropriate output port. An arbiter
iterates over each input port and forwards the available
frame to the destination port. The headers are put in the
output queue at the output port.

D. Output Port Logic

This module is described in Fig. 5. When the packet
header arrives at Output port, Output Port Logic begins.
The header is placed in the appropriate Priority Queue
according to the class of service defined for the packet.
Each priority queue is assigned a weight. A Weighted Fair
Queuing Scheduler empties each priority queues in
proportion to the weight assigned to the queue. Thus
Fig. 3. Node Architecture. available bandwidth is divided among the queues in ratio
of their weights.
B. Edge Port Logic The scheduler then places the available headers into a
This module is described in Fig. 4. It is implemented packet aggregator. The aggregator then places a request to
at the input port. For the purpose of simulation, an input Memory Read Controller to read the corresponding frames
port queue is maintained. A packet is stored in the queue, from the Memory. Now the entire packets read from the
until the previous packet is completely received. However, memory are forwarded for UNI-NNI processing.
for an individual packet, processing starts as soon as the The UNI-NNI logic as its counterpart in the Edge port
first bit arrives. Simultaneously, a request is placed to the logic performs link layer specific post processing and
Memory Write Controller to store the packet into Memory. associates an appropriate data link encapsulation with the
Since the packet will be stored in Memory, to reduce packet. The packet is then forwarded to output interface,
packet delay, all the processing hence forth is done on the from where it is sent out in the MPLS-TP network towards
packet header. With the arrival of the first byte, UNI/NNI its intended destination.
processing begins.
The UNI-NNI Logic is responsible for frame
classification, link layer specific preprocessing and
identification of Traffic Service Instance and client flow.
After this step, if the packet is a data packet, the packet
header is stored in Look-up Queue. If the packet is an
OAM packet, it is forwarded to Automatic Protection
Switching (APS) Manager.

Fig. 5. Output Port Logic.

E. Automatic Protection Switch (APS)

Manager
APS manager is responsible for OAM mechanisms
needed for fault detection, diagnostics, maintenance, and
Fig. 4. Edge Port Logic other functions on a PW and LSP. It is an important
component that is required for the 50 ms restoration time
The Look-Up module then looks up Incoming Label in event of failure. The T-PEs for a MS-PW form the
Map (ILM) and FEC-To-NHLFE (FTN) table to extract Maintenance End Points (MEPs). The intermediate S-PEs
Next-hop Label forwarding entries (NHLFE). The packet in the Transport path form the Maintenance Intermediate
header is then forwarded to Forwarding Logic. Points (MIPs). Proactive OAM monitoring is done for
checking the integrity and status of the transport path.
 The simulator implements this by the means of CCM
packets and G-ACh. The G-ACh acts as a container or
channel that runs on the PW and carries OAM messages.
The MEPs generate In-band CCM packets. These CCM
packets share fate with the data-packets. The MIPs do not
generate OAM packets. They simply forward these packets
towards their destination MEPs. A MEP sends 3
successive CCM packets towards other MEP of the
Transport path. The MPLS-TP OAM requirement specifies
an interval of 3.3 ms between successive CCM packets.
The MEP destined as receiver has a Hold-off timer. If the
3 packets are not received when the timer expires, a
trigger is raised indicating the Path-Failure. The
Transport path is then switched to the Protection path,
until the Primary work path is restored again.
To section in the simulator config file can be used to
simulate Path-Failures. The elements of this section Fig. 6. Topology
specify which link to fail and at what time.
A. Load vs. Delay
F. Network Topology and Traffic generation Average packet delay as a function of load, for packet
The Network topology is built using the Adjacency sizes 64-100, 801-900 and 1401-1500 is shown in Fig. 7. It
Matrix in the config file. A section in the config file is observed that there is a steep rise in average packet
specifies what nodes are the S-PEs. Rest all nodes are delays for 70% traffic load and above.
designated as T-PEs.
The Traffic Matrix specifies how much traffic is to be
2.50E-02
generated between the specified nodes. Such nodes are T-
PEs. The granularity of the links between nodes is 2.00E-02 Packet Size(in Bytes)
specified by Granularity Matrix. The Traffic generation 64-100
module models the packet arrival at each T-PE as a 1.50E-02
801-900
Poisson process, while being considerate about the 1.00E-02 1401-1500
constraints specified by Traffic and Granularity Matrices.
For every Transport path in the network, a Protection 5.00E-03
path (1:1) is also provisioned. These paths are generated
0.00E+00
by modifying the Adjacency Matrix and using Dijkstra’s
0 20 40 60 80 100
algorithm to compute the shortest path on the modified
matrix. Fig. 7. Load vs. Delay (different packet sizes)

For various priorities also, it is observed that the

III. Simulation Results delay increases with the traffic load and there is a steep
rise in delay for traffic load of 70% and above. This is
Using the simulation model described in the previous shown is Fig. 8.
section, simulation was performed to evaluate the 2.50E-02

behavior and performance of MPLS-TP under various

traffic loads for various packet sizes and priorities (class of 2.00E-02

traffic). The topology used for performing simulations is Packet Priorities

shown in Fig. 6. The Traffic and Granularity matrices in 1.50E-02

0
1

the config file were used to specify the T-PE pairs amongst 2
3

which the LSPs will be setup. The LSPs for this 1.00E-02
4
5

experiment are all co-routed bidirectional LSPs. It should 6

be noted that the packet arrival at each T-PE is modeled 5.00E-03

as a Poisson process.
The implementation of simulator provides for 8 0.00E+00
0 10 20 30 40 50 60 70 80 90 100

priorities (classes of traffic). The lowest priority is 0 and Fig. 8. Load vs. Delay (for different priorities)
the highest being 8. The highest priority is used for OAM.
The simulation experiment was run for a simulation
B. Load vs. Jitter
period of 1 second for each traffic load (10% to 90%). For
Jitter is calculated as the average of the difference in
each traffic load, the following metrics were measured:
the latencies of the packets at each node, i.e.
1. Load vs. Delay (for various packet sizes)
Diffn = | Laencyn - Latencyn-1 | , where, n is the current
2. Load vs. Jitter (for various packet sizes)
packet.
3. Load vs. Delay (for various priorities)
Thus Jitter is given by
4. Load vs. Jitter (for various priorities)
Jitter = ∑ Diffn/( n – 1), where n is the total number of
a. Load vs. Throughput/Packet Drop
packets.
 It is observed that jitter as a function of traffic load using IP/MPLS and MPLS-TP, service providers will have
depicts a saw-tooth pattern as shown in Fig. 9. This is a consistent way of provisioning, troubleshooting, and
because of router introducing alternate latencies because managing their networks from edge to edge.
of packets being queued in different priority queues. The simulator simulates the behavior of an MPLS-TP
network, when the native service used is MS-PW. The
1.00E+00
0 20 40 60 80 100
results benchmark important metrics as a function of
1.00E-02 traffic load, for various packet sizes and priorities.
1.00E-04 Packet Size
64-100
1.00E-06
101-200
V. References:
1.00E-08 201-300
301-400 [1]RFC 3031: Multiprotocol Label Switching Architecture
1.00E-10
[2]RFC 5317: Joint Working Team (JWT) Report on
1.00E-12
MPLS Architectural Considerations for a Transport
1.00E-14
Profile
Fig. 9. Load vs. jitter (for various packet sizes) [3]RFC 5654: Requirements of an MPLS Transport Profile
[4]RFC 5586: MPLS Generic Associated Channel
A similar pattern can also be observed for various
priorities as shown in Fig. 10. [5]RFC 5860 Requirements for OAM in MPLS
Transport Networks
1.00E+00 [6]RFC 5921: A Framework for MPLS in Transport
Networks
0 20 40 60 80 100
1.00E-02

1.00E-04
Packet Priorities
0 [7]RFC 5659: An architecture for Multi-Segment
1.00E-06
1
2 Pseudowire Emulation Edge-to-Edge
3
4 [8]RFC 5960: MPLS Transport Profile Data Plane
1.00E-08
5
6
Architecture
1.00E-10
[9]RFC 6371: Operations, Administration, and
1.00E-12
Maintenance Framework for MPLS-Based Transport
1.00E-14 Networks
Fig. 10. Load vs. Jitter (for various priorities).

C. Load vs. Throughput/Packet-Drop

Based on the previous two results, it can be easily
concluded that, as the packet delay increases with
increase in load, the packet drop must also happen. The
results corroborate this fact. For traffic loads of 70% and
above, packets start dropping. This is shown in Fig. 11.

120

100

80

60 THROUGHPUT
DROP

40

20

0
0 10 20 30 40 50 60 70 80 90 100

Fig. 11. Load vs. Throughput/Packet Drop

IV. Conclusion

MPLS-TP represents a new development in the larger

MPLS protocol suite. MPLS-TP based packet transport
networks take advantage of the cost-effectiveness and
ease-of-use of pseudo wire over IP/MPLS architecture,
and carefully preserves the OAM and management
characteristics of legacy transport networks. Major
advantages are consistent operations and OAM
functions across the different network layers and the
seamless interworking with IP/MPLS networks. By