INTERNET DRAFT Taruni Seth Internet Engineering Task Force Albert Broscius February 26, 1999 Christian Huitema Expires August 26, 1999 Huai-An P. Lin Bellcore Performance Requirements for TCAP Signaling in Internet Telephony T. Seth, A. Broscius, C. Huitema, H. P. Lin Bellcore Status of this document This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." To view the entire list of current Internet-Drafts, please check the " http://www.ietf.org/ietf/1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This document is an Internet-Draft. Internet-Drafts are working docu- ments of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Abstract To allow interoperability between the existing telephone network and Internet Telephony (IT) it is necessary for the signaling performance to be comparable to that of the current standards to avoid introducing degradation in the service. In this Internet Draft, we discuss the Seth, Broscius, Huitema, Lin [Page 1] Internet draft SIGTRAN, TCAP Performance Requirement February 26, 1999 performance requirements for TCAP signaling across an IP network. We also highlight the dependency on the SCP database location and thus problems related in providing high-quality service for TCAP based appli- cations. Table of Contents 1. Introduction ...............................................3 2. Context .............................................. 4 3. Overview of TCAP .............................................. 5 3.1 TCAP in a Nutshell .............................................. 5 3.2 Signaling Connection Control Part .............................................. 6 3.3 Global Title Translation .............................................. 6 3.4 Service Control Point (SCP) .............................................. 7 3.5 TCAP Transaction Flow Diagram .............................................. 7 4. Performance Requirements .............................................. 9 4.1 Query Response Time .............................................. 9 4.2 SSP Response Time .............................................. 10 4.3 SCP Response Time .............................................. 10 4.3.1 SCP Handling Time .............................................. 11 4.3.2 Disk Lookup Time .............................................. 11 Seth, Broscius, Huitema, Lin [Page 2] Internet draft SIGTRAN, TCAP Performance Requirement February 26, 1999 4.3.3 Link Output Delay .............................................. 11 4.3.4 Total SCP Response Time .............................................. 12 4.4 Message Transfer Time ............................................. 12 4.5 Other General Parameters .............................................. 13 4.5.1 maxResponseTime .............................................. 13 4.5.2 maxPendingTime .............................................. 13 5. Implications to VoIP .............................................. 13 6. References .............................................. 15 7. Authors' Addresses .............................................. 15 Full Copyright Statement .............................................. 16 1. Introduction A public switched telephone network (PSTN) based telephone call involves the delivery of voice over a dedicated circuit-switched network (CSN) and the delivery of call processing signaling messages over a separate packet switched network called the Common Channel Signaling (CCS) net- work. PSTN call processing involves two types of signaling messages: the ISUP (ISDN User Part) [2] messages which are responsible for the basic setup, management and teardown of a telephone call and the Transaction Capabilities User Part (TCAP) [3] messages, which are used for non- circuit related messages used in advanced call setup features, and those requiring access to network databases, such as the database of valid calling card PIN numbers. To interwork with PSTN, Internet Telephony must process these ISUP and TCAP messages. Both of these protocols have specific performance requirements. Requirements for ISUP messages were discussed in [1]. This Internet Draft focuses mainly on some of the Seth, Broscius, Huitema, Lin [Page 3] Internet draft SIGTRAN, TCAP Performance Requirement February 26, 1999 issues related to the performance requirement of the TCAP messages. 2. Context A commonly envisioned Internet Telephony system architecture includes an IP network as the core communication infrastructure. Both reliable and unreliable data is transported over the IP infrastructure through the use of a variety of upper layer protocols. In the IP network, generally, all the traffic competes against each other in a single flow. Segmenting signaling, data and voice traffic flows on the network allows the per- formance guarantees of the different traffic components to be set independently, since they differ in their loss and delay tolerance requirements. Signalling quality requirements could be expressed by simply stating that call set-up time, and generally signalling delays, should be simi- lar to those observed in classic telephony networks. When analyzing the requirements, we will distinguish between absolute requirements, which are mandated for proper interaction with the classic telephone network, and quality objectives, which are mostly desirable goals based on user expectations. The mandatory requirements of telephony systems are specified in several "General Requirement" documents published by Bellcore and ITU-T. We need to derive loss and delay bounds from the existing telephony standards for inter working of Internet Telephony and the PSTN. Both loss and latency affect the perceived user quality when establishing telephone calls across the Internet Telephony infrastructure. Excessive delay may cause call setup failure through end-switch time-outs, requiring the user to re-dial. TCAP loss may also cause call setup failures through timeouts that may leave resources in the network held in an active state after a call teardown message is lost. Earlier work specified the requirements for ISUP Signaling over IP based on the PSTN specifications[1]. ISUP messages are used for basic call control and setup, whereas TCAP messages are particular to each specific application and do not have generic performance requirements. However, there are some specifications for the network elements involved in a TCAP transaction, which allow us to estimate some other measures. Here we will try and establish a similar set of parameters for TCAP messag- ing, based on signalling performance metrics such as the query-response delay. In this Internet draft, we focus on the performance requirements for TCAP applications. We discuss mandatory requirements as established by the timers in PSTN network elements, which determine the tolerance of these applications to delays and losses. We will also discuss the user expectations and values of these requirements as available from current Seth, Broscius, Huitema, Lin [Page 4] Internet draft SIGTRAN, TCAP Performance Requirement February 26, 1999 PSTN implementations. We summarize the implications of these in a VoIP framework and discuss merits of existing technologies to enhance these performance requirements in the IP networks. 3. Overview of TCAP 3.1. TCAP in a Nutshell TCAP messages are designed for accessing databases or other switches to retrieve information or invoke features. TCAP enables the deployment of advanced intelligent network services by supporting non-circuit related information exchange between signaling points using the signaling con- nection control part (SCCP) connectionless service for message tran- sport. This is a fundamental difference between ISUP and TCAP protocols. ISUP messages follow a particular path used to establish a circuit con- nection and use the Message Transfer Part (MTP) to route its messages, whereas TCAP information is not related to any one circuit and must be transferred through the network using end-to-end signaling, which is achieved by the SCCP protocol above MTP. The term "Transaction Capabili- ties" refers to the application layer protocol, called TCAP, plus the supporting Presentation, Session, and Transport layers, called the Application Services Part (ASP). A common example of TCAP usage is in dialing a 800, 888, or 900 number. An SSP uses TCAP to query an SCP to determine the routing number(s) associated with the dialed digits. The SCP uses TCAP to return a response containing the routing number(s) (or an error) back to the SSP. TCAP messages consist of two portions: a Transaction Portion composed entirely of protocol control information, and a Component Portion which contains protocol-related information as well as data concerning the application process. The transaction portion of the TCAP message identifies whether the tran- saction between two nodes is expected to consist of a single message (i.e. one way communication) or multiple messages (i.e. interactive com- munication). There are five types of TCAP messages, called Package Type: Query, Response, Conversation, Unidirectional, and Abort. The transac- tion portion provides the information necessary for the signaling point to route the component information to its destination. It contains the Transaction ID and the package type identifier. The Transaction ID is a reference to correlate messages within the same transaction and associ- ate the TCAP transaction with a specific application at the originating and destination signaling points. In a single transaction, one or more operations may occur. For each operation, one or more components may be involved. Components provide the information that request an action, invoke an operation or provide the reaction to a previous request. Component types include Invoke, Seth, Broscius, Huitema, Lin [Page 5] Internet draft SIGTRAN, TCAP Performance Requirement February 26, 1999 Return Result, Return Error, and Reject. Components include parameters which contain application-specific data carried unexamined by TCAP. 3.2. Signaling Connection Control Part The SCCP provides connectionless and connection-oriented network ser- vices above MTP Level 3. SCCP provides two major functions that are lacking in the MTP. The first of these is the capability to address applications within a signaling point. The MTP can only receive and deliver messages from a node "as a whole"; it does not deal with software applications within a node. While MTP Level 3 provides point codes to allow messages to be addressed to specific signaling points, SCCP provides subsystem numbers to allow messages to be addressed to specific applications (called subsystems) at these signaling points. SCCP is used as the transport layer for TCAP-based services such as toll free (800) phone, calling card, and wireless services. The SCCP controls provide efficient routing of TCAP like messages that are independent of voice network connections. Their routing information may contain the Link Selection information besides the Originating and Destination Point Codes, if necessary. 3.3. Global Title Translation SCCP also provides the means by which a Signal Transfer Point (STP) can perform global title translation (GTT), a procedure by which the desti- nation signaling point and subsystem number (SSN) is determined from digits (i.e., the global title) present in the signaling message. The global title digits may be the dialed 800/888 number, calling card number, or mobile subscriber identification number depending on the ser- vice requested. Since an STP provides global title translation, ori- ginating signaling points do not need to know the destination point code or subsystem number of every potential destination to which they might have to route a message for the associated service. Only the STPs need to maintain a database of destination point codes and subsystem numbers associated with specific services and possible destinations. The STP examines the message, and determines where the message should be routed. Switches can generate queries addressed to their local STPs, which, using global title translation, select the correct destination to which the message should be routed. STPs must maintain a database that enables them to determine to where a query should be routed. Global title trans- lation effectively centralizes the problem and places it in a node (the STP) that has been designed to perform this function. Further, an STP can perform "intermediate global title translation," in which it uses its tables to find another STP further along the route to the destina- tion. Intermediate global title translation minimizes the need for STPs to maintain extensive information about nodes which are far removed from them. Global Title Translation is also used at the STP to share load Seth, Broscius, Huitema, Lin [Page 6] Internet draft SIGTRAN, TCAP Performance Requirement February 26, 1999 among mated Service Control Point (SCP) databases in both normal and failure scenarios. It can select an SCP on either a priority basis (referred to as primary -- backup) or to allow load sharing across all available SCPs. 3.4. Service Control Point (SCP) An SCP site refers to the hardware and node software needed to support applications. An SCP is a network system that supports the execution of service logic in response to queries from switching systems. These ser- vices are implemented as features of switching systems and network data- bases. The SCP node serves as a network host to each application and provides common functions as distributing incoming messages to the appropriate application, assigning external signaling links, SCP mainte- nance and controlling SCP overload procedures. The SCP applications consist of application-specific software and data that can be accessed by other nodes on the signaling network, such as a switching system or an Operator Services System (OSS). Each application may provide many individual services, and these are transparent to the SCP node. In return, this application formulates the parameters of a response mes- sage, which the node formats and routes to the appropriate network entity. 3.5. TCAP Transaction Flow Diagram In the VoIP framework, TCAP messages must be supported not only in order to interoperate with the PSTN, but to allow development of new services. In the IP network, there exist the Media Gateway Controllers (MGC), which are the counterparts to the switches in the PSTN network. These MGCs contain the Call Controller, which provides signaling functionality for call setup. The TCAP signaling may be envisioned within IP networks between the MGC and/or a SG and an IP-based SCP (IP-SCP) (Figure 1). Further, as shown in the architecture document [4], the TCAP signaling may also be used for cross-access between entities in the SS7 domain and the IP domain, such as: - access from an SS7 network to an IP-SCP - access from an SS7 network to an MGC - access from an MGC to an SS7 net- work element (SCP) - access from an IP-SCP to an SS7 network element In this minimal scenario of a TCAP call query (Figure 1), the signal may be an incoming TCAP query to the ingress signaling gateway (SG) or may originate at the MGC. It is accordingly processed and sent to the IP-SCP which will then process it and return an appropriate response. Call Related TCAP Transaction/Message Flow Diagram [5] Seth, Broscius, Huitema, Lin [Page 7] Internet draft SIGTRAN, TCAP Performance Requirement February 26, 1999 | SG/MGC| | IP-SCP| | | | | | | | | | Query | | | | ------|--------------------------------> | | | | | | | | | | | Conversation | | <-|-------------------------------- | | | | | | | | | | Conversation | | | ----|--------------------------------> | | | | | | | | | | | Response | | <--|-----------------------------|-- | Figure 1: simplified scenario of a TCAP query and response The sequence of messages that must complete successfully before the TCAP transaction query is satisfied is as follows: * Query message processing by the SG or MGC * Query message transport to the IP database (IP-SCP), * Query message processing by the IP-SCP, * Conversation message processing by the IP-SCP, * Conversation message transport from the IP-SCP to the SG or MGC, * Conversation message processing by the SG/MGC, * Conversation message transport from the SG/MGC to the IP-SCP, * Conversation message processing by the IP-SCP, * Response message processing by the IP-SCP, * Response message transport from the IP-SCP to the SG/MGC, * Response message processing by the SG/MGC, Seth, Broscius, Huitema, Lin [Page 8] Internet draft SIGTRAN, TCAP Performance Requirement February 26, 1999 4. Performance Requirements The end-to-end AIN performance is a function of the performance of each AIN network element (e.g., an SSP, STP) and each network system (e.g., a SCP) and their interfaces. Thus to ensure overall network performance, the performance objectives and requirements must be defined for each component. We described the requirements for STPs in our earlier docu- ment [1], and here we discuss them for SSPs and SCPs. The SSP generally originates a query to the SCP and awaits its response. The performance of the TCAP applications relies on the Query Response Time. The SCP per- formance depends not only on its several components and interfaces but also on the application process(es) involved. Thus its conformance test- ing depends on the use of standard application processes called bench- mark transactions, that emulate the potential AIN service on a SCP. 4.1. Query Response Time Query Response Time is defined as the time it takes to send a query to a database host and for the database to process the query and return data to the querying entity (e.g. SSP, STP). The Query response time for the Network User Identifier (NUI) database host and the NUI database to pro- cess a Public Packet Switched Network (PPSN) query and return the data to the querying entity is given as [6]: * Mean value 0.25 to 0.5 seconds The common user expectation for most simple TCAP query-response applica- tions appears to be on the order of 0.5sec. However, the actual PSTN working data shows that these are in the range of 250-350ms. Seth, Broscius, Huitema, Lin [Page 9] Internet draft SIGTRAN, TCAP Performance Requirement February 26, 1999 Query Response Time | | +---------------------------------------+ | | SCP Response Time Message Transfer Time | +-------------+--------------+ | | | | | | SCP Handling Disk LookUp Link Output Time Time Delay | | | | | | +----------+ Number of +-------------+ | | LookUps | | | | | | | | | | SCP Platform SCP Application Msg. Queueing Msg. Emission Processing Time Processing Time Delay Delay Figure 2: Time components in a TCAP query 4.2. SSP Response Time The SSP uses a timer T1 to establish the time for a message from the SCP in response to a message sent by the SSP to the SCP. Each instance of this timer T1 is associated with a particular TCAP transaction, and only one timer is set for a given transaction. The allowable range for timer T1, is from 0.1 to 30.0 seconds, with 0.1 second increments, and a default value is 3.0 seconds [7]. The SSP starts this T1 timer after it sends a Query (or Conversation Package) to the SCP and then awaits an SCP call-related response (or Conversation Package) for the particular TCAP transaction. The SSP can- cels the timer on receipt of this response, closes the particular TCAP transaction, and continues call processing. 4.3. SCP Response Time The SCP response time is calculated as a sum of the SCP Handling Time, Disk Lookup Time and Link Output Delay. It is defined as the interval that begins when the last bit of a Call Related message enters the SCP, and ends when the last bit of a Call Related message leaves the SCP. Seth, Broscius, Huitema, Lin [Page 10] Internet draft SIGTRAN, TCAP Performance Requirement February 26, 1999 4.3.1. SCP Handling Time It is defined as the interval that begins when the last bit of a Call Related message enters the SCP, and ends when the last bit of a Call Related message is placed at the outgoing signaling link buffer, exclud- ing time taken for a disk lookup. It is further subdivided into the SCP Platform Processing Time and the SCP Application Processing Time. SCP Platform Processing Time: This has three time contributions. The first begins when the last bit of a Call Related message enters the SCP, and ends when the TCAP message is made available to the application pro- cess. Second involves execution time of any application support process- ing functions needed by the SCP application, and the third begins when the platform receives the outgoing message from the application process and ends when the last bit of a Call Related message is placed at the outgoing signaling link buffer. The mean and 95th percentile SCP Plat- form Processing Time in processing a Call Related message which does not involve a disk look up [7], (but does involve processing of critical operations, administration, and maintenance functions) is * Mean value <= 100 ms * 0.95 prob. of not exceeding <= 120 ms SCP Application Processing Time: It is the difference between the SCP Handling Time and the SCP Platform Processing Time. It is a function of desired overall service delay, network architecture, deployment etc. and is negotiated and tailored to each application's need. 4.3.2. Disk Lookup Time Certain applications require access to data on the disk, and some mes- sages may even require multiple disk lookups. The Disk Lookup Time required in determining a SCP response message, must be * <= 30 ms for each Lookup. 4.3.3. Link Output Delay It is the interval that begins when last bit of a SCP Response message is placed at the outgoing signaling link buffer, and ends when the last bit of the Call Related message leaves the SCP on the outgoing signaling link. The two components of the Link Output Delay are the message queu- ing delay and the message emission delay. Queuing delay is a function of link occupancy and the message length distribution. Emission delay is a function of the signaling link speed and the message length distribu- tion. Under normal conditions, messages are expected to be shorter than 279 octets. The Link Output Delay [7] calculated using the M/G/1 queuing Seth, Broscius, Huitema, Lin [Page 11] Internet draft SIGTRAN, TCAP Performance Requirement February 26, 1999 formula for messages of length 279 octets and at a Link load of 0.4 erlang should be * 56 Kb/s 64Kb/s * Mean value <= 55 ms <= 47 ms * 0.95 prob. of not exceeding <=102 ms <= 89 ms 4.3.4. Total SCP Response Time The industry requirement for SCP response times for a simple TCAP tran- saction (one query, one response, for data retrieval from a LIDB for an operator system) can be summarized as follows [6]: * Daily Peak Yearly Peak (aka Reference Load A) (aka Reference Load B) * Mean value <= 250 ms <= 400 ms * 0.95 prob. not exceed 300 ms 600 ms 4.4. Message Transfer Time The maximum signalling delay is a function of several parameters, such as the propagation time on the signalling links (which is variable of distance), number of SSPs, STPs, (or SG/MGC) and SCPs involved in each connection as well as the processing time, emission and queuing delays within each of these network elements. Delay allocation rules, in most standards, apply to processing time only, as the propagation time por- tion is determined by the distance and speed of the signal in the transmission facility. However it is possible to estimate the upper bound for the time available for message transfers from the maximum query response time and a sum of the times required by the various com- ponents of the network involved in the query. Consider a mean time of 350ms for a simple TCAP query-response applica- tion, which uses a single disk lookup, a 25ms average SCP Application Processing Time and a 64Kbps link. Then, the transmission time available between the querying agent and the database is of the order of 150 ms for a query and its response. Mean Values * SCP Platform Processing Time 100 ms Seth, Broscius, Huitema, Lin [Page 12] Internet draft SIGTRAN, TCAP Performance Requirement February 26, 1999 * Disk Lookup (Assuming one) 30 ms * SCP Application Processing Time (Assumed) 25 ms * Link Output Delay (64 kbps link) 47 ms --------------------------------------------------------------------------- * SCP Response Time 202 ms * Average Query Response 350 ms * Implied Message Transfer Time 148 ms Thus, if the SCP Response Time is independent of the network technology (other than the Link Output Delay), we have roughly a 150 ms budget for TCAP message transfer--round trip, or 75 ms one way, to achieve a response time comparable to the PSTN. 4.5. Other General Parameters Certain parameters such as maxResponseTime and maxPendingTime are also defined as general performance measures over the CCS network. 4.5.1. maxResponseTime It is the maximum time the SCP allows itself to respond to a message received over the CCS network. It takes into account the time it will take for the SCP reply to reach the sending node i.e. the SSP. It is an administrable value with a default set to 2.0 seconds [6]. 4.5.2. maxPendingTime It is the maximum time the SCP will wait for a reply to a Conversation or Query Package Type. This value is meant to be a "catch all" in case of an error. Applications that need to monitor the time or depend on the timing of the reply to the message sent set separate timers. It is an administrable value with a default set to 15.0 minutes [6]. 5. Implications to VoIP Telephony applications can be described as relatively intolerant to packet losses and network delay. The quality of service delivered by an IP transport mechanisms depends on the quality of the underlying IP net- work service. Statistical measurements and analysis by Guy Almes [8] and also Sanghi et. al. [9], show that the losses in the Internet today are in the range of 2-10%. Losses have a direct correlation with delay. A tentative conclusion from this is that the basic Internet quality, today, would not really allow the transmission of toll quality voice, Seth, Broscius, Huitema, Lin [Page 13] Internet draft SIGTRAN, TCAP Performance Requirement February 26, 1999 except on some "lucky" subsets. We may expect that Internet Telephony traffic will often be transported over dedicated IP networks, and that prioritization and access control will be used to minimize loss and delay (to signaling traffic), via QoS-based differentiated services mechanisms. This will guarantee a level of service that is compatible with quality expectation of PSTN users. In IP routing, the use of differentiated services via traffic schedulers such as Weighted Fair Queuing (WFQ), and Priority Queuing, allows traffic flows to be distinguished and prioritized. This enables allocation of QoS parameters to different flows. However, preliminary laboratory tests of commercial routers supporting differentiated ser- vices indicate that there are some overhead delays associated with implementing these mechanisms and may lead to some unexpected complica- tions. These delays are probably processing delays of the WFQ scheduling algorithm and some additional queuing delays. The average shift in the delay comprises of: 1. A one-time overhead of 10ms delay associated with tagging the incoming signaling packets with the required precedence bits at the ingress router. 2. A 10ms per-node (router) delay arising from applying the WFQ algo- rithm to the different traffic flows. The delays associated with the implementation of WFQ will probably increase linearly with the number of routers in the transmission path. The network designer would have to very carefully decide if they can justify the use of QoS to guarantee reliability, if use of differen- tiated services imposes unacceptable delays on the transmission of TCAP signaling messages. For example, if one-way transmission time is about 75ms and there are 3 routers in the path between the querying entity and the IP-SCP, then applying ToS based WFQ to the signaling packets would reduce available transmission time to roughly 35ms (10ms for tagging and 30ms for WFQ at the 3 routers). It may be argued that these delays are vendor specific and can be improved over time and that packets may be tagged at source. However, tagging at ingress routers across different network domains as a security measure may still be an issue. In the IT architecture the IP-SCP is still an ambiguous network element. It would allow the SG or the MGC to directly access the database to satisfy the TCAP queries. Since the IP network is not as robust as the existing PSTN, the high loss probability of messages will impose strict restrictions on the location of the IP-SCP within the IP network. More- over, if the TCAP query originates in the IP network and needs to access an PSTN based SCP, it would involve complex message processing and transmission. The estimate of the message transfer time in Section 4.4, Seth, Broscius, Huitema, Lin [Page 14] Internet draft SIGTRAN, TCAP Performance Requirement February 26, 1999 would imply that there is little scope for retransmission in the event of network losses. At this stage, we can only conclude that these delays need to be investigated more thoroughly before deciding the effective- ness of using Differentiated Services to prioritize signaling traffic. 6. References [1] T. Seth, et al, "Performance Requirements for Signaling in Internet Telephony" , Nov. 1998. [2] American National Standard Institute (ANSI), "Signaling System No. 7 (SS7) - Integrated Services Digital (ISDN) User Part," ANSI standard T1.113, January 3, 1995. [3] Bellcore, "AIN Switch - Service Control Point(SCP)/ Adjunct Inter- face Generic Requirements", GR-1299-CORE, Issue 2, Dec. 1994, Sec- tion 2-TCAP. .IP [4] L. Ong, " Architectural Framework for Signaling Transport" , Feb. 1999. [5] Bellcore, "Advanced Intelligent Network Generic Requirements (AINGR): Switch - Service Control Point(SCP)/ Adjunct Interface, ", GR-1299-CORE, Issue 4, Sept. 1997. [6] Bellcore, "Service Control Point Node, Generic Requirements", TR- NWT-000029, Issue 1, Sept. 1990. [7] Bellcore, "Advanced Intelligent Network (AIN) Service Control Point(SCP), Generic Requirements", GR-1280-CORE, Issue 1, Aug. 1993. [8] Guy Almes, "Loss and Delay Measurement Plots", http://ippm- db.advanced.org/plots, Advanced Network & Services, Inc. [9] D. Sanghi et.al., "Experimental Assessment of End-to-End Behavior on Internet", Proc. IEEE INFOCOM '93, March 1993, pp 867-874. 7. Authors' Addresses Taruni U Seth Bellcore 445 South Street, MCC-1G209R Morristown, NJ 07960-6438 Phone: 973 829-4046 Email: tseth@notes.cc.bellcore.com Seth, Broscius, Huitema, Lin [Page 15] Internet draft SIGTRAN, TCAP Performance Requirement February 26, 1999 Bellcore 445 South Street, MCC-1A264B Morristown, NJ 07960-6438 Phone: 973 829-4781 Email: broscius@bellcore.com Christian Huitema Bellcore 445 South Street, MCC-1J244B Morristown, NJ 07960-6438 Phone: 973 829-4266 Email: huitema@bellcore.com Huai-An P. Lin Bellcore 445 South Street, MCC-1A216R Morristown, NJ 07960-6438 Phone: 973 829-2412 Email: hlin@bellcore.com Full Copyright Statement Copyright (C) The Internet Society (1998). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Seth, Broscius, Huitema, Lin [Page 16] Internet draft SIGTRAN, TCAP Performance Requirement February 26, 1999 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Seth, Broscius, Huitema, Lin [Page 17]