routing over ip (trip) performance evaluation of telephony

University of Kansas

Performance Evaluation of Telephony Routing over IP (TRIP)

Matthew C. SchlesenerMaster’s Thesis Defense

November 25, 2002

Defense Committee:Dr. Victor Frost (Chair)Dr. Joseph EvansDr. Gary Minden

University of Kansas2

Presentation Organization� Introduction�Background�TRIP Research Issues�TRIP Model Description�TRIP Simulation Results & Conclusions� Summary of Conclusions�Next Steps�Acknowledgements�Questions


Introduction� Telephony Routing over IP (TRIP) is new signaling protocol

being developed for use in an IP network.

� The most basic function of TRIP is to locate the optimum gateway out of a Voice over IP (VoIP) network into the Public Switched Telephone Network (PSTN).

� Thesis investigation will center on the impact of varying physical characteristics of a TRIP-enabled system such as traffic load and network topologies via changes in propagation delay.


Background�Control Signaling:

� Exchange of messages related to call setup, monitoring, teardown, and network management information.

� Provides command and control infrastructure for communications networks.

� Signaling System 7� Predominant control signaling network for PSTN.� Signaling Point: use signaling to transmit and receive control

information .� Signaling Link: interconnect signaling points.� Signaling Transfer Point: transfer signaling messages from one link to

another.� Signaling Control Point: database for SS7 network.


Background� SS7 Network

� Figure from: International Engineering Consortium, http://www.iec.org/online/tutorials/ip_in/topic01.html, 2002

User A

User C

User B


Background� Signal Transport (SigTran)

� Developed to allow VoIP networks to utilize the extensive functionality and superior performance of SS7.

� Interworks VoIP network with SS7/PSTN� SS7 packets are encapsulated in IP packets by Signaling GW

and sent to Media GW Controller which makes routing decisions.

� Media stream (voice) is encapsulated in IP packets by Media GW.


Background�Resource ReSerVation Protocol (RSVP)

� Designed to provide integrated services across the Internet.� Host requests service with very specific connection parameters from

the network. � Network routers along the specified path will each be requested for

dedicated resources (e.g., bandwidth).� If all nodes along the path dedicate the resources, the reservation is

complete and the host may begin use.

RVSP Request

RVSP Request

RVSP Request

RVSP Request


Background�Voice over IP (VoIP)

� A network that transmits voice packets over IP.� Voice signal is digitized, compressed and converted to IP

packets.� Specialized signaling protocols are used to set up and tear

down calls, carry information required to locate users and negotiate capabilities.

� Examples are H.323 and SIP.


Background� Session Initiation Protocol (SIP)

� VoIP signaling protocol.� Begins, changes and terminates network sessions.� Provides advanced signaling and control to an IP network.� User Agent: end users of the SIP network that initiate requests and are

the destination of services offered across the SIP network.� Registrar: manage user agents assigned to their network domain.� Proxy Server: forward SIP requests and responses.� Redirect Server: take SIP requests and return location information of

another user agent or server.� Location Server: locates the next-hop for an incoming session request.� Also, media GW and signaling GW for interworking with PSTN.


Background� SIP Network

Proxy/Registrar/Redirect ServicesLocation Server

ENTERPRISE IPNETWORK

PRIIP IP

1 2 3

4 5 67 8 9

* 8 #

PSTN/SS7

Signaling/Media GWSignaling/Media GW

IP Network

PRI

SIP SIP

1 2 3

4 5 67 8 9

* 8 #

IP

SIP

SIP PhoneUser Agent

Soft PhoneUser Agent

SIP

SIP

SIPIP

IP

Dashed Lines areSignaling links

User A


TRIP� The most basic function of TRIP is to locate the optimum

gateway out of a Voice over IP (VoIP) network into the Public Switched Telephone Network (PSTN).

� TRIP is a voice routing protocol that is independent of the underlying VoIP signaling protocol.

� Common TRIP implementations use either SIP or H.323.� Benefits of a TRIP-enabled Network

