From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc2871.txt | 1403 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1403 insertions(+) create mode 100644 doc/rfc/rfc2871.txt (limited to 'doc/rfc/rfc2871.txt') diff --git a/doc/rfc/rfc2871.txt b/doc/rfc/rfc2871.txt new file mode 100644 index 0000000..349b21e --- /dev/null +++ b/doc/rfc/rfc2871.txt @@ -0,0 +1,1403 @@ + + + + + + +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. + +Abstract + + This 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. + +Table of Contents + + 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 + + + +Rosenberg & Schulzrinne Informational [Page 1] + +RFC 2871 TRIP Framework June 2000 + + + 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 + +1 Introduction + + This 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. + +2 Terminology + + We define the following terms. Note that there are other definitions + for these terms, outside of the context of gateway location. Our + definitions aren't general, but refer to the specific meaning here: + + Gateway: A device with some sort of circuit switched network + connectivity and IP connectivity, capable of initiating and + terminating IP telephony signaling protocols, and capable of + initiating and terminating telephone network signaling + protocols. + + End User: The end user is usually (but not necessarily) a human + being, and is the party who is the ultimate initiator or + recipient of calls. + + Calling Device: The calling device is a physical entity which has + IP connectivity. It is under the direction of an end user who + wishes to place a call. The end user may or may not be directly + controlling the calling device. If the calling device is a PC, + + + + + +Rosenberg & Schulzrinne Informational [Page 2] + +RFC 2871 TRIP Framework June 2000 + + + 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 [1]. + + SIP Server: The Session Initiation Protocol proxy or redirect + server defined in [2]. + + Call Agent: The MGCP call agent, defined in [3]. + + 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. + + + + + +Rosenberg & Schulzrinne Informational [Page 3] + +RFC 2871 TRIP Framework June 2000 + + + 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. + +3 Motivation and Problem Definition + + As IP telephony gateways grow in terms of numbers and usage, managing + their operation will become increasingly complex. One of the + difficult tasks is that of gateway location, also known as gateway + selection, path selection, gateway discovery, and gateway routing. + The problem occurs when a calling device (such as a telephony gateway + or a PC with IP telephony software) on an IP network needs to + complete a call to a phone number that represents a terminal on a + circuit switched telephone network. Since the intended target of the + call resides in a circuit switched network, and the caller is + initiating the call from an IP host, a telephony gateway must be + used. The gateway functions as a conversion point for media and + signaling, converting between the protocols used on the IP network, + and those used in the circuit switched network. + + The gateway is, in essence, a relaying point for an application layer + signaling protocol. There may be many gateways which could possibly + complete the call from the calling device on the IP network to the + called party on the circuit switched network. Choosing such a gateway + is a non-trivial process. It is complicated because of the following + issues: + + Number of Candidate Gateways: It is anticipated that as IP + telephony becomes widely deployed, the number of telephony + gateways connecting the Internet to the GSTN will become large. + Attachment to the GSTN means that the gateway will have + connectivity to the nearly one billion terminals reachable on + this network. This means that every gateway could theoretically + complete a call to any terminal on the GSTN. As such, the + number of candidate gateways for completing a call may be very + large. + + Business Relationships: In reality, the owner of a gateway is + unlikely to make the gateway available to any user who wishes to + connect to it. The gateway provides a useful service, and incurs + cost when completing calls towards the circuit switched network. + As a result, providers of gateways will, in many cases, wish to + + + +Rosenberg & Schulzrinne Informational [Page 4] + +RFC 2871 TRIP Framework June 2000 + + + 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: + + + + + +Rosenberg & Schulzrinne Informational [Page 5] + +RFC 2871 TRIP Framework June 2000 + + + 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. + +4 Related Problems + + At a high level, the problem TRIP solves appears to be a mapping + problem: given an input telephone number, determine, based on some + criteria, the address of a telephony gateway. For this reason, the + gateway location problem is often called a "phone number to IP + address translation problem". This is an over-simplification, + however. There are at least three separate problems, all of which can + be classified as a "phone number to IP address translation problem", + and only one of which is addressed by TRIP: + + o Given a phone number that corresponds to a terminal on a + circuit switched network, determine the IP address of a + gateway capable of completing a call to that phone number. + + o Given a phone number that corresponds to a specific host on + the Internet (this host may have a phone number in order to + facilitate calls to it from the circuit switched network), + determine the IP address of this host. + + o Given a phone number that corresponds to a user of a terminal + on a circuit switched network, determine the IP address of an + IP terminal which is owned by the same user. + + The last of these three mapping functions is useful for services + where the PC serves as an interface for the phone. One such service + is the delivery of an instant message to a PC when the user's phone + rings. To deliver this service, a switch in the GSTN is routing a + call towards a phone number. It wishes to send an Instant Message to + the PC for this user. This switch must somehow have access to the IP + + + +Rosenberg & Schulzrinne Informational [Page 6] + +RFC 2871 TRIP Framework June 2000 + + + 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 + [4] or by dialup network access servers using PPP [5]. 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. + +5 Relationship with BGP + + TRIP can be classified as a close cousin of inter-domain IP routing + protocols, such as BGP [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. + + + + + + +Rosenberg & Schulzrinne Informational [Page 7] + +RFC 2871 TRIP Framework June 2000 + + + 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. + +6 Example Applications of TRIP + + TRIP is a general purpose tool for exchanging IP telephony routes + between providers. TRIP does not, in any way, dictate the structure + or nature of the relationships between those providers. As a result, + TRIP has applications for a number of common cases for IP telephony. + +6.1 Clearinghouses + + A clearinghouse is a provider that serves as an exchange point + between a number of other providers, called the members of the + clearinghouse. Each member signs on with the clearinghouse. As part + of the agreement, the member makes their gateways available to the + other members of the clearinghouse. In exchange, the members have + + + +Rosenberg & Schulzrinne Informational [Page 8] + +RFC 2871 TRIP Framework June 2000 + + + 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. + +6.2 Confederations + + We refer to a confederation as a group of providers which all agree + to share gateways with each other in a full mesh, without using a + central clearinghouse. Such a configuration is shown in Figure 2. + TRIP would run between each pair of providers. + +6.3 Gateway Wholesalers + + ------ ------ + | | | | + | M1 | TRIP TRIP | M2 | + | |\ | | /| | + ------ \ | | / ------ + \ \ / -------------- \ / / + ------ \----| |----/ ------ + | | | | | | + | M3 |--------| Clearinghouse|--------| M4 | + | | | | | | + ------ /----| |----\ ------ + / -------------- \ + ------ / \ ------ + | |/ \| | + | M5 | | M6 | + | | | | + ------ ------ + + + Figure 1: TRIP in the Clearinghouse Application + + + + + + + + + + + +Rosenberg & Schulzrinne Informational [Page 9] + +RFC 2871 TRIP Framework June 2000 + + + ------ ------ + | |------| | + | 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. + + + + + + + +Rosenberg & Schulzrinne Informational [Page 10] + +RFC 2871 TRIP Framework June 2000 + + +7 Architecture + + Figure 4 gives the overall architecture of TRIP. + + ITAD1 ITAD2 + ----------------- ------------------ + | | | | + | ---- | | ---- | + | | GW | | | | EU | | + | ---- \ ---- | | ---- / ---- | + | | LS | ---------------- | LS | | + | ---- ---- | / ---- \ ---- | + | | GW | / | /| | EU | | + | ---- | / | ---- | + | | / | | + ------------------ / ------------------ + / + / + --------- /---------- + | | | + | ---- | + | | LS | | + | / ---- \ | + | ---- || ---- | + | | GW | || | EU | | + | ---- || ---- | + | ---- || ---- | + | | GW | / \ | EU | | + | ---- ---- | + | | + --------------------- + ITAD3 + + Figure 4: TRIP Architecture + + There are a number of Internet Telephony administrative domains + (ITAD's), each of which has at least one Location Server (LS). The + LS's, through an out-of-band means, called the intra-domain protocol, + learn about the gateways in their domain. The intra-domain protocol + is represented by the lines between the GW and LS elements in ITAD1 + in the Figure. The LS's have associations with other LS's, over which + they exchange gateway information. These associations are established + administratively, and are set up when the IT administrative domains + have some kind of agreements in place regarding exchange of gateway + information. In the figure, the LS in ITAD1 is connected to the LS in + ITAD2, which is in turn connected to the LS in ITAD3. Through + Telephony Routing over IP (TRIP), the LS in ITAD2 learns about the + two gateways in ITAD1. This information is accessed by end users + + + +Rosenberg & Schulzrinne Informational [Page 11] + +RFC 2871 TRIP Framework June 2000 + + + (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. + +8 Elements + + The architecture in Figure 4 consists of a number of elements. These + include the IT administrative domain, end user, gateway, and location + server. + +8.1 IT Administrative Domain + + An IT administrative domain consists of zero or more gateways, at + least one Location Server, and zero or more end users. The gateways + and LS's are those which are under the administrative control of a + single authority. This means that there is one authority responsible + for dictating the policies and configuration of the gateways and + LS's. + + An IT administrative domain need not be the same as an autonomous + system. While an AS represents a set of physically connected + networks, an IT administrative domain may consist of elements on + disparate networks, and even within disparate autonomous systems. + + The end users within an IT administrative domain are effectively the + customers of that IT administrative domain. They are interested in + completing calls towards the telephone network, and thus need access + to gateways. An end user may be a customer of one IT administrative + domain for one call, and then a customer of a different one for the + next call. + + An IT administrative domain need not have any gateways. In this case, + its LS learns about gateways in other domains, and makes these + available to the end users within its domain. In this case, the IT + administrative domain is effectively a virtual IP telephony gateway + provider. This is because it provides gateway service, but may not + actually own or administer any gateways. + + An IT administrative domain need not have any end users. In this + case, it provides "wholesale" gateway service, making its gateways + available to customers in other IT administrative domains. + + An IT administrative domain need not have gateways nor end users. In + this case, the ITAD only has LS's. The ITAD acts as a reseller, + learning about other gateways, and then aggregating and propagating + this information to other ITAD's which do have customers. + + + +Rosenberg & Schulzrinne Informational [Page 12] + +RFC 2871 TRIP Framework June 2000 + + +8.2 Gateway + + A gateway is a logical device which has both IP connectivity and + connectivity to some other network, usually a public or private + telephone network. The function of the gateway is to translate the + media and signaling protocols from one network technology to the + other, achieving a transparent connection for the users of the + system. + + A gateway has a number of attributes which characterize the service + it provides. Most fundamental among these are the range of phone + numbers to which it is willing to provide service. This range may be + broken into subranges, and associated with each, some cost metric or + cost token. This token indicates some notion of cost or preference + for completing calls for this part of the telephone number range. + + A gateway has attributes which characterize the volume of service + which it can provide. These include the number of ports it has (i.e., + the number of simultaneous phone calls it can support), and the + access link speed. These two together represent some notion of the + capacity of the gateway. The metric is useful for allowing Location + Servers to decide to route calls to gateways in proportion to the + value of the metric, thus achieving a simple form of load balancing. + + A gateway also has attributes which characterize the type of service + it provides. This includes, but is not limited to, signaling + protocols supported, telephony features provided, speech codecs + understood, and encryption algorithms which are implemented. These + attributes may be important in selecting a gateway. In the absence of + baseline required features across all gateways (an admirable, but + difficult goal), such a set of attributes is required in order to + select a gateway with which communications can be established. End + users which have specific requirements for the call (such as a user + requesting a business class call, in which case certain call features + may need to be supported) may wish to make use of such information as + well. + + Some of these attributes are transported in TRIP to describe + gateways, and others are not. This depends on whether the metric can + be reasonably aggregated, and whether it is something which must be + conveyed in TRIP before the call is set up (as opposed to negotiated + or exchanged by the signaling protocols themselves). The philosophy + of TRIP is to keep it simple, and to favor scalability above + abundance of information. TRIP's attribute set is readily extensible. + Flags provide information that allow unknown attributes to be + reasonably processed by an LS. + + + + + +Rosenberg & Schulzrinne Informational [Page 13] + +RFC 2871 TRIP Framework June 2000 + + +8.3 End Users + + An end user is an entity (usually a human being) which wishes to + complete a call through a gateway from an IP network to a terminal on + a telephone network. An end user may be a user logged on at a PC with + some Internet telephony software. The end user may also be connected + to the IP network through an ingress telephone gateway, which the + user accessed from telephone handset. This is the case for what is + referred to as "phone to phone" service with the IP network used for + interexchange transport. + + End users may, or may not be aware that there is a telephony routing + service running when they complete a call towards the telephone + network. In cases where they are aware, end users may have + preferences for how a call is completed. These preferences might + include call features which must be supported, quality metrics, owner + or administrator, and cost preferences. + + TRIP does not dictate how these preferences are combined with those + of the provider to yield the final gateway selection. Nor does TRIP + support the transport of these preferences to the LS. This transport + can be accomplished using the front end, or by some non-protocol + means. + +8.4 Location Server + + The Location Server (LS) is the main functional entity of TRIP. It + is a logical device which has access to a database of gateways, + called the Telephony Routing Information Base (TRIB). This database + of gateways is constructed by combining the set of locally available + gateways and the set of remote gateways (learned through TRIP) based + on policy. The LS also exports a set of gateways to its peer LS's in + other ITAD's. The set of exported gateways is constructed from the set + of local gateways and the set of remote gateways (learned through + TRIP) based on policy. As such, policy plays a central role in the LS + operation. This flow of information is shown in Figure 5. + + + + + + + + + + + + + + + +Rosenberg & Schulzrinne Informational [Page 14] + +RFC 2871 TRIP Framework June 2000 + + + | + |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. + + + + + + + + + + +Rosenberg & Schulzrinne Informational [Page 15] + +RFC 2871 TRIP Framework June 2000 + + +9 Element Interactions + +9.1 Gateways and Location Servers + + Gateways must somehow propagate information about their + characteristics to an LS within the same ITAD. This LS may, in turn, + further propagate this information outside of the ITAD by means of + TRIP. This LS is called an originating LS for that gateway. When an + LS nis not coresident with the gateway, the means by which the + information gets propagated is not within the scope of TRIP. The + protocol used to accomplish this is generally called an intra-domain + protocol. + + One way in which the information can be propagated is with the + Service Location Protocol (SLP) [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 [8] 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. + +9.2 Location Server to Location Server + + The interaction between LS's is what is defined by TRIP. LS's within + the same ITAD use TRIP to synchronize information amongst themselves. + LS's within different ITADs use TRIP to exchange gateway information + according to policy. In the former case the LS's are referred to as + internal peers, and in the latter case, external peers. + + + + + + +Rosenberg & Schulzrinne Informational [Page 16] + +RFC 2871 TRIP Framework June 2000 + + + 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) [9]. + 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. + +9.2.1 Nature of Exchanged Information + + The information exchanged by the LS's is a set of routing objects. + Each routing object minimally consists of a range of telephone + numbers which are reachable, and an IP address or host name which is + the application-layer "next hop" towards a gateway which can reach + that range. Routing objects are learned from the intra-domain + protocol, static configuration, or from LS's in remote ITAD's. An LS + may aggregate these routing objects together (merging ranges of + telephone numbers, and replacing the IP address with its own IP + address, or with the IP address of a signaling server with which the + LS is communicating) and then propagate them to another LS. The + decision about which objects to aggregate and propagate is known as a + route selection operation. The administrator has great latitude in + selecting which objects to aggregate and propagate, so long as they + are within the bounds of correct protocol operation (i.e., no loops + are formed). The selection can be made based on information learned + through TRIP, or through any out of band means. + + + + + +Rosenberg & Schulzrinne Informational [Page 17] + +RFC 2871 TRIP Framework June 2000 + + + 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. + +9.2.2 Quality of Service + + One of the factors which is useful to consider when selecting a + gateway is "QoS" - will a call through this gateway suffer + sufficiently low loss, delay, and jitter? The quality of a call + depends on two components - the QoS on the path between the caller + and gateway, and the capacity of the gateway itself (measured in + terms of number of circuits available, link capacity, DSP resources, + etc.). Determination of the latter requires intricate knowledge of + + + + +Rosenberg & Schulzrinne Informational [Page 18] + +RFC 2871 TRIP Framework June 2000 + + + 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. + +9.2.3 Cost Information + + Another useful attribute to propagate is a pricing metric. This might + represent the amount a particular gateway might charge for a call. + The metric can be an index into a table that defines a pricing + structure according to a pre-existing business arrangement, or it can + contain a representation of the price itself. TRIP itself does not + define a pricing metric, but one can and should be defined as an + extension. Using an extension for pricing means more than one such + metric can be defined. + +10 The Front End + + As a result of TRIP, the LS builds up a database (the TRIB) of + gateway routes. This information is made available to various + entities within the ITAD. The way in which this information is made + available is called the front end. It is the visible means by which + TRIP services are exposed outside of the protocol. + +10.1 Front End Customers + + There are several entities which might use the front end to access + the TRIB. These include, but are not limited to: + + Signaling Servers: Signaling servers receive signaling messages + (such as H.323 or SIP messages) whose purpose is the initiation + of IP telephony calls. The destination address of these calls + may be a phone number corresponding to a terminal on the GSTN. + In order to route these calls to an appropriate gateway, the + signaling server will need access to the database built up in + the LS. + + End Users: End users can directly query the LS to get routing + information. This allows them to provide detailed information on + their requirements. They can then go and contact the next hop + signaling server or gateway towards that phone number. + + + +Rosenberg & Schulzrinne Informational [Page 19] + +RFC 2871 TRIP Framework June 2000 + + + 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 [10]). 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. + +10.2 Front End Protocols + + There are numerous protocols that can be used in the front end to + access the LS database. TRIP does not specify or restrict the + possibilities for the front end. It is not clear that it is necessary + or even desirable for there to be a single standard for the front + end. The various protocols have their strengths and weaknesses. One + may be the right solution in some cases, and another in different + cases. + + + + + + +Rosenberg & Schulzrinne Informational [Page 20] + +RFC 2871 TRIP Framework June 2000 + + + 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 [11] 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. + +11 Number Translations + + The model for TRIP is that of many gateways, each of which is willing + to terminate calls towards some set of phone numbers. Often, this set + will be based on the set of telephone numbers which are in close + geographic proximity to the gateway. For example, a gateway in New + York might be willing to terminate calls to the 212 and 718 area + codes. Of course, it is up to the administrator to decide on what + phone numbers the gateway is willing to call. + + + + + + +Rosenberg & Schulzrinne Informational [Page 21] + +RFC 2871 TRIP Framework June 2000 + + + 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. + +12 Security Considerations + + Security is an important component in TRIP. The TRIP model assumes a + level of trust between peer LS's that exchange information. This + information is used to propagate information which determines where + calls will be routed. If this information were incorrect, it could + cause complete misrouting of calls. This enables a significant denial + of service attack. The information might also be propagated to other + + + +Rosenberg & Schulzrinne Informational [Page 22] + +RFC 2871 TRIP Framework June 2000 + + + 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. + +13 Acknowledgments + + The authors would like to thank Randy Bush, Mark Foster, Dave Oran, + Hussein Salama, and Matt Squire for their useful comments on this + document. + +14 Bibliography + + [1] 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. + + [2] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, + "SIP: Session Initiation Protocol", RFC 2543, March 1999. + + [3] Arango, M., Dugan, A., Elliott, I., Huitema, C. and S. Pickett, + "Media Gateway Control Protocol (MGCP) Version 1.0", RFC 2705, + October 1999. + + [4] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, + March 1997. + + [5] Simpson, W., "The Point-to-Point Protocol (PPP)," STD 51, RFC + 1661, July 1994. + + [6] Rekhter Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC + 1771, March 1995. + + [7] Veizades, J., Guttman, E., Perkins, C. and S. Kaplan, "Service + Location Protocol", RFC 2165, June 1997. + + + +Rosenberg & Schulzrinne Informational [Page 23] + +RFC 2871 TRIP Framework June 2000 + + + [8] Yeong, W., Howes, T. and S. Kille, "Lightweight Directory Access + Protocol", RFC 1777, March 1995. + + [9] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service + Location Protocol, Version 2", RFC 2608, June 1999. + + [10] Schulzrinne H. and J. Rosenberg, "SIP caller preferences and + callee capabilities", Work in progress. + + [11] 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. + +15 Authors' Addresses + + Jonathan Rosenberg + dynamicsoft + 72 Eagle Rock Avenue + First Floor + East Hanover, NJ 07936 + + Email: jdrosen@dynamicsoft.com + + + Henning Schulzrinne + Columbia University + M/S 0401 + 1214 Amsterdam Ave. + New York, NY 10027-7003 + + Email: schulzrinne@cs.columbia.edu + + + + + + + + + + + + + + + + + + +Rosenberg & Schulzrinne Informational [Page 24] + +RFC 2871 TRIP Framework June 2000 + + +16. Full Copyright Statement + + Copyright (C) The Internet Society (2000). 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 + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Rosenberg & Schulzrinne Informational [Page 25] + -- cgit v1.2.3