Optimization of Network Redundant 
Technologies Collaboration 
in IMS Carrier Topology
Filip Burda, Peter Havrila, Marián Knězek, Klaudia Konôpková
Ivan Kotuliak, Ján Murányi, Juraj Nemeček
Faculty of Informatics and Information Technologies
Slovak University of Technology in Bratislava
Contents
Motivation
Proposed Solution
Test-bed setup
Performance results
Motivation for optimized route selection

In the latest generation of mobile networks, the quality of service and load-balancing could be native to the whole network, but IP networks are routed in the shortest path first manner 

This approach creates limitations on the ability of these networks to utilize the bandwidth of routes other than those declared as shortest paths to the destination

When underestimated, this fundamental principle can have detrimental effects on end-to-end quality






Conclusion
Traffic Engineering is manipulation of traffic in order for it to fit the network

Proposed Solution
All links are OC-3 links with the bandwidth roughly 150 Mbit/s
R1 sends 90 Mbit/s of data to the router R6 and router R7 sends another 80 Mbit/s to router R6

In the classical shortest path first manner, R2 has link to R5 as next hop towards R6
This will simply result in congestion on the link between routers R2 and R5 and obviously, alternative link through the path R2-R3-R4-R6 remains under full utilization



Possibility of using Traffic Engineering is by manipulating costs
This results in costs equilibrating of all alternative paths and then load-balance between these paths
Proposed Solution


Focus on MPLS Traffic Engineering (TE) technology and its usability in the IMS environment
IP SLA
Cisco specific function for supporting monitoring of specific parameters

Can monitor different constraints of the node, link or path from the routers and taking appropriate actions and informing administrator through SNMP protocol

IP SLA currently monitors various types of delay, jitter, RTT, number of dropped packets, latency, etc.

Cisco specific feature 
Objects:

Object Tracking
IP SLA object
Status of an interface
Status of IP address
Presence of the destination network in the forwarding table
Metric of the path
Composite objects can be created, where other objects are put together through boolean logic or threshold system
One TE tunnel on the router R1 is placed across routers R3, R5 and R7 
Second TE tunnel from R1 through R4, R6 to the R8 
Primary tunnels are placed among “upper” routers (R1,R3, R5, R7)
On the exit points - External Border Gateway Protocol (eBGP) is configured
One of the customers is located behind the left exit point and one behind the right exit point
 These TE tunnels are created across the whole network, from the one exit point to the other exit
point.
Test-bed setup
Primary TE tunnel is placed statically 
Primary and secondary TE tunnel are learned via dynamic routing protocol, in our case via IS-IS
The static primary TE tunnel is tracked by an object
All the traffic destined for the networks behind the other exit point is going through this static TE tunnel

After conditions are met, tracked object goes down, which leads to removing this static route from the routing table
After removing this static route, the same dynamically learned primary TE tunnel and also  the secondary TE tunnel are placed into forwarding table
The traffic is now load balanced

The first measurement: without our solution
For our measurements, the network traffic will enter only the router R1 and is destined to the exit point behind the routers R7 and R8 . One of the customers is located behind the left exit point and one behind the right exit point

After initiating calls, the bandwidth utilization is rising, which leads to increased Round Trip Time (RTT). Because of 128 kbit/s link between routers, only one call can be established with no quality penalty 

After initiating the second call, increased RTT, jitter and also packet loss is observed

Both calls have equally penalized quality
The second measurement: with our solution

IP SLA objects - RTT and average jitter

First IP SLA object 1 - icmp-echo type of packet with the Type Of Service (TOS) decimal value of 184, which is the decimal representation of EF class

Threshold - 20 ms

Frequency of sending these packets and controlling the quality of the link - one second 



Second IP SLA object 2 -  configured in the same way as the IP SLA object 1

Threshold - 4 ms

Reaction - average jitter with the upper threshold of 4 ms and lower threshold of 3 ms


If threshold limits are exceeded, immediate action is taken. Each and every IP SLA object is mapped to its own unique object in Object Tracking (1 and 2). 

One composite tracked object is created with the boolean logic, designated as object 3. If any object is down, the whole composite object is down. This composite object is used for the static route configuration.

Tracked objects 1 and 2 are delayed. If they are not delayed and if one of the IP SLA object fail their test, immediate action is taken. 

We are delaying the “down” and the “up” state three times the frequency of IP SLA object, which is 3 seconds. If three times in a row the test fails, tracked object is considered to be down. The same rule applies for the “up” state.
The second measurement: with our solution
The second measurement:with solution
Performance results
Tunnel setup in test-bed
Tunnel setup in test-bed
Configuration:
Configuration:
RTP behavior with and without pro-active backup MPLS TE tunnel utilization
First call - TE tunnel bandwidth was sufficient for exactly this one call as indicated by acceptable RTT and Jitter characteristics for 128 kbit/s A/S interfaces
Performance results
RTP behavior with and without pro-active backup MPLS TE tunnel utilization
Second call - RTT measurements started to constantly rise. After 4 seconds of both calls in place, call quality deteriorated beyond acceptable threshold 

Performance results
RTP behavior with and without pro-active backup MPLS TE tunnel utilization
With our optimization - network was able to detect degrading call quality and dynamically  switch traffic patterns in Traffic Engineering manner to adapt rising demands for network throughput

Our optimization system needed roughly 4 seconds, to detect, propagate, compute, and update routing forwarding information base for rising throughput demands via load sharing TE tunnels. Consequently, after roughly 4 seconds, our system was able to dynamically achieve sustained acceptable call quality
Comparison of the RTT evolution in time for system with and without IP SLA
For half a second interval after 4th second, RTT is in a great variation after applying our configuration. During this time, out of sequence packets are arriving, causing these values “jumping” from the upper to the normal  RTT level. These packets were discarded by the VoIP clients. Clients were able to communicate after the 4.5 seconds with its expected quality. Without IP SLA, RTT was constantly rising up to the 2000 ms
Using Traffic Engineering to solve this fundamental problem
Conclusion
We have proposed innovative solution:
to find suboptimal bandwidth utilization automatically, 
without requirement of the network administrator involvement

We have demonstrated:
IP SLA with the Object Tracking can be effectively combined with the other technologies like MPLS TE
After link failure or link overload, it can reroute traffic in fully automated way to alternative routes

Thank you for your attention
{filip.burda,phavrila,marian.knezek,konopielka,
jan.muranyi,juraj.nemecek}@gmail.com
Ivan.Kotuliak@stuba.sk