� Reachable routes must be manually provisioned in the GW only.� Location server has knowledge of dynamic state of gateway

resources.� Dynamic routing which provides the optimum path for session

routing.


Location Server (LS)� Exchanges route table information with other location

servers.� TRIP builds a routing table for the LS it supports. � The LS will utilize that routing table to make session request

forwarding decisions.� Call requests can be rerouted between location servers based

on dynamic state of gateway resources.� A location server running TRIP is referred to as a TRIP

speaker.


TRIP-lite (TRIP-GW)� TRIP-lite advertises route

and prefix destinations to at least one location server.

� Attributes advertised include destination prefixes, capacity to each prefix destination, dynamic utilization of each trunk group.

� TRIP-lite allows the LS to have real-time knowledge of available GW resources.

P R I

P S T N /S S 7

L it e

P R I

L S

P R I

T R IP - l i teM e s s a g in g

L i t e

L i te

S IP P r o x y

G W 1

G W 2

G W 3

P r e f ix 9 1 3 & 8 1 6P r e f ix 9 1 3


I-TRIP� Interior Administrative

Domain Routing (I-TRIP)� I-TRIP exchanges GW

location and routing information insidethe locally administered domain(ITAD).

� I-TRIP database update messaging is flooded to all LS’s throughout the ITAD, based on OSPF.

Lite

LS

SIP Proxy

TRIP UpdateFlooding

ITAD

PRI

SS7/PSTN

Lite

Lite

LS

PRI

PRI

LS

Lite

PRI

TRIP-liteMessaging

TRIP-liteMessaging

SIP Proxy

SIP Proxy


E-TRIP�Exterior Administrative Domain Routing (E-TRIP)�E-TRIP exchanges telephony routing information

between administrative domains. �Based on

BGP.

LS

Lite

Lite

LS

SIP Proxy

SIP Proxy

LSLS

Lite

Lite

SIP ProxySIP Proxy

I-TRIPI-TRIP

E-TRIP

ITAD BITAD A

TRIP-litemessaging

PRI PSTNPRI

TRIP-litemessaging


TRIP Research Issues� What is the impact of LS-to-GW and LS-to-LS propagation

delay on blocking probability in a TRIP environment?� The importance of this issue to a carrier concerns deployment of

location servers to support the network. Determining propagation delay impact on call blocking will allow designers to place the fewest number of LS to support demand in a given geographic area.

� What is the impact of LS-to-GW and LS-to-LS delay on call request delivery in a TRIP environment?� The importance of this issue to a carrier concerns quality of service

provided to customers. Determining where delay will be incurred will allow designers to meet delay budget.


TRIP Research Issues� What is the impact of LS-to-GW and LS-to-LS delay on

location server call request rerouting in a TRIP environment?� The importance of this issue to a carrier concerns call setup.

Determining the impact of call reroutes on call setup delay impacts the delay budget.

� What is the impact of traffic intensity along with LS-to-GW and LS-to-LS delay variation in a TRIP environment?� The importance of this issue to a carrier is to understand how the

network will react under varying load conditions. A network designer would be able to design the network to a specific load.


TRIP Research Issues�What is the impact of trunk failure along with LS-to-

GW delay and LS-to-LS delay variation on blocking probability in a TRIP environment?� The importance to a carrier is to understand how a failure will impact

customers.

�How does the system blocking performance of a TRIP network differ from the blocking performance of a SIP network?� The importance to a carrier is to understand how the addition of TRIP

will affect a SIP network. The addition of TRIP will add complexity and cost over a SIP network. This experiment will show the benefits.


TRIP Model�TRIP research questions to be addressed through

simulation.

�Model developed to evaluate each research issue.

�Model developed using Extend graphical modeling software.

�Model will simulate appropriate number of events (call requests) to provide a 99% confidence interval.


TRIP Model Description�TRIP Model Architecture:

