idnits 2.17.1 draft-ietf-sigtran-performance-req-00.txt: -(80): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(83): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(86): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(91): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(217): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == There are 19 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 9 longer pages, the longest (page 3) being 64 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 9 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 104 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force 2 INTERNET DRAFT Authors 3 Signaling Transport Working Group Huai-An P. Lin 4 June 26, 1999 Taruni Seth 5 Expires December 26, 1999 Albert Broscius 6 Christian Huitema 7 Telcordia Technologies 9 VoIP Signaling Performance Requirements and Expectations 10 12 Status of this document 14 This document is an Internet-Draft and is in full conformance with all 15 provisions of Section 10 of RFC2026. Internet-Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its areas, and 17 its working groups. Note that other groups may also distribute working 18 documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference material 23 or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 This document serves as input into the IETF SIGTRAN requirements 34 process. It includes call setup delay requirements, derived from 35 relevant ISDN and SS7 standards published by ITU-T (International 36 Telecommunications Union--Telecommunications Standardization Sector) and 37 generic requirements published by Telcordia Technologies (formerly 38 Bellcore). To gain user acceptance of Voice-over-IP (VoIP) services and 39 to enable interoperability between Switched Circuit Networks (SCNs) and 40 VoIP systems, it is imperative that the VoIP signaling performance be 41 comparable to that of the current SCNs. The requirements given in this 42 Internet Draft are intended to be the worst-case requirements, for at 43 least in United States SCN calls are typically set up far faster than 44 the derived requirements. 46 1. Introduction 48 This document serves as input into the IETF SIGTRAN requirements 49 process. It includes call setup delay requirements, derived from 50 relevant ISDN and SS7 standards published by ITU-T (International 51 Telecommunications Union--Telecommunications Standardization Sector) and 52 generic requirements published by Telcordia Technologies (formerly 53 Bellcore). To gain user acceptance of Voice-over-IP (VoIP) services and 55 to enable interoperability between Switched Circuit Networks (SCNs) and 56 VoIP systems, it is imperative that the VoIP signaling performance be 57 comparable to that of the current SCNs. The requirements given in this 58 Internet Draft are intended to be the worst-case requirements, since at 59 least in United States SCN calls are typically set up within one to two 60 seconds [1]--far faster than the derived requirements. 62 The call setup delay, also known as the post-dialing delay, in an ISDN- 63 SS7 environment is the period that starts when an ISDN user dials the 64 last digit of the called number and ends when the user receives the last 65 bit of the Alerting message. Call setup delays are not explicitly given 66 in the existing SCN performance requirements; rather, performances of 67 SCNs are typically expressed in terms of cross-switch (or cross-office) 68 transfer times. This Internet Draft uses ITU-T�s SS7 Hypothetical 69 Signaling Reference Connection (HSRC) [2], cross-STP (Signaling Transfer 70 Point) time [3], Telcordia�s switch response time generic requirements 71 [4], and a simple ISDN-SS7 call flow to derive the call setup delay 72 requirements. ITU-T�s cross-switch time requirements [5] are listed as 73 references but not used, since the ISDN timings are missing. 75 2. Hypothetical Signaling Reference Connection (HSRC) 77 HSRC is specified in ITU-T Recommendation Q.709. A HSRC is made up by a 78 set of signaling points and STPs that are connected in series by 79 signaling data links to produce a signaling connection. Recommendation 80 Q.709 distinguishes the �national� components from the �international� 81 components. A HSRC for international working consists of an 82 international component and two national components. The size of each 83 country is considered; however, the definitions of �large� and �average� 84 countries was not completely precise: 86 �When the maximum distance between an international switching center and 87 a subscriber who can be reached from it does not exceed 1000 km or, 88 exceptionally, 1500 km, and when the country has less than n � 10E7 89 subscribers, the country is considered to be of average-size. A country 90 with a larger distance between an international switching center and a 91 subscriber, or with more than n � 10E7 subscribers, is considered to be 92 of large-size. (The value of n is for further study.)� 94 Recommendation Q.709 uses a probabilistic approach to specify the number 95 of signaling points and STPs on a signaling connection. The maximum 96 number of signaling points and STPs allowed in a national component and 97 an international component are listed in Tables 1 and 2, respectively. 99 Table 1: Maximum Number of Signaling Points and STPs in a National 100 Component (Source: ITU-T Recommendation Q.709, Table 3) 102 Country size Percent of Number of Number of 103 connections STPs signaling points* 105 Large-size 50% 3 3 106 95% 4 4 108 Average-size 50% 2 2 109 95% 3 3 111 * The terms signaling points and switches are used interchangeably in 112 this Internet Draft. 114 Table 2: Maximum Number of Signaling Points and STPs in International 115 Component (Source: ITU-T Recommendation Q.709, Table 1) 117 Country size Percent of Number of Number of 118 connections STPs signaling points 120 Large-size 50% 3 3 121 to 122 Large-size 95% 4 3 124 Large-size 50% 4 4 125 to 126 Average-size 95% 5 4 128 Average-size 50% 5 5 129 to 130 Average-size 95% 7 5 132 3. Switch Response Time (aka Cross-switch Transfer Time) 134 Most of SCN performance requirements are specified in terms of switch 135 response times, which are also referred to as cross-switch transport 136 time or cross-switch delay. This section reviews the meanings of switch 137 response times, several other related terms, and the generally accepted 138 values of switch response times published by Telcordia Technologies. The 139 corresponding ITU-T�s cross-switch timing requirements are also listed 140 as references. 142 This Internet Draft reviews the switch response time requirements 143 intended to apply under normal loading. Normal loading is usually 144 associated with the notion of the Average Busy Season Busy Hour (ABSBH) 145 load. Simply put, it is expected that the switch response times that a 146 particular switch experiences at this load will be virtually load- 147 independent. 149 Switch response time is the period that starts when a stimulus occurs at 150 the switch and ends when the switch completes its response to the 151 stimulus. The occurrence of a stimulus often means the switch receives 152 the last bit of a message from an incoming signaling link, and 153 completion of a response means the switch transmits the last bit of the 154 message on the outgoing signaling link. If the switch�s response to a 155 stimulus involves the switch sending a message on the outgoing signaling 156 link, then switch processing time is the sum of the switch processing 157 time and the link output delay: 159 switch response time = switch processing time + link output delay 161 Switch processing time is the period that starts when a stimulus occurs 162 at the switch and ends when the switch places the last bit of the 163 message in the output signaling link controller buffer. The period 164 between the switch placing the message in the output signaling link 165 controller buffer and the switch transmitting the last bit of the 166 message on the outgoing signaling link is defined as the link output 167 delay. Link output delay can be further divided into the queuing delay 168 and message emission time. There are separate delay requirements for 169 switch processing time and link output delay; however, for simplicity 170 only the combined delay requirements for switch response time, as given 171 in Table 3, will be listed in this Internet Draft. 173 Table 3: Switch Response Time Assuming Typical Traffic Mix and 174 Message Lengths (Source: Telcordia GR-1364-CORE, Table 5-1) 176 Type of Call Segment Switch Response Time (ms) 177 Mean 95% 178 ISUP Message 205-218 <=337-349 179 Alerting 400 <=532 180 ISDN Access Message 220-227 <=352-359 181 TCAP Message 210-222 <=342-354 182 Announcement/Tone 300 <=432 183 Connection 300 <=432 185 Telcordia GR-1364 specifies switch response time using �switch call 186 segments� as a convenient way to refer to the various phases of call 187 processing that switches are involved in. (An alternative would be 188 proposing switch processing requirements for every possible type of 189 switch processing. Obviously, this would become burdensome and would 190 necessitate adding to the requirements every time an additional type of 191 switch processing was required.) Listed in Table 3 are: 193 1. ISUP message call segments that involve the switch sending an ISUP 194 message as a result of a stimulus. 195 2. Alerting call segments that involve the switch alerting the 196 originating and/or terminating lines as a result of a stimulus. 197 3. ISDN access message call segments that involve the switch sending an 198 ISDN access message (other than an ISDN access ALERT message) as a 199 result of stimulus. ISDN access message call segment processing 200 occurs at originating or terminating switches where the originating 201 or terminating line, respectively, is an ISDN line. 202 4. TCAP message call segments that involve the switch sending a TCAP 203 message as a result of a stimulus. 204 5. Announcement/tone call segments that involve the switch playing an 205 announcement, placing a tone on, or removing a tone from the 206 originating or terminating line as a result of a stimulus. However, 207 the announcement/tone call segments do not include dial-tone delay, 208 of which the delay requirements can be found in Telcordia 209 TR-TSY-000511[6]. 210 6. Connection call segments involve the switch connecting one or more 211 users as a result of a stimulus. 213 The ITU-T�s cross-switch timing requirements are listed below as 215 references. It is noted that the ITU-T�s requirements are noticeably 216 stringent that those of Telcordia under the normal loading. However, 217 since the ITU-T�s values are stated as �provisional� and they do not 218 provide the timing requirements for ISDN, Telcordia�s values will be 219 used to derive the call setup delay requirements. 221 Table 4: ITU-T Cross-Switch Transfer Time 222 (Source: ITU-T Recommendation Q.725, Table 3) 223 Exchange call Cross-Switch Transfer 224 Time (ms)* 225 Message typ attempt loading Mean 95% 227 Simple Normal 110 220 228 (e.g. answer) +15% 165 330 229 +30% 275 550 231 Processing Normal 180 360 232 intensive +15% 270 540 233 (e.g. IAM) +30% 450 900 235 * Provisional values. 237 4. Cross-STP Delay 239 Message delay through an STP is specified as the cross-STP delay. It is 240 the interval that begins when the STP receives the last bit of a message 241 from the incoming signaling link, and ends when the STP transmits the 242 last bit of the message on the outgoing signaling link. As with the 243 switch response time discussed in the previous section, the cross-STP 244 can be divided into processor handling time and link output delay. This 245 Internet Draft adopts the cross-STP delay requirements specified in ITU- 246 T Q.706 Recommendation. 248 Table 5: Message transfer time at an STP 249 (Source: ITU-T Recommendation Q.706, Table 5) 251 Message transfer Time (ms) 252 STP signaling traffic load Mean 95% 254 Normal 20 40 255 +15% 40 80 256 +30% 100 200 258 5. Maximum End-to-End Signaling Delays 260 Using the HSRC, switch response times, and cross-STP delays, one can 261 compute the maximum signaling transfer delays for ISUP messages under 262 normal load. As with Telcordia GR-1364, it is assumed that the 263 distribution of switch response time for each call segment is 264 approximately a normal distribution. It is further assumed that switch 265 response times of different switches are independent. Under these 266 assumptions, the end-to-end (from originating switch to terminating 268 switch) delays for each national component and for international calls 269 are listed in Tables 6 and 7, respectively. The 20 ms cross-STP delay is 270 assumed in all cases. It should be noted that all these values must be 271 increased by the transmission propagation delays, which are listed in 272 Table 8. 274 Table 6: Maximum ISUP Signal Transfer Delays for Each National Component 276 Country size Percent of Delay (ms) 277 connections Mean 95% 279 Large-size 50% 675-714 <=904-941 280 95% 900-952 <=1164-1214 282 Average-size 50% 450-476 <=637-661 283 95% 675-714 <=904-941 285 Table 7: Maximum ISUP Signal Transfer Delays for International Calls 287 Country size Percent of Delay (ms) 288 connections Mean 95% 290 Large-size to 50% 2025-2142 <=2421-2538 291 Large-size 95% 2495-2638 <=2933-3076 293 Large-size to 50% 2250-2380 <=2677-2797 294 Average-size 95% 2720-2876 <=3177-3333 296 Average-size to 50% 2475-2618 <=2913-3056 297 Average-size 95% 2965-3134 <=3441-3610 299 Table 8: Calculated Terrestrial Transmission Delays for Various Call 300 Distances (Source: ITU-T Recommendation Q.706, Table 1) 302 Arc length Delay terrestrial (ms) 303 (km) Wire Fibre Radio 304 500 2.4 2.5 1.7 305 1000 4.8 5.0 3.3 306 2000 9.6 10.0 6.6 307 5000 24.0 25.0 16.5 308 10000 48.0 50.0 33.0 309 15000 72.0 75.0 49.5 310 17737 85.1 88.7 58.5 311 20000 96.0 100.0 66.0 312 25000 120.0 125.0 82.5 314 6. Basic Call Flow and Call Setup Delays 316 The following figure illustrates the simplest call flow for call setup 317 in an ISDN-SS7 environment. The end user terminals are assumed to be 318 ISDN phones and use Q.931 messages (i.e., Setup and Alerting). The 319 switches use ISUP messages to establish inter-switch trunks for the 320 subsequent voice communication. 322 Figure 1: Simple Call Setup Signaling Flow 324 Caller Originating Terminating Called 325 Terminal Switch Switch Terminal 326 | | | | 327 | Setup | | | 328 |---------------->| | | 329 | | IAM IAM | | 330 | |---------> . . . . --------->| | 331 | | | Setup | 332 | | |-------------->| 333 | | | | 334 | | | Alerting | 335 | | |<--------------| 336 | | ACM ACM | | 337 | |<--------- . . . . <---------| | 338 | Alerting | | | 339 |<----------------| | | 340 | | | | 341 | | | | 343 Using the above call flow, the end-to-end message transfer delays in 344 Tables 6 and 7, and the switch response times for Q.931 messages in 345 Table 3, one can derive the call setup times given in the following 346 tables. Again, all these values must be increased by the transmission 347 propagation delays listed in Table 8. 349 Table 9: Call Setup Delays for Each National Component 351 Country size Percent of Call Setup Delay (ms) 352 connections Mean 95% 354 Large-size 50% 2590-2682 <=3007-3099 355 95% 3040-3158 <=3497-3615 357 Average-size 50% 2140-2206 <=2513-2579 358 95% 2590-2682 <=3007-3099 360 Table 10: Call Setup Delays for International Calls 362 Country size Percent of Delay (ms) 363 connections Mean 95% 365 Large-size to 50% 5290-5538 <=5909-6157 366 Large-size 95% 6230-6530 <=6903-7203 368 Large-size to 50% 5740-6014 <=6387-6661 369 Average-size 95% 6680-7006 <=7378-7704 371 Average-size to 50% 6190-6490 <=6863-7163 372 Average-size 95% 7170-7522 <=7893-8245 374 8. User Expectations 376 The requirements derived in the previous section should be interpreted 377 as the worst-case requirements. At least in the United States, users of 378 SCN typically experience far less setup delays than the derived delay 379 requirements. With the maturing of Common Channel Signaling (CCS) 380 Network, call setup time has been reduced to a mere one to two seconds 381 [1]. The VoIP networks are expected to achieve the same level of delay 383 There is no known study on expected setup delays for international 384 calls. As discussed, a HSRC for international working consists of an 385 international component and two national components, and the maximum 386 number of signaling points and STPs in a national component is roughly 387 the same as the number in an international component (Tables 1 and 2). 388 As a consequence, the end-to-end ISUP delays in an international call 389 are roughly three times of those in a national call. On the other hand, 390 the Q.931 signals occur only at the two ends for both national and 391 international calls. Based on these observations, one may expect 2.5-5 392 second call setup delays to be reasonable for international calls. 394 Acknowledgements 396 The authors would like to express their gratitude to Dr. Daniel Luan of 397 AT&T Labs for his insight into network operation and valuable 398 suggestions for calculating end-to-end signaling delays as well as call 399 setup delays. 401 References 403 [1] AT&T Webpage, 404 www.att.com/technology/technologists/fellows/lawser.html. 406 [2] ITU-T Recommendation Q.709, Specifications of Signaling System No. 407 7--Hypothetical Signaling Reference Connection, March 1993. 409 [3] Telcordia Technologies Generic Requirements GR-1364-CORE, Issue 1, 410 LSSGR: Switch Processing Time Generic Requirements Section 5.6, June 411 1995. 413 [4] ITU-T Recommendation Q.706, Specifications of Signaling System No. 414 7�Message Transfer Part Signaling Performance, March 1993. 416 [5] ITU-T Recommendation Q.706, Specifications of Signaling System No. 417 7�Signaling performance in the Telephone Application, March 1993. 419 [6] Telcordia Technologies TR-TSY-000511, LSSGR: Service Standards, 420 Section 11, Issue 2, July 1987. 422 Authors' addresses 424 Huai-An Lin 425 Telcordia Technologies 426 445 South Street, MCC-1A216R 427 Morristown, NJ 07960-6438 428 Phone: 973 829-2412 429 Email: hlin@research.telcordia.com 431 Taruni Seth 432 Telcordia Technologies 433 445 South Street, MCC-1G209R 434 Morristown, NJ 07960-6438 Phone: 973 829-4046 435 Email: taruni@research.telcordia.com 437 Albert Broscius 438 Telcordia Technologies 439 445 South Street, MCC-1A264B 440 Morristown, NJ 07960-6438 441 Phone: 973 829-4781 442 Email: broscius@research.telcordia.com 444 Christian Huitema 445 Telcordia Technologies 446 445 South Street, MCC-1J244B 447 Morristown, NJ 07960-6438 448 Phone: 973 829-4266 449 Email: huitema@research.telcordia.com