Performance Evaluation of Telephony Routing over IP (TRIP)

Performance Evaluation of Telephony Routing over IP (TRIP) Matthew C. Schlesener Master s Thesis Defense November 25, 2002 Defense Committee: Dr. Victor Frost (Chair) Dr. Joseph Evans Dr. Gary Minden

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

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. 3

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. 4

Background SS7 Network User B User A User C Figure from: International Engineering Consortium, http://www.iec.org/online/tutorials/ip_in/topic01.html, 2002 5

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. 6

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 7

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. 8

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. 9

1 2 3 4 5 6 7 8 9 * 8 # 1 2 3 4 5 6 7 8 9 * 8 # Background SIP Network Proxy/Registrar/Redirect Services Location Server Signaling/Media GW Signaling/Media GW SIP SIP IP IP PRI SIP PRI IP Network PSTN/SS7 SIP IP IP SIP ENTERPRISE IP NETWORK SIP IP SIP Phone User Agent User A Soft Phone User Agent Dashed Lines are Signaling links 10

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. 11

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. 12

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. GW1 Lite Prefix 913 PRI GW2 LS Lite PRI PSTN/SS7 SIP Proxy T R IP -lite Messaging PRI Lite GW3 Prefix 913 & 816 13

I-TRIP Interior Administrative Domain Routing (I-TRIP) I-TRIP exchanges GW location and routing information inside the locally administered domain (ITAD). I-TRIP database update Lite PRI messaging is flooded to all LS s throughout the ITAD, based on OSPF. LS TRIP-lite Messaging Lite PRI SS7/PSTN SIP Proxy ITAD TRIP Update Flooding PRI Lite LS SIP Proxy PRI LS SIP Proxy Lite TRIP-lite Messaging 14

E-TRIP Exterior Administrative Domain Routing (E-TRIP) E-TRIP exchanges telephony routing information between administrative domains. ITAD A ITAD B Based on E-TRIP SIP Proxy BGP. SIP Proxy SIP Proxy TRIP-lite messaging Lite Lite LS I-TRIP LS SIP Proxy LS I-TRIP LS TRIP-lite messaging Lite Lite PRI PSTN PRI 15

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. 16

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. 17

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. 18

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. 19

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. 20