� Two Location Server & Gateway Pairs� Each LS/GW pair has a dedicated call request generator� LS1 only sends calls to GW1 and LS2 only sends calls to GW2� GW1 has 48 DS-0 to destination prefix� GW2 has 24 DS-0 to destination prefix� Each LS is running TRIP� Each GW is running the TRIP-lite Client� TRIP-lite messaging is sent only when GW is at full trunk utilization.

This is the worst case-scenario. � Varying network topology via element-to-element propagation delay.


TRIP Model Description

PSTN/SS7

1 2 34 5 67 8 9

* 8 #

LS1 Call Generator

1 2 34 5 67 8 9

* 8 #

LS2 Call Generator

Lite

GW2

Lite

GW1

LS

LS1

LS

LS2

LS to LS CallRequest Rerouting

48 Trunks to PSTN

24 Trunks to PSTN

TRIP-lite UpdateMessaging

TRIP-lite UpdateMessaging

Generates TrafficLoad of 1% Call

Blocking

GeneratesVariableTraffic

Load which varies CallBlocking

LS-to-LS Delay LS-to-LS Delay

LS-to-GW Delay

LS-to-GW Delay

LS-to-GW Delay

LS-to-GW Delay


TRIP Model Description� Variable System

Parameters� LS-to-GW Propagation Delay� LS-to-LS Propagation Delay� Traffic Load� Gateway Trunk Failure

� System Performance Metrics� Overall System Call Blocking� LS Call Blocking� GW Call Blocking� Call Request Delivery Delay� Percentage Call Request

Rerouting between Location Servers

� Cumulative Blocked Calls during Gateway Trunk Failure


TRIP Simulation Results� System Parameters:

�Varied traffic loads ranging from 1% to 85% call blocking.

�LS-to-GW and LS-to-LS propagation delay was varied.�Delay values included:

�~0ms: elements co-located�24ms: cross country fiber connection�250ms: satellite link.

�GW trunk failure.


-33.86005 2468.962 4971.783 7474.605 9977.427 12480.25 14983.07 17485.89 19988.71 22491.53 24994.36 27497.18 30000-2.3315e-15

0.6717197

1.343439

2.015159

2.686879

3.358599

4.030318

4.702038

5.373758

6.045477

6.717197

7.388917

8.060637

8.732356

9.404076

10.0758

10.74752

11.41924

12.09095

12.76267

13.43439

14.10611

14.77783

15.44955

16.12127

16.79299

17.46471

18.13643

18.80815

Time

ValuePlotter, DE Multisim

Product 0 Product 1 Product 2 Product 3

TRIP Simulation Results� Impact of propagation delay and load variation on Call Blocking.� Results for system call blocking vs. time, 5% call blocking, LS-to-GW

delay variation, Blue: 0ms; Red: 24ms; Green: 250ms.

5%

Steady State tends to Erlang B Prediction of 5% Call Blocking


TRIP Simulation Results� System call blocking is driven by traffic load.� System call blocking follows Erlang B prediction.� Propagation delay and thus network topology does not impact system call

blocking performance.

System Call Blocking %LS to GW Delay

0102030405060708090

57.95 66.65 79.55 108.05 204.15 478.80

Traffic Intensity (Erlang)

Blo

ckin

g (%

)

0ms3.43ms6.86ms10.29ms13.72ms17.15ms20.58ms24.01ms125ms250msErlang B


TRIP Simulation Results� For low LS-to-GW delay, LS call blocking follows Erlang B predictions.� For high delay (satellite link), blocking shifts from LS to GW.

� LS-to-LS delay variation does not cause blocking shift from LS to GW.

GW Call Blocking %LS to GW Delay

0

2

4

6

8

10

12

14

16

57.95 66.65 79.55 108.05 204.15 478.80

Traffic Intensity (Erlang)B

lock

ing

(%)

0ms3.43ms6.86ms10.29ms13.72ms17.15ms20.58ms24.01ms125ms250ms

LS Call Blocking %LS to GW Delay

0102030405060708090

