Network Working Group J. Rosenberg Request for Comments: 2871 dynamicsoft Category: Informational H. Schulzrinne Columbia University June 2000 A Framework for Telephony Routing over IP Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved.
AbstractThis document serves as a framework for Telephony Routing over IP (TRIP), which supports the discovery and exchange of IP telephony gateway routing tables between providers. The document defines the problem of telephony routing exchange, and motivates the need for the protocol. It presents an architectural framework for TRIP, defines terminology, specifies the various protocol elements and their functions, overviews the services provided by the protocol, and discusses how it fits into the broader context of Internet telephony. 1 Introduction ........................................ 2 2 Terminology ......................................... 2 3 Motivation and Problem Definition ................... 4 4 Related Problems .................................... 6 5 Relationship with BGP ............................... 7 6 Example Applications of TRIP ........................ 8 6.1 Clearinghouses ...................................... 8 6.2 Confederations ...................................... 9 6.3 Gateway Wholesalers ................................. 9 7 Architecture ........................................ 11 8 Elements ............................................ 12 8.1 IT Administrative Domain ............................ 12 8.2 Gateway ............................................. 13 8.3 End Users ........................................... 14 8.4 Location Server ..................................... 14 9 Element Interactions ................................ 16
9.1 Gateways and Location Servers ....................... 16 9.2 Location Server to Location Server .................. 16 9.2.1 Nature of Exchanged Information ..................... 17 9.2.2 Quality of Service .................................. 18 9.2.3 Cost Information .................................... 19 10 The Front End ....................................... 19 10.1 Front End Customers ................................. 19 10.2 Front End Protocols ................................. 20 11 Number Translations ................................. 21 12 Security Considerations ............................. 22 13 Acknowledgments ..................................... 23 14 Bibliography ........................................ 23 15 Authors' Addresses .................................. 24 16 Full Copyright Statement ............................ 25
the end user is directly controlling it. If, however, the calling device is a telephony gateway, the end user may be accessing it through a telephone. Gatekeeper: The H.323 gatekeeper element, defined in . SIP Server: The Session Initiation Protocol proxy or redirect server defined in . Call Agent: The MGCP call agent, defined in . GSTN: The Global Switched Telephone Network, which is the worldwide circuit switched network. Signaling Server: A signaling server is an entity which is capable of receiving and sending signaling messages for some IP telephony signaling protocol, such as H.323 or SIP. Generally speaking, a signaling server is a gatekeeper, SIP server, or call agent. Location Server (LS): A logical entity with IP connectivity which has knowledge of gateways that can be used to terminate calls towards the GSTN. The LS is the main entity that participates in Telephony Routing over IP. The LS is generally a point of contact for end users for completing calls to the telephony network. An LS may also be responsible for propagation of gateway information to other LS's. An LS may be coresident with an H.323 gatekeeper or SIP server, but this is not required. Internet Telephony Administrative Domain (ITAD): The set of resources (gateways and Location Servers) under the control of a single administrative authority. End users are customers of an ITAD. Provider: The administrator of an ITAD. Location Server Policy: The set of rules which dictate how a location server processes information it sends and receives via TRIP. This includes rules for aggregating, propagating, generating, and accepting information. End User Policy: Preferences that an end user has about how a call towards the GSTN should be routed. Peers: Two LS's are peers when they have a persistent association between them over which gateway information is exchanged.
Internal peers: Peers that both reside within the same ITAD. External peers: Peers that reside within different ITADs. Originating Location Server: A Location Server which first generates a route to a gateway in its ITAD. Telephony Routing Information Base (TRIB): The database of gateways an LS builds up as a result of participation in TRIP.
charge for use of these gateways. This may restrict usage of the gateway to those users who have, in some fashion, an established relationship with the gateway provider. Provider Policy: In all likelihood, an end user who wishes to make use of a gateway service will not compensate the gateway provider directly. The end user may have a relationship with an IP telephony service provider which acts as an intermediary to providers of gateways. The IP telephony service provider may have gateways of its own as well. In this case, the IP telephony service provider may have policies regarding the usage of various gateways from other providers by its customers. These policies must figure into the selection process. End User Policy: In some cases, the end user may have specific requirements regarding the gateway selection. The end user may need a specific feature, or have a preference for a certain provider. These need to be taken into account as well. Capacity: All gateways are not created equal. Some are large, capable of supporting hundreds or even thousands of simultaneous calls. Others, such as residential gateways, may only support one or two calls. The process for selecting gateways should allow gateway capacity to play a role. It is particularly desirable to support some form of load balancing across gateways based on their capacities. Protocol and Feature Compatibilities: The calling party may be using a specific signaling or media protocol that is not supported by all gateways. From these issues, it becomes evident that the selection of a gateway is driven in large part by the policies of various parties, and by the relationships established between these parties. As such, there cannot be a global "directory of gateways" in which users look up phone numbers. Rather, information on availability of gateways must be exchanged by providers, and subject to policy, made available locally and then propagated to other providers. This would allow each provider to build up its own local database of available gateways - such a database being very different for each provider depending on policy. From this, we can conclude that a protocol is needed between administrative domains for exchange of gateway routing information. The protocol that provides these functions is Telephony Routing over IP (TRIP). TRIP provides a specific set of functions:
o Establishment and maintenance of peering relationships between providers; o Exchange and synchronization of telephony gateway routing information between providers; o Prevention of stable routing loops for IP telephony signaling protocols; o Propagation of learned gateway routing information to other providers in a timely and scalable fashion; o Definition of the syntax and semantics of the data which describe telephony gateway routes. TRIP can be generally summarized as an inter-domain IP telephony gateway routing protocol.
network, in order to determine the IP address of the PC corresponding to the user with the given phone number. The mapping function is a name to address translation problem, where the name happens to be represented by a string of digits. Such a translation function is best supported by directory protocols. This problem is not addressed by TRIP. The second of these mappings is needed to facilitate calls from traditional phones to IP terminals. When a user on the GSTN wishes to call a user with a terminal on the IP network, they need to dial a number identifying that terminal. This number could be an IP address. However, IP addresses are often ephemeral, assigned on demand by DHCP  or by dialup network access servers using PPP . The number could be a hostname, obtained through some translation of groups of numbers to letters. However, this is cumbersome. It has been proposed instead to assign phone numbers to IP telephony terminals. A caller on the GSTN would then dial this number as they would any other. This number serves as an alternate name for the IP terminal, in much the same way its hostname serves as a name. A switch in the GSTN must then access the IP network, and obtain the mapping from this number to an IP address for the PC. Like the previous case, this problem is a name to address translation problem, and is best handled by a directory protocol. It is not addressed by TRIP. The first mapping function, however, is fundamentally an address to route translation problem. It is this problem which is considered by TRIP. As discussed in Section 3, this mapping depends on local factors such as policies and provider relationships. As a result, the database of available gateways is substantially different for each provider, and needs to be built up through specific inter-provider relationships. It is for this reason that a directory protocol is not appropriate for TRIP, whereas it is appropriate for the others. 6]. However, there are important differences between BGP and TRIP: o TRIP runs at the application layer, not the network layer, where BGP resides. o TRIP runs between servers which may be separated by many intermediate networks and IP service providers. BGP runs between routers that are usually adjacent.
o The information exchanged between TRIP peers describes routes to application layer devices, not IP routers, as is done with BGP. o TRIP assumes the existence of an underlying IP transport network. This means that servers which exchange TRIP routing information need not act as forwarders of signaling messages that are routed based on this information. This is not true in BGP, where the peers must also act as forwarding points (or name an adjacent forwarding hop) for IP packets. o The purpose of TRIP is not to establish global connectivity across all ITADs. It is perfectly reasonable for there to be many small islands of TRIP connectivity. Each island represents a closed set of administrative relationships. Furthermore, each island can still have complete connectivity to the entire GSTN. This is in sharp contrast to BGP, where the goal is complete connectivity across the Internet. If a set of AS's are isolated from some other set because of a BGP disconnect, no IP network connectivity exists between them. o Gateway routes are far more complex than IP routes (since they reside at the application, not the network layer), with many more parameters which may describe them. o BGP exchanges prefixes which represent a portion of the IP name space. TRIP exchanges phone number ranges, representing a portion of the GSTN numbering space. The organization and hierarchies in these two namespaces are different. These differences means that TRIP borrows many of the concepts from BGP, but that it is still a different protocol with its own specific set of functions.
access to the gateways owned by the other members of the clearinghouse. When a gateway belonging to one member makes a call, the clearinghouse plays a key role in determining which member terminates the call. TRIP can be applied here as the tool for exchanging routes between the members and the clearinghouse. This is shown in Figure 1. There are 6 member companies, M1 through M6. Each uses TRIP to send and receive gateway routes with the clearinghouse provider.
------ ------ | |------| | | M1 | | M2 | | |\ /| | ------ \ / ------ | \/ | | /\ |<-----TRIP ------ / \ ------ | |/ \| | | M3 | | M4 | | |------| | ------ ------ Figure 2: TRIP for Confederations In this application, there are a number of large providers of telephony gateways. Each of these resells its gateway services to medium sized providers. These, in turn, resell to local providers who sell directly to consumers. This is effectively a pyramidal relationship, as shown in Figure 3. ------ | | | M1 | | | ------ / \ <------- TRIP ------ ------ | | | | | M2 | | M3 | | | | | ------ ------ / \ / \ ------ ------ ------ | | | | | | | M4 | | M5 | | M6 | | | | | | | ------ ------ ------ Figure 3: TRIP for Wholesalers Note that in this example, provider M5 resells gateways from both M2 and M3.
(EUs) in ITAD2 through the front-end. The front-end is a non-TRIP protocol or mechanism by which the LS databases are accessed. In ITAD3, there are both EUs and gateways. The LS in ITAD3 learns about the gateways in ITAD1 through a potentially aggregated advertisement from the LS in ITAD2.
| |Intra-domain protocol \ / Local Gateways TRIP--> Gateways POLICY Gateways -->TRIP IN Out | \ / Telephony Routing Information Base Figure 5: Flow of Information in TRIP The TRIB built up in the LS allows it to make decisions about IP telephony call routing. When a signaling message arrives at a signaling server, destined for a telephone network address, the LS's database can provide information which is useful for determining a gateway or an additional signaling server to forward the signaling message to. For this reason, an LS may be coresident with a signaling server. When they are not coresident, some means of communication between the LS and the signaling server is needed. This communication is not specifically addressed by TRIP, although it is possible that TRIP might meet the needs of such a protocol. An ITAD must have at least one LS in order to participate in TRIP. An ITAD may have more than one LS, for purposes of load balancing, ease of management, or any other reason. In that case, communications between these LS's may need to take place in order to synchronize databases and share information learned from external peers. This is often referred to as the interior component of an inter-domain protocol. TRIP includes such a function. Figure 5 shows an LS learning about gateways within the ITAD by means of an intra-domain protocol. There need not be an intra-domain protocol. An LS may operate without knowledge of any locally run gateways. Or, it may know of locally run gateways, but through static configuration. An LS may also be co-resident with a gateway, in which case it would know about the gateway that it is co-resident with.
7]. The gateway can contain a Service Agent (SA), and the LS can act as a Directory Agent (DA). SLP defines procedures by which service information is automatically propagated to DA's from SA's. In this fashion, an LS can learn about gateways in the ITAD. An alternate mechanism for the intra-domain protocol is via the registration procedures of SIP or H.323. The registration procedures provide a means by which users inform a gatekeeper or SIP server about their address. Such a registration procedure could be extended to allow a gateway to effectively register as well. LDAP  might also be used for the intra-domain protocol. A gateway can use LDAP to add an entry for itself into the database. If the LS also plays the role of the LDAP server, it will be able to learn about all those gateways in its ITAD. The intra-domain protocol which is used may be different from IT administrative domain to IT administrative domain, and is a matter of local configuration. There may also be more than one intra-domain protocol in a particular ITAD. An LS can also function without an intra-domain protocol. It may learn about gateways through static configuration, or may not know of any local gateways.
LS's communicate with each other through persistent associations. An LS may be connected to one or more other LS's. LS's need not be physically adjacent or part of the same autonomous system. The association between a pair of LS's is normally set up administratively. Two LS's are configured to communicate with each other when their administrators have an agreement in place to exchange gateway information. While TRIP does not provide an autodiscovery procedure for peer LS's to discover each other, one could possibly be used. Such a procedure might be useful for finding a backup peer LS when a crash occurs. Alternatively, in an environment where the business relationships between peers become more standardized, peers might be allowed to discover each other through protocols like the Service Location Protocol (SLP) . Determination about whether autodiscovery should or should not be used is at the discretion of the administrator. The syntax and semantics of the messages exchanged over the association between LS's are dictated by TRIP. The protocol does not dictate the nature of the agreements which must be in place. TRIP merely provides a transport means to exchange whatever gateway routing information is deemed appropriate by the administrators of the system. Details are provided in the TRIP protocol specification itself. The rules which govern which gateway information is generated, propagated, and accepted by a gateway is called a location server policy. TRIP does not dictate or mandate any specific policy.
A routing object may have additional information which characterizes the service at the gateway. These attributes include things like protocols, features supported, and capacity. Greater numbers of attributes can provide useful information, however, they come at a cost. Aggregation becomes difficult with more and more information, impacting the scalability of the protocol. Aggregation plays a central role in TRIP. In order to facilitate scalability, routing objects can be combined into larger aggregates before being propagated. The mechanisms by which this is done are specified in TRIP. Aggregation of application layer routes to gateways is a non-trivial problem. There is a fundamental tradeoff between aggregatability and verbosity. The more information that is present in a TRIP routing object, the more difficult it is to aggregate. Consider a simple example of two gateways, A and B, capable of reaching some set of telephone numbers, X and Y, respectively. C is an LS for the ITAD in which A and B are resident. C learns of A and B through some other means. As it turns out, X and Y can be combined into a single address range, Z. C has several options. It can propagate just the advertisement for A, just the advertisement for B, propagate both, or combine them and propagate the aggregate advertisement. In this case C chooses the latter approach, and sends a single routing object to one of its peers, D, containing address range Z and its own address, since it is also a signaling server. D is also a signaling server. Some calling device, E, wishes to place a phone call to telephone number T, which happens to be in the address range X. E is configured to use D as its default H.323 gatekeeper. So, E sends a call setup message to D, containing destination address T. D determines that the address T is within the range Z. As D had received a routing object from C containing address range Z, it forwards the call setup message to C. C, in turn, sees that T is within range X, and so it forwards the call setup to A, which terminates the call signaling and initiates a call towards the telephone network.
underlying network topologies, and of where the caller is located. This is something handled by QoS routing protocols, and is outside the scope of TRIP. However, gateway capacity is not dependent on the caller location or path characteristics. For this reason, a capacity metric of some form is supported by TRIP. This metric represents the static capacity of the gateway, not the dynamic available capacity which varies continuously during the gateways operation. LS's can use this metric as a means of load balancing of calls among gateways. It can also be used as an input to any other policy decision.
Administrators: Administrators may need to access the TRIB for maintenance and management functions. When a signaling server contacts the LS to route a phone number, it is usually doing so because a calling device (on behalf of an end user) has attempted to set up a call. As a result, signaling servers effectively act as proxies for end users when accessing the LS database. The communication between the calling devices and their proxies (the signaling servers) is through the signaling protocol. The advantage of this proxy approach is that the actual LS interaction is hidden from the calling device. Therefore, whether the call is to a phone number or IP address is irrelevant. The routing in the case of phone numbers takes place transparently. Proxy mode is also advantageous for thin clients (such as standalone IP telephones) which do not have the interfaces or processing power for a direct query of the LS. The disadvantage of the proxy approach is the same as its advantage - the LS interaction is hidden from the calling device (and thus the end user). In some cases, the end user may have requirements as to how they would like the call to be routed. These include preferences about cost, quality, administrator, or call services and protocols. These requirements are called the end user policy. In the proxy approach, the user effectively accesses the service through the signaling protocol. The signaling protocol is not likely to be able to support expression of complex call routing preferences from end users (note however, that SIP does support some forms of caller preferences for call routing ). Therefore, direct access from the end user to the LS can provide much richer call routing services. When the end user policy is presented to the LS (either directly or through the signaling protocol), it is at the discretion of the LS how to make use of it. The location server may have its own policies regarding how end user preferences are handled.
Some of the possible protocols for the front end are: Service Location Protocol (SLP): SLP has been designed to fit exactly this kind of function. SLP is ideal for locating servers described by a set of attributes. In this case, the server is a gateway (or next hop towards the gateway), and the attributes are the end user policy. The end user is an SLP UA, and the LS is an SLP DA. The Service Query is used to ask for a gateway with a particular set of attributes. Open Settlements Protocol (OSP): OSP  is a client server protocol. It allows the client to query a server with a phone number, and get back the address of a next hop, along with authorization tokens to use for the call. In this case, the server can be an LS. The routing table it uses to respond to OSP queries is the one built up using TRIP. Lightweight Directory Access Protocol (LDAP): LDAP is used for accessing distributed databases. Since the LS server contains a database, LDAP could be used to query it. Web Page: The LS could have a web front end. Users could enter queries into a form, and the matching gateways returned in the response. This access mechanism is more appropriate for human access, however. A signaling server would not likely access the front end through a web page. TRIP: The protocols discussed above are all of the query-response type. There is no reason why the LS access must be of this form. It is perfectly acceptable for the access to be through complete database synchronization, so that the entity accessing the LS database effectively has a full copy of it. If this approach were desired, TRIP itself is an appropriate mechanism. This approach has obvious drawbacks, but nothing precludes it from being done.
However, certain phone numbers don't represent GSTN terminals at all, but rather they represent services or virtual addresses. An example of such numbers are freephone and LNP numbers. In the telephone network, these are actually mapped to routable telephone numbers, often based on complex formulae. A classic example is time-of-day- based translation. While nothing prevents a gateway from advertising reachability to these kinds of numbers, this usage is highly discouraged. Since TRIP is a routing protocol, the routes it propagates should be to routable numbers, not to names which are eventually translated to routable numbers. Numerous problems arise when TRIP is used to propagate routes to these numbers: o Often, these numbers have only local significance. Calls to a freephone number made from New York might terminate in a New York office of a company, while calls made from California will terminate in a California branch. If this freephone number is injected into TRIP by a gateway in New York, it could be propagated to other LS's with end users in California. If this route is used, calls may be not be routed as intended. o The call signaling paths might be very suboptimal. Consider a gateway in New York that advertises a ported number that maps to a phone in California. This number is propagated by TRIP, eventually being learned by an LS with end users in California. When one of them dials this number, the call is routed over the IP network towards New York, where it hits the gateway, and then is routed over the GSTN back to California. This is a waste of resources. Had the ported number been translated before the gateway routing function was invoked, a California gateway could have been accessed directly. As a result, it is more efficient to perform translations of these special numbers before the LS routing databases are accessed. How this translation is done is outside the scope of TRIP. It can be accomplished by the calling device before making the call, or by a signaling server before it accesses the LS database.
ITADs, causing the problem to potentially spread. As a result, mutual authentication of peer LS's is critical. Furthermore, message integrity is required. TRIP messages may contain potentially sensitive information. They represent the routing capabilities of an ITAD. Such information might be used by corporate competitors to determine the network topology and capacity of the ITAD. As a result, encryption of messages is also supported in TRIP. As routing objects can be passed via one LS to another, there is a need for some sort of end to end authentication as well. However, aggregation will cause the routing objects to be modified, and therefore authentication can only take place from the point of last aggregation to the receiving LS's.  International Telecommunication Union, "Visual telephone systems and equipment for local area networks which provide a non- guaranteed quality of service," Recommendation H.323, Telecommunication Standardization Sector of ITU, Geneva, Switzerland, May 1996.  Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999.  Arango, M., Dugan, A., Elliott, I., Huitema, C. and S. Pickett, "Media Gateway Control Protocol (MGCP) Version 1.0", RFC 2705, October 1999.  Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.  Simpson, W., "The Point-to-Point Protocol (PPP)," STD 51, RFC 1661, July 1994.  Rekhter Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995.  Veizades, J., Guttman, E., Perkins, C. and S. Kaplan, "Service Location Protocol", RFC 2165, June 1997.
 Yeong, W., Howes, T. and S. Kille, "Lightweight Directory Access Protocol", RFC 1777, March 1995.  Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service Location Protocol, Version 2", RFC 2608, June 1999.  Schulzrinne H. and J. Rosenberg, "SIP caller preferences and callee capabilities", Work in progress.  European Telecommunications Standards Institute (ETSI), Telecommunications and Internet Protocol Harmonization Over Networks (TIPHON), "Inter-domain pricing, authorization, and usage exchange," Technical Specification 101 321 version 1.4.2, ETSI, 1998.
Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.