summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc2871.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc2871.txt')
-rw-r--r--doc/rfc/rfc2871.txt1403
1 files changed, 1403 insertions, 0 deletions
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]
+