One document matched: draft-ietf-iptel-gwloc-framework-03.txt
Differences from draft-ietf-iptel-gwloc-framework-02.txt
Internet Engineering Task Force iptel wg
Internet Draft J.Rosenberg,H.Schulzrinne
draft-ietf-iptel-gwloc-framework-03.txt Bell Labs/Columbia U.
June 10, 1999
Expires: December 1999
A Framework for a Gateway Location Protocol
STATUS OF THIS MEMO
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as work in progress.
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document serves as a framework for the Gateway Location Protocol
(GLP), which supports the discovery and exchange of IP telephony
gateway routing tables between providers. The document defines the
problem of gateway location, and motivates the need for the protocol.
It presents an architectural framework for GLP, defines terminology,
specifies the various protocol elements and their functions,
overviews the services provided by the protocol, and discusses how it
fits into the broader context of Internet telephony.
1 Introduction
This document serves as a framework for the Gateway Location Protocol
(GLP), which supports the discovery and exchange of IP telephony
gateway routing tables between providers. The document defines the
J.Rosenberg,H.Schulzrinne [Page 1]
Internet Draft GLP framework June 10, 1999
problem of gateway location, and motivates the need for the protocol.
It presents an architectural framework for GLP, 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,
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 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
J.Rosenberg,H.Schulzrinne [Page 2]
Internet Draft GLP framework June 10, 1999
the gateway location protocol. 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 receives via GLP. 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.
Gateway Information Base (GIB): The database of gateways an LS builds
up as a result of participation in GLP.
Peers: Two LS's are peers when they have a persistent connection
between them over which gateway information is exchanged.
Internal peers: Peers that both reside within the same ITAD.
External peers: Peers that reside within different ITADs.
Originating Location Server: A Location Server which first generates
a route to a gateway in its ITAD.
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.
J.Rosenberg,H.Schulzrinne [Page 3]
Internet Draft GLP framework June 10, 1999
The gateway is, in essence, a routing 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 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
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.
J.Rosenberg,H.Schulzrinne [Page 4]
Internet Draft GLP framework June 10, 1999
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 the Gateway Location
Protocol (GLP). GLP provides a specific set of functions:
o Establishment and maintenance of peering relationships between
providers
o Exchange and synchronization of gateway routing information
between providers
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
GLP can be generally summarized as an inter-domain IP telephony
gateway routing protocol.
4 Related Problems
At a high level, the problem GLP 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":
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.
J.Rosenberg,H.Schulzrinne [Page 5]
Internet Draft GLP framework June 10, 1999
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
network, in order to determine the IP address of the PC corresponding
to the user with the given phone number.
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.
As a result for both of these cases, 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.
The first mapping function, however, is fundamentally an address to
route translation problem. It is this problem which is considered by
GLP. 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 GLP, whereas it is appropriate for the others.
5 Relationship with BGP
J.Rosenberg,H.Schulzrinne [Page 6]
Internet Draft GLP framework June 10, 1999
GLP 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 GLP:
o GLP runs at the application layer, not the network layer,
where BGP resides.
o GLP runs between servers which may be separated by many
intermediate networks and IP service providers. BGP runs
between routers are usually adjacent.
o The information exchanged between GLP peers describes routes
to application layer devices, not IP routers, as is done with
BGP.
o GLP assumes the existence of an underlying IP transport
network. This means that servers which exchange GLP 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 GLP is not to establish global connectivity
across all ITADs. It is perfectly reasonable for there to be
many small islands of GLP 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. GLP 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 GLP borrows many of the concepts from
BGP, but that it is still a different protocol with its own specific
functions.
6 Example Applications of GLP
GLP is a general purpose tool for exchanging of IP telephony routes
J.Rosenberg,H.Schulzrinne [Page 7]
Internet Draft GLP framework June 10, 1999
between providers. GLP does not, in any way, dictate the structure or
nature of the relationships between those providers. As a result, GLP
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
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.
GLP can be applied here as the tool for exchanging routes between the
members and the clearinghouse. This is shown in Figure 1.
------ ------
| | | |
| M1 | GLP GLP | M2 |
| |\ | | /| |
------ \ | | / ------
\ \/ -------------- \/ /
------ \----| |----/ ------
| | | | | |
| M3 |--------| Clearinghouse|--------| M4 |
| | | | | |
------ /----| |----\ ------
/ -------------- \
------ / \ ------
| |/ \| |
| M5 | | M6 |
| | | |
------ ------
Figure 1: GLP in the Clearinghouse Application
There are 6 member companies, M1 through M6. Each uses GLP to send
and receive gateway routes with the clearinghouse provider.
J.Rosenberg,H.Schulzrinne [Page 8]
Internet Draft GLP framework June 10, 1999
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. GLP
would run between each pair of providers.
------ ------
| |------| |
| M1 | | M2 |
| |\ /| |
------ \ / ------
| \/ |
| /\ |<-----GLP
------ / \ ------
| |/ \| |
| M3 | | M4 |
| |------| |
------ ------
Figure 2: GLP for Confederations
6.3 Gateway Wholesalers
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.
Note that in this example, provider M5 resells gateways from both M2
and M3.
7 Architecture
Figure 4 gives the overall architecture of GLP.
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
J.Rosenberg,H.Schulzrinne [Page 9]
Internet Draft GLP framework June 10, 1999
------
| |
| M1 |
| |
------
/ \ <------- GLP
------ ------
| | | |
| M2 | | M3 |
| | | |
------ ------
/ \ / \
------ ------ ------
| | | | | |
| M4 | | M5 | | M6 |
| | | | | |
------ ------ ------
Figure 3: GLP for Wholesalers
is represented by the lines between the GW and LS elements in ITAD1
in the Figure. The LS's have connections with other LS's, over which
they exchange gateway information. These connections 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 the
gateway location protocol (GLP), the LS in ITAD2 learns about the two
gateways in ITAD1. This information is accessed by end users (EUs) in
ITAD2 through the front-end. The front-end is a non-GLP 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
J.Rosenberg,H.Schulzrinne [Page 10]
Internet Draft GLP framework June 10, 1999
ITAD1 ITAD2
----------------- ------------------
| | | |
| ---- | | ---- |
| | GW | | | | EU | |
| ---- \ ---- | | ---- / ---- |
| | LS | ---------------- | LS | |
| ---- ---- | / ---- \ ---- |
| | GW | / | /| | EU | |
| ---- | / | ---- |
| | / | |
------------------ / ------------------
/
/
--------- /----------
| | |
| ---- |
| | LS | |
| / ---- \ |
| ---- || ---- |
| | GW | || | EU | |
| ---- || ---- |
| ---- || ---- |
| | GW | / \ | EU | |
| ---- ---- |
| |
---------------------
ITAD3
Figure 4: GLP Architecture
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
J.Rosenberg,H.Schulzrinne [Page 11]
Internet Draft GLP framework June 10, 1999
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.
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 set 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 are required in order to
select a gateway with which communications can be established. End
J.Rosenberg,H.Schulzrinne [Page 12]
Internet Draft GLP framework June 10, 1999
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 GLP 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 GLP before the call is set up (as opposed to negotiated
or exchanged by the signaling protocols themselves). The philosophy
of GLP is to keep it simple, and to favor scalability above abundance
of information.
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 gateway location
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.
GLP does not dictate how these preferences are combined with those of
the provider to yield the final gateway selection. Nor does GLP
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 the gateway
location protocol. It is a logical device which has access to a
database of gateways, called the Gateway Information Base (GIB). This
database of gateways is constructed by combining the set of locally
available gateways and the set of remote gateways (learned through
GLP) 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 GLP) based on policy. As such, policy plays
J.Rosenberg,H.Schulzrinne [Page 13]
Internet Draft GLP framework June 10, 1999
a central role in the LS operation. This flow of information is shown
in Figure 5.
|
|Intra-domain protocol
\/
Local
Gateways
GLP--> Gateways POLICY Gateways -->GLP
IN Out
|
\/
Gateway
Information Base
Figure 5: Flow of Information in GLP
The GIB 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 GLP, although it is possible that
GLP might meet the needs of such a protocol.
An ITAD must have at least one LS in order to participate in the
gateway location protocol. 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. GLP 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
J.Rosenberg,H.Schulzrinne [Page 14]
Internet Draft GLP framework June 10, 1999
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.
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
GLP. This LS is called an originating LS for that gateway. When an LS
is not coresident with the gateway, the means by which the
information gets propagated is not within the scope of the gateway
location protocol. 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. 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 the gateway
location protocol. LS's within the same ITAD use GLP to synchronize
information amongst themselves. LS's within different ITADs use GLP
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.
J.Rosenberg,H.Schulzrinne [Page 15]
Internet Draft GLP framework June 10, 1999
LS's communicate with each other through persistent connections. 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
connection between a pair of LS's is set up administratively. There
is no autodiscovery procedure. Two LS's are configured to communicate
with each other when their administrators have an agreement in place
to exchange gateway information. The syntax and semantics of the
messages exchanged over this connection are dictated by the gateway
location protocol. The protocol does not dictate the nature of the
agreements which must be in place. The GLP 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 GLP protocol specification itself.
The rules which govern which gateway information is generated,
propagated, and accepted by a gateway is called a location server
policy. The gateway location protocol 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 which is the 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. How
the decision is made is at the discretion of the administrator, and
is embodied in the LS policy. The decision can be made based on
information learned through the GLP, or through any out of band
means.
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 GLP. In order to facilitate
scalability, routing objects can be combined into larger aggregates
before being propagated. The mechanisms by which this is done is
specified in GLP. Aggregation of application layer routes to gateways
J.Rosenberg,H.Schulzrinne [Page 16]
Internet Draft GLP framework June 10, 1999
is a non-trivial problem. There is a fundamental tradeoff between
aggregatability and verbosity. The more information that is present
in a GLP 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 route, 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
underlying network topologies, and of where the caller is located.
This is something handled by QoS routing protocols, and is outside
the scope of GLP.
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 the GLP. 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
J.Rosenberg,H.Schulzrinne [Page 17]
Internet Draft GLP framework June 10, 1999
Another useful attribute to propagate is cost metrics. These might
represent the amount a particular gateway might charge for a call.
Unfortunately, the set of cost structures is potentially unbounded,
ranging from the simple (flat rate), to the arbitrarily complex (time
and caller dependent, past usage dependent, destination dependent,
etc.). For this reason, the GLP does not attempt to define specific
cost structures.
10 The Front End
As a result of the GLP, the LS builds up a database (the GIB) 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
GLP 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 GIB. 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.
Administrators: Administrators may need to access the GIB 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)
J.Rosenberg,H.Schulzrinne [Page 18]
Internet Draft GLP framework June 10, 1999
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 about
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 [9]). 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. GLP 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.
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.
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
J.Rosenberg,H.Schulzrinne [Page 19]
Internet Draft GLP framework June 10, 1999
access, however. A signaling server would not likely access the
front end through a web page.
GLP: 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, GLP itself is an appropriate mechanism. This
approach has obvious drawbacks, but nothing precludes it from
being done.
11 Number Translations
The model for GLP is that of many gateways, each of which has some
set of phone numbers they are willing to terminate IP calls towards.
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.
However, certain phone numbers don't represent GSTN terminals at all,
but rather they represent services. An example of such numbers are
700, 800 and 900 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 discouraged. Since GLP 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 GLP is used to propagate routes
to these numbers:
o Often, these numbers have only local significance. Calls to an
800 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 800 number is
injected into GLP 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 an 800 number that maps to
a phone in California. This number is propagated by GLP,
eventually being learned by an LS with end users in
California. When one of them dials this number, the call is
J.Rosenberg,H.Schulzrinne [Page 20]
Internet Draft GLP framework June 10, 1999
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 800 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 GLP. 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 GLP. The GLP 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
ITADs, causing the problem to potentially spread. As a result, mutual
authentication of peer LS's is critical. Furthermore, message
integrity is required.
Since the relationships between LS's are based on pre-arranged
administrative relationships, shared secrets seem an appropriate
mechanism for the authentication and integrity.
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.
GLP 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 GLP.
13 Acknowledgments
The authors would like to thank Matt Squire and Hussein Salama for
their detailed comments on this document.
14 Changes from -02
o Added a problem definition and motivation section
J.Rosenberg,H.Schulzrinne [Page 21]
Internet Draft GLP framework June 10, 1999
o Added a section discussing the relationship with other "phone
number to IP address" mapping protocols
o Added a section discussing the differences between GLP and BGP
o Added a section giving example GLP configurations
o Added some additional definitions, including the term Gateway
Information Base (GIB) to represent the IP telephony
equivalent of the RIB
o Clarified that gateway capacity is not a dynamic metric
o Added a figure representing the flow of information in an LS
o Added acknowledgments section
o Added mention of the fact that GLP will include the equivalent
of I-BGP
o Made the concept of the front end more explicit, and clarified
that signaling servers can also access the front end
o Added GLP as a corner case front end protocol
o Added discussion of GLP usage with 800 numbers
15 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] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP:
session initiation protocol," Request for Comments (Proposed
Standard) 2543, Internet Engineering Task Force, Mar. 1999.
[3] M. Arango, A. Dugan, I. Elliott, C. Huitema, and S. Pickett,
"Media gateway control protocol (MGCP)," Internet Draft, Internet
Engineering Task Force, Feb. 1999. Work in progress.
[4] R. Droms, "Dynamic host configuration protocol," Request for
Comments (Draft Standard) 2131, Internet Engineering Task Force, Mar.
1997.
[5] W. Simpson and Editor, "The point-to-point protocol (PPP),"
Request for Comments (Standard) 1661, Internet Engineering Task
J.Rosenberg,H.Schulzrinne [Page 22]
Internet Draft GLP framework June 10, 1999
Force, July 1994.
[6] Y. Rekhter and T. Li, "A border gateway protocol 4 (BGP-4),"
Request for Comments (Draft Standard) 1771, Internet Engineering Task
Force, Mar. 1995.
[7] J. Veizades, E. Guttman, C. Perkins, and S. Kaplan, "Service
location protocol," Request for Comments (Proposed Standard) 2165,
Internet Engineering Task Force, June 1997.
[8] W. Yeong, T. Howes, and S. Kille, "Lightweight directory access
protocol," Request for Comments (Draft Standard) 1777, Internet
Engineering Task Force, Mar. 1995.
[9] H. Schulzrinne and J. Rosenberg, "SIP caller preferences and
callee capabilities," Internet Draft, Internet Engineering Task
Force, Mar. 1999. Work in progress.
16 Authors Addresses
Jonathan Rosenberg
Lucent Technologies, Bell Laboratories
101 Crawfords Corner Rd.
Holmdel, NJ 07733
Rm. 4C-526
email: jdrosen@bell-labs.com
Henning Schulzrinne
Columbia University
M/S 0401
1214 Amsterdam Ave.
New York, NY 10027-7003
email: schulzrinne@cs.columbia.edu
Table of Contents
1 Introduction ........................................ 1
2 Terminology ......................................... 2
3 Motivation and Problem Definition ................... 3
4 Related Problems .................................... 5
J.Rosenberg,H.Schulzrinne [Page 23]
Internet Draft GLP framework June 10, 1999
5 Relationship with BGP ............................... 6
6 Example Applications of GLP ......................... 7
6.1 Clearinghouses ...................................... 8
6.2 Confederations ...................................... 9
6.3 Gateway Wholesalers ................................. 9
7 Architecture ........................................ 9
8 Elements ............................................ 10
8.1 IT Administrative Domain ............................ 10
8.2 Gateway ............................................. 12
8.3 End Users ........................................... 13
8.4 Location Server ..................................... 13
9 Element Interactions ................................ 15
9.1 Gateways and Location Servers ....................... 15
9.2 Location Server to Location Server .................. 15
9.2.1 Nature of Exchanged Information ..................... 16
9.2.2 Quality of Service .................................. 17
9.2.3 Cost Information .................................... 17
10 The Front End ....................................... 18
10.1 Front End Customers ................................. 18
10.2 Front End Protocols ................................. 19
11 Number Translations ................................. 20
12 Security Considerations ............................. 21
13 Acknowledgments ..................................... 21
14 Changes from -02 .................................... 21
15 Bibliography ........................................ 22
16 Authors Addresses ................................... 23
J.Rosenberg,H.Schulzrinne [Page 24]
| PAFTECH AB 2003-2026 | 2026-04-24 08:28:12 |