1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 TRIP Model Description LS-to-GW Delay LS1 TRIP-lite Update Messaging * 8 # LS1 Call Generator LS LS-to-GW Delay Lite Generates VariableTraffic Load which varies Call Blocking LS to LS Call Request Rerouting GW1 48 Trunks to PSTN PSTN/SS7 LS-to-LS Delay LS-to-LS Delay Lite 24 Trunks to PSTN LS2 Call Generator LS GW2 * 8 # Generates Traffic Load of 1% Call Blocking LS2 LS-to-GW Delay TRIP-lite Update Messaging LS-to-GW Delay 21

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 22

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. 23

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. Value 18.80815 Plotter, DE Multisim 18.13643 17.46471 16.79299 16.12127 15.44955 14.77783 14.10611 13.43439 12.76267 12.09095 11.41924 10.74752 10.0758 9.404076 8.732356 Steady State tends to Erlang B Prediction of 5% Call Blocking 8.060637 5% 7.388917 6.717197 6.045477 5.373758 4.702038 4.030318 3.358599 2.686879 2.015159 1.343439 0.6717197-2.3315e-15-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 Time Product 0 Product 1 Product 2 Product 3 24

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. Blocking (%) 90 80 70 60 50 40 30 20 System Call Blocking % LS to GW Delay 0ms 3.43ms 6.86ms 10.29ms 13.72ms 17.15ms 20.58ms 10 24.01ms 0 125ms 57.95 66.65 79.55 108.05 204.15 478.80 250ms Traffic Intensity (Erlang) Erlang B 25

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. Blocking (%) 90 80 70 60 50 40 30 20 10 0 LS Call Blocking % LS to GW Delay 57.95 66.65 79.55 108.05 204.15 478.80 Traffic Intensity (Erlang) 0ms 3.43ms 6.86ms 10.29ms 13.72ms 17.15ms 20.58ms 24.01ms 125ms 250ms Blocking (%) 16 14 12 10 8 6 4 2 0 GW Call Blocking % LS to GW Delay 57.95 66.65 79.55 108.05 204.15 478.80 Traffic Intensity (Erlang) 0ms 3.43ms 6.86ms 10.29ms 13.72ms 17.15ms 20.58ms 24.01ms 125ms 250ms LS-to-LS delay variation does not cause blocking shift from LS to GW. 26

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. Reroute % (%) 40 35 30 25 20 15 10 5 0 Percent Call Request Reroute LS to GW Delay 57.95 66.65 79.55 108.05 204.15 478.80 0ms 3.43ms 6.86ms 10.29ms 13.72ms 17.15ms 20.58ms 24.01ms 125ms 250ms Reroute % (%) 40 35 30 25 20 15 10 5 0 Percent Call Request Reroute LS to LS Delay 57.95 66.65 79.55 108.05 204.15 478.80 0ms 3.43ms 6.86ms 10.29ms 13.72ms 17.15ms 20.58ms 24.01ms 125ms 250ms Traffic Intensity (Erlang) Traffic Intensity (Erlang) 27

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 Delay (ms) 300 250 200 150 100 50 0 Call Request Delivery Delay LS to GW Delay 57.95 66.65 79.55 108.05 204.15 478.80 0ms 3.43ms 6.86ms 10.29ms 13.72ms 17.15ms 20.58ms 24.01ms 125ms 250ms Call Request Delivery Delay (ms) 140 120 100 80 60 40 20 0 Call Request Delivery Delay LS to LS Delay 57.95 66.65 79.55 108.05 204.15 478.80 0ms 3.43ms 6.86ms 10.29ms 13.72ms 17.15ms 20.58ms 24.01ms 125ms 250ms Traffic Intensity (Erlang) Traffic Intensity (Erlang) 28

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. 29

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. Blocking (%) 100 90 80 70 60 50 40 30 20 10 0 System Call Blocking % LS to GW Delay 57.95 66.65 79.55 108.05 204.15 478.80 Traffic Intensity (Erlang) 0ms 3.43ms 6.86ms 10.29ms 13.72ms 17.15ms 20.58ms 24.01ms 125ms 250ms SIP Erlang B 30

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. 31

TRIP Simulation Results Gateway trunk failure results Cumulative number of blocked calls versus time. Value 6086 5933.875 5781.75 5629.625 5477.5 5325.375 Plotter, DE Multisim Blocked Calls 5173.25 5021.125 4869 4716.875 4564.75 4412.625 4260.5 4108.375 3956.25 3804.125 3652 3499.875 3347.75 3195.625 3043.5 2891.375 2739.25 2587.125 2435 2282.875 Restoral 2130.75 1978.625 1826.5 1674.375 1522.25 1370.125 Failure 1218 1065.875 913.75 761.625 609.5 457.375 305.25 153.125 1 0 12500 25000 37500 50000 62500 75000 87500 100000 112500 125000 137500 150000 162500 175000 187500 200000 Time NumberExited 0 NumberExited 1 NumberExited 2 NumberExited 3 time (seconds) 32

TRIP Simulation Results TRIP results during trunk failure with varied propagation delay. Delay Location Delay (ms) Interval LS-to-GW 0ms Before Failure Average Slope (blocked/sec) Calculated Call Blocking (%) Erlang B (%) 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% LS-to-GW 24ms Before Failure 0.00331 1.03% 1.0% LS-to-GW 24ms After Failure 0.07181 22.3% 22.1% LS-to-GW 24ms After Restoral 0.00344 1.07% 1.0% LS-to-GW 250ms Before Failure 0.00352 1.09% 1.0% LS-to-GW 250ms After Failure 0.07217 22.4% 22.1% LS-to-GW 250ms After Restoral 0.00327 1.02% 1.0% LS-to-LS results also show propagation delay has no impact. 33

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. 34

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. 35

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 intensity is the driving factor. This result dictates that designers be concerned with traffic load and not propagation delay when addressing TRIP rerouting functionality. 36

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. 37

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. 38

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. 39

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. 40

Questions 41