57.95 66.65 79.55 108.05 204.15 478.80


Blo

ckin

g (%

)



TRIP Simulation Results� Impact of propagation delay and load variation on call request rerouting.� Call request rerouting is driven by traffic load.� The higher the traffic load the great percentage of reroutes.� Propagation delay and thus network topology does not impact the

percentage of call request reroutes.

Percent Call Request RerouteLS to GW Delay

0

5

10

15

20

25

30

35

40

57.95 66.65 79.55 108.05 204.15 478.80


Rer

oute

% (%

)


Percent Call Request RerouteLS to LS Delay

0

5

10

15

20

25

30

35

40

57.95 66.65 79.55 108.05 204.15 478.80


Rer

oute

% (%

)



TRIP Simulation Results� Impact of propagation delay and load variation on Call Request Delivery

to a GW.� LS-to-GW propagation delay will add directly to the call delivery delay.� The percentage of LS-to-LS delay added to total call delivery delay is

based on traffic load and call request rerouting.� Overall call delivery delay is the sum of both.

Call Request Delivery DelayLS to GW Delay

0

50

100

150

200

250

300

57.95 66.65 79.55 108.05 204.15 478.80


Cal

l Req

uest

Del

iver

yD

elay

(ms)


Call Request Delivery DelayLS to LS Delay

0

20

40

60

80

100

120

140

57.95 66.65 79.55 108.05 204.15 478.80


Cal

l Req

uest

Del

iver

yD

elay

(ms)



TRIP Simulation Results� The relationship between call request rerouting and LS-to-LS

delay can be illustrated by this predictive expression.

� At 24ms LS-to-LS propagation delay there are 4.3% calls rerouted and incur both the 24ms LS-to-LS delay plus the constant 4ms LS-to-GW delay.

� Subsequently, 95.7% of call requests do not get rerouted and only incur the 4ms LS-to-GW delay.

� Call Delivery Delay = 0.043*[24ms + 4ms] + 0.957*[4ms] = 5.032ms� The predicted value through simulation is 5.634ms. Thus the delivery

delay can be predicted given the simulated call request reroute percentage.


TRIP Simulation Results� Comparison of a TRIP-enabled Network to a SIP Network.� SIP call blocking is consistently higher than TRIP. � Given standard traffic assumptions Erlang B cannot be used to predict call

blocking in a SIP network.

System Call Blocking %LS to GW Delay

0102030405060708090

100

57.95 66.65 79.55 108.05 204.15 478.80


Blo

ckin

g (%

)

0ms3.43ms6.86ms10.29ms13.72ms17.15ms20.58ms24.01ms125ms250msSIPErlang B


TRIP Model Demonstration� Demonstration of TRIP model simulating trunk failure on

GW1. 1% call blocking prior to failure.� At 50,000 seconds, GW1 suffers a T1 failure. This drops the

available trunks on GW1 from 48 to 24. Overall system resources drop from 72 DS-0 to 48.

� After failure, Erlang B predicts blocking of 22.1%.� At 125,000 seconds, restoral of failed trunk and 1% call

blocking. � At 200,000 seconds, simulation ends.


TRIP Simulation Results� Gateway trunk failure results� Cumulative number of blocked calls versus time.

0 12500 25000 37500 50000 62500 75000 87500 100000 112500 125000 137500 150000 162500 175000 187500 2000001

153.125

305.25

457.375

609.5

761.625

913.75

1065.875

1218

1370.125

1522.25

1674.375

1826.5

1978.625

2130.75

2282.875

2435

2587.125

2739.25

2891.375

3043.5

3195.625

3347.75

3499.875

3652

3804.125

3956.25

4108.375

4260.5

4412.625

4564.75

4716.875

4869

5021.125

5173.25

5325.375

5477.5

5629.625

5781.75

5933.875

6086

Time

ValuePlotter, DE Multisim

NumberExited 0 NumberExited 1 NumberExited 2 NumberExited 3

Failure

Restoral

time (seconds)

Blo

cked

Cal

ls


� TRIP results during trunk failure with varied propagation delay.

� LS-to-LS results also show propagation delay has no impact.

TRIP Simulation Results

Delay Location

Delay (ms)

Interval Average Slope (blocked/sec)

Calculated Call Blocking

(%)

Erlang B (%)

LS-to-GW 0ms Before Failure

0.00347 1.08% 1.0%

LS-to-GW 0ms After Failure 0.07013 21.8% 22.1%

LS-to-GW 0ms After Restoral 0.00378 1.2% 1.0%


0.00331 1.03% 1.0%




0.00352 1.09% 1.0%




TRIP Simulation Results• System reaction to a state change is dependent on traffic

load.• As the traffic load is increased, the system reaction time

to the state change will decrease.• For a 1% call blocking, the TRIP system will react to the

state change in approximately 3.1-9.3 second.• 15% in 2.3-6.9 second & 85% in 0.38-1.14 second.• Propagation delay during a failure scenario does not

impact the system reaction to new state.


TRIP Conclusions� Network topology does not impact system blocking

probability. In a TRIP-enabled network, the system blocking will be driven by traffic load.� This result impacts geographic deployment of location servers to

support the network. From a system blocking standpoint, designers do not need to be concerned with propagation delay but must be concerned with traffic load.

� Overall system blocking will follow Erlang B given specified values for traffic load and call holding time. � This result allows designers to implement a correctly sized TRIP

network based on forecasted customer usage. This would impact number of trunks to support a given destination prefix, number of gateways in a geographic area, and number location servers in the network.


TRIP Conclusions� As LS-to-GW delay is increased towards a satellite link delay

(250ms), loss of knowledge about the current state of the system causes call blocking to increase at the GW. � This result places a limit on implementation options. TRIP messaging

can incur propagation delay equivalent to cross country fiber links but satellite links should not be considered.

� Propagation delay, LS-to-GW and LS-to-LS, does not impact the percentage of reroutes in the system. The traffic intensityis the driving factor. � This result dictates that designers be concerned with traffic load and

not propagation delay when addressing TRIP rerouting functionality.


TRIP Conclusions� LS-to-GW propagation delay will add directly to the call

delivery delay. For LS-to-LS delay only a percentage of the propagation delay will add into the total call delivery delay. And that amount will be dependent upon the traffic load. � This issue impacts the delay budget. The result indicates that any delay

between the LS and GW must be added to overall call setup delay. While, only a percentage of the delay between LS and LS should be added.

� SIP blocking is consistently higher than TRIP and higher than what would be predicted by Erlang B.� TRIP provides a SIP network with lower blocking. It benefits the carrier with

less provisioning, gateway dynamic resource information available at the proxy, optimum path routing, and also better blocking performance.


TRIP Conclusions� The time required for a TRIP system to react to a change in

state (i.e., gateway trunk failure) is based on traffic load. As the traffic load is increased, the system reaction time to the state change will decrease. Additionally, the results show that propagation delay during a failure scenario does not impact the system reaction to new state.� When a failure happens the TRIP network will react within a

reasonable time interval and tend toward the new steady state.


Next Steps� Simulation of TRIP-lite network with added update

messaging. � Simulation of TRIP network synchronization (TRIP Routing

Convergence).� Lab evaluation of Vendor TRIP-lite equipment and software.� Lab evaluation of Vendor Interior Administrative Domain

Routing (I-TRIP) equipment and software.� Lab evaluation of Vendor Exterior Administrative Domain

Routing (E-TRIP) equipment and software.� Lab evaluation of a TRIP network with all TRIP entities.


Acknowledgements

�Special Thanks to:�Dr. Victor Frost�Dr. Joseph Evans�Dr. Gary Minden�The Cisco TRIP Marketing and Development

Team�And Very Special Thanks to Sprint, Network

Services Executive Management.


Questions

routing over ip (trip) performance evaluation of telephony

Documents