IPTEL WG Jonathan Rosenberg
Bell Laboratories
Henning Schulzrinne
draft-ietf-iptel-gwloc-framework-01.txt Columbia U.
October 28, 1998
Expires: April 28, 1999
A Framework for a Gateway Location Protocol
STATUS OF THIS MEMO
This document is an Internet-Draft. Internet-Drafts are working docu-
ments of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute work-
ing 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 mate-
rial or to cite them other than as ``work in progress''.
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or
ftp.isi.edu (US West Coast).
Distribution of this document is unlimited.
1 Abstract
This document serves as a framework for a protocol for locating an IP
telephony gateway. It defines terminology, specifies the various
architectural elements and their functions, overviews the services
provided by the protocol, and discusses how it fits into the broader
context of Internet telephony.
2 Introduction
As IP telephony gateways grow in terms of numbers and usage, managing
[Page 1]
their operation will become increasingly complex. One of the diffi-
cult tasks is that of gateway location, also known as gateway selec-
tion, path selection, gateway discovery, and gateway routing. The
Internet Draft gwloc framework October 28, 1998
essence of the problem is that an ingress gateway or end user must
select a gateway to terminate a call towards the PSTN. This gateway
may lie in a remote administrative domain, and the selection of the
gateway may be based on a number of criteria.
To support discovery and location of gateways in remote administra-
tive domains, a protocol is being developed, call the Gateway Loca-
tion Protocol (GLP). This document serves as a framework for GLP. It
defines terminology used in the specification, specifies the various
architectural elements and their functions, overviews the services
provided by the protocol, and discusses how it fits into the broader
context of Internet telephony.
3 Terminology
We define the following terms. Note that there are other definitions
for these terms, outside of the context of gateway location. Our def-
initions aren't general, but refer to the specific meaning here:
oGateway: A device with some sort of PSTN connectivity and IP con-
nectivity, capable of initiating and terminating IP telephony sig-
naling protocols, and capable of initiating and terminating tele-
phone network signaling protocols.
oUser Agent (UA): An entity with IP connectivity which wishes to
place a call from an IP network to a user connected only via a
telephone network. The user agent can be an individual at a PC, an
intelligent IP peripheral, or a local gateway for a phone to phone
IP telephony call.
oGatekeeper: The H.323 gatekeeper element, defined in [1]
oSIP Server: The Session Initiation Protocol proxy server, defined
in [2].
oSignaling Server: A signaling server is an entity which is capable
of receiving signaling messages for some IP telephony signaling
protocol, such as H.323 or SIP, and forwarding the signaling mes-
sages to another signaling server or gateway. Generally speaking,
a gatekeeper or SIP server.
oLocation Server (LS): A logical entity with IP connectivity which
has knowledge of gateways that can be used to terminate calls
towards the PSTN. The LS is the main entity that participates in
the gateway location protocol. The LS is generally a point of con-
tact for user agents for completing calls to the telephony net-
work. An LS may also be responsible for propagation of gateway
information to other LS's. An LS may be coresident with an H.323
[Page 2]
Internet Draft gwloc framework October 28, 1998
gatekeeper of SIP server, but this is not required.
oAdministrative Domain: The set of gateways and Location Servers
under the control of a single administrative authority. User
agents are customers of an administrative domain.
oLocation Server Policy: The set of rules which dictate how a loca-
tion server processes information it receives via GLP. This
includes rules for aggregating, propagating, generating, and
accepting information.
oUser Agent Policy: Preferences that a user agent has about how a
call towards the PSTN should be routed.
4 Architecture
Figure 1 gives the overall architectural perspective of the gateway
location protocol.
AD1 AD2
----------------- ------------------
| | | |
| ---- | | ---- |
| | GW | | | | UA | |
| ---- \ ---- | | ---- / ---- |
| | LS | ---------------- | LS | |
| ---- ---- | / ---- \ ---- |
| | GW | / | /| | UA | |
| ---- | / | ---- |
| | / | |
------------------ / ------------------
/
/
--------- /----------
| | |
| ---- |
| | LS | |
| / ---- \ |
| ---- || ---- |
| | GW | || | UA | |
| ---- || ---- |
| ---- || ---- |
| | GW | / \ | UA | |
| ---- ---- |
| |
---------------------
[Page 3]
Internet Draft gwloc framework October 28, 1998
AD3
Figure 1: GLP Architecture
There are a number of administrative domains (AD'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 gate-
ways in their domain. The intra-domain protocol is represented by the
lines between the GW and LS elements in AD1 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 administrative domains have some kind of agree-
ments in place regarding exchange of gateway information. In the fig-
ure, the LS in AD1 is connected to the LS in AD2, which is in turn
connected to the LS in AD3. Through the gateway location protocol
(GLP), the LS in AD2 learns about the two gateways in AD1. This
information is accessed by user agents (UA's) in AD2 through the
front-end. The front-end is a non-GLP protocol or mechanism by which
UA's access the information. In AD3, there are both UA's and gate-
ways. The LS in AD3 learns about the gateways in AD1 through a poten-
tially aggregated advertisement from the LS in AD2.
The GLP is similar in flavor to inter-domain routing protocols, such
as BGP [3]. However, it differs in that the connectivity being
expressed is not network level, but represents application level
relationships. Furthermore, attributes play a more important role
here than in BGP because the protocol is an application, not network,
layer protocol.
5 Elements
The system for gateway location consists of a number of elements.
These include the administrative domain, user agent, gateway, and
location server.
5.1 Administrative Domain
An administrative domain consists of zero or more gateways, at least
one Location Server, and zero or more user agents. 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 administrative domain may not be the same as an autonomous system.
While an AS represents a set of physically connected networks, an
administrative domain may consist of elements on disparate networks,
[Page 4]
Internet Draft gwloc framework October 28, 1998
and even within disparate autonomous systems.
The user agents within an administrative domain are effectively the
customers of that administrative domain. They are interested in com-
pleting calls towards the telephone network, and thus need access to
gateways. A user agent may be a customer of one administrative domain
for one call, and then a customer of a different one for the next
call.
An administrative domain may not have any gateways. In this case, its
LS learns about gateways in other domains, and makes these available
to the user agents within its domain. In this case, the administra-
tive 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 administrative domain may not have any user agents. In this case,
it provides wholesale gateway service, making its gateways available
to customers in other administrative domains.
An administrative domain must have either gateways or user agents or
both.
5.2 Gateway
A gateway is a logical device which has both IP connectivity and con-
nectivity to some other network, usually a public or private tele-
phone 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 num-
bers 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.
Question - can this actually be a dollar cost value? There are seri-
ous issues with trying to do this. Cost plans can be arbitrarily com-
plex, and be based on many different currencies. Should we provide
some simple cost structures (unit of currency per unit time and flat
rate), or just use a preference, much like a weight metric associated
with a route.
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
[Page 5]
Internet Draft gwloc framework October 28, 1998
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 proto-
cols supported, telephony features provided, speech codecs under-
stood, 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
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.
5.3 User Agent
A user agent is an entity which wishes to complete a call through a
gateway from an IP network to a terminal on a telephone network. A
user agent may be a user logged on at a PC with some Internet tele-
phony software. The user agent may also be a telephone gateway,
dialed by a user from telephone handset. This is the case for the
phone to phone service using the IP network for long distance trans-
port.
User agents may, or may not be aware that there is a gateway location
service running when they complete a call towards the telephone net-
work. In cases where they are aware, user agents may have preferences
for how a call is completed. These preferences might include call
features which must be supported, quality metrics, owner or adminis-
trator, and cost preferences.
5.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 data-
base of gateways, and participates in the gateway location protocol.
As a participant, its job is to receive information about gateways
from other Location Servers, send information to other Location
Servers about gateways it knows about, and to aggregate and forward
information about gateways to other LS's.
The database built up in the LS allows it to make decisions about IP
telephony call routing. When a signaling message arrives at a signal-
ing server, destined for a telephone network address, the LS's
[Page 6]
Internet Draft gwloc framework October 28, 1998
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.
An LS is a representative for an administrative domain. An adminis-
trative domain must have at least one LS in order to participate in
the gateway location protocol. An administrative domain may have more
than one LS, for purposes of load balancing, ease of management, or
any other reason.
One or more of the LS's in an administrative domain may have knowl-
edge of the gateways run by the administrative domain. This knowledge
may be configured statically, learned through other protocols, or
acquired through gwloc by placing an LS coresident with the gateway,
allowing the gateway to participate in gwloc.
The information learned from other LS's may be used by an LS to aid
in routing calls which originate or transit through the administra-
tive domain.
A LS may be coresident with an H.323 gatekeeper, SIP server, or MGCP
call agent, but this need not be the case. When they are not coresi-
dent, some means of communication between the LS and the server,
gatekeeper, or call agent is needed. This communication is not
addressed by the gwloc protocol.
6 Element Interactions
6.1 Gateways and Location Servers
Gateways must somehow propagate information about their characteris-
tics to an LS which will further propagate this information. That 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 Ser-
vice Location Protocol (SLP) [4]. 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 administrative domain.
An alternate mechanism for the intra-domain protocol is via the reg-
istration procedures of SIP or H.323. The registration procedures
[Page 7]
Internet Draft gwloc framework October 28, 1998
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.
Other means exist as well. These might include LDAP [5], email, web
page, or human based means, such as a phone call or letter. The mech-
anism which is used may be different from administrative domain to
administrative domain, and is a matter of local configuration. The
only requirement for the gateway location protocol to operate effec-
tively is that this mechanism exist in some form.
6.2 Location Server to Location Server
The interaction between LS's is what is defined by the gateway loca-
tion protocol.
LS's communicate with each other through TCP 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 TCP 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 mes-
sages 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, nor does it dictate what informa-
tion is actually exchanged. The gwloc protocol merely provides a
transport means to exchange whatever information is deemed appropri-
ate by the administrators of the system.
The rules which govern which gateway information is generated, propa-
gated, and accepted by a gateway is called a location server policy.
The gateway location protocol does not dicate or mandate any specific
policy.
When an LS learns about a gateway through some means outside of the
gateway location protocol, and then propagates this information to
other LS's through the gateway location protocol, that LS is said to
be an originating LS for that gateway. This means that the LS is the
one responsible for determining when an update about the gateway
should be sent.
Two LS's may be connected even if they are owned by the same adminis-
trative authority. This may be done for a number of reasons. First,
an LS may be coresident with a gateway. As a result, this LS will
have knowledge about the state of the gateway, whether it is up or
down, and whether any attributes have changed. Thus, this LS is an
originating LS for the gateway it is coresident with. By connecting
[Page 8]
Internet Draft gwloc framework October 28, 1998
this LS with other LS's in the administrative domain, other LS's can
learn about gateways within the administrative system. Second, an
administrative domain may have multiple LS's for purposes of scala-
bility and load balancing. These may communicate with each other in
order to maintain a consistent database of gateways.
6.2.1 Nature of Exchanged Information
The information exchanged by the LS's is a set of gateway objects.
Each gateway object minimally consists of a range of telephone num-
bers which are reachable, and an IP address which is the next hop
towards a gateway which can reach that range. In the case of an LS
coresident with a gateway, this address will be its own address, and
the address range is the set of addresses which it can complete calls
to. This information is then sent from the gateway (through its
coresident LS) to another LS. This LS, in turn, may receive adver-
tisements from other LS's. An LS may aggregate this information
together, merging ranges of telephone numbers, and replacing the IP
address with its own IP address, or with the IP address of a signal-
ing server with which the LS is communicating.
Consider a simple example of two gateways, A and B, capable of reach-
ing some set of telephone numbers, X and Y, respectively. A and B are
each coresident with an LS. Both A and B are connected to C. A sends
C a gateway object containing range X, and IP address A. B sends C a
gateway object containing range Y, and IP address B. C aggregates
these together. As it turns out, X and Y can be combined into a sin-
gle address range, Z. C therefore sends a single gateway 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 client, 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 gateway object from C con-
taining 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.
A gateway object may have additional information which characterizes
the service at the gateway. These attributes include things like pro-
tocols, features supported, capacity, and cost metrics.
Aggregating advertisements together which contain these attributes is
nearly impossible. As a result, an LS must either pass the entire
gateway object unmodified, or, it it aggregates the gateway
[Page 9]
Internet Draft gwloc framework October 28, 1998
information together, remove the additional information before propa-
gating it.
6.2.2 Determining when to send an object
An LS is free to send an updated gateway object at its discretion.
Normally, an update is sent if (1) the LS is an originating LS, and
the attributes or state of the gateway has changed, (2) the LS has
received an updated object, and wishes to propagate it or change
other objects which it created as a result of aggregation, (3) the
policy of the LS has changed.
6.3 User Agents and Location Servers
The interaction between the user agents and location servers is also
outside the scope of the gateway location protocol. This interaction
is referred to as the front-end, as it provides the visible means by
which the gateway location protocol services are exposed.
A front end is required when an administrative domain has user
agents, and these user agents wish to complete calls to a telephone
network address. This can happen when a user sitting at a PC types a
telephone number into their IP telephony software, or when an ingress
gateway receives a call from a telephone wishing to complete a call
to another telephone. In both cases, the user agent must determine
where to send its signaling messages in order to complete the call.
In some cases, the user agent 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 user agent policy. This policy is dis-
tinct from the location server policy. The location server policy
includes the providers preferences about which gateways to accept and
make available to its customers: the user agents in its administra-
tive domain. The location server policy effectively takes the set of
all available gateways, and distills them into a list which is
acceptable to the provider. The user agent policy may then be used to
select among those gateways. When a user agent policy is expressed,
it is the discretion of the administrator whether to use or modify
this policy when selecting a gateway.
There are two models for the front end. These are called direct and
proxy modes.
6.3.1 Direct Mode
In direct mode, the user agent is aware that the call needs to termi-
nate on the telephone network, and it directly queries one of the
[Page 10]
Internet Draft gwloc framework October 28, 1998
LS's within the administrative domain for the address of a gateway or
signaling server which can route the call. This query can contain
policy from the user agent, or can just contain the telephone number
which is desired. The LS receives the query, and after consulting its
database, and any existing policy, returns zero or more addresses to
the user agent. The response to the user agent may also contain
parameters or attributes of the gateway if they are known.
Many protocols may be used for direct mode access. The Service Loca-
tion Protocol (SLP) is one example; its been designed to fit exactly
this kind of need. The user agent 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 (i.e., policy).
Other means exist. The web can be used, either through some kind of
search engine running based on the data at the LS, or through dynamic
web pages created from the LS database. This search could be auto-
mated or more interactive, as is normally done with web searches.
Once a response is received, the user agent can send its call setup
message to the signaling server or gateway indicated in the response.
The advantage of direct mode is that it gives the user agent the
ability to specify call by call policy. The policy can be arbitrarily
complex, depending on the services provided by the front end. The
disadvantage is that it requires more intelligence in the user agent.
This may not be appropriate for embedded devices, for example.
6.3.2 Proxy Mode
In proxy mode, the user agent doesn't worry about selecting or query-
ing for a gateway. The call setup message is sent to a proxy, either
the location server, or a signaling server which has access to the
database maintained by the LS. The LS or signaling server receives
the setup message, sees that it is to a gateway, and consults the
database to find the appropriate next hop signaling server or gateway
to terminate the call. This procedure happens transparently to the
user agent.
As part of the selection process, the LS or signaling server may
access a policy database containing preferences specified by the user
agent ahead of time. For example, a PC user may tell the administra-
tors that they would like calls towards the PSTN to be routed to
gateways run by provider X, or that calls should use the cheapest
gateway. When the LS or signaling server receives the call setup mes-
sage, this information can be taken into account when selecting a
next hop.
[Page 11]
Internet Draft gwloc framework October 28, 1998
Additionally, the signaling messages may themselves contain user
agent preferences about call routing.
The proxy mode front end is appropriate for thin clients, which can-
not express policy requirements on their own. It is also appropriate
when the administrator wants complete control over gateway selection.
It also has the advantage of making the fact that the call is a gate-
way call transparent to the user agent.
7 Security Considerations
There are a number of security requirements. First and foremost is
mutual authentication between LS's which are connected. This may be
through either public key or shared secret. Additionally, message
integrity of all exchanges is required. Encryption of messages is
also supported.
As gateway 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 gateway objects to be modified, and there-
fore authentication can only take place from the point of last aggre-
gation to the receiving LS's.
8 Conclusion
This document has provided a framework for a gateway location proto-
col. The major elements, and the relationships and protocols between
them, have been described.
9 Open Issues
oExpression of cost. Can or should we express cost structures in
the gateway advertisements?
oAggregation. The draft proposes that all attributes except tele-
phone number range and next hop be hop-by-hop attributes, and
shouldn't be propagated unless the advertisement is transparently
propagated (that is, not aggregated or de-aggregated). Is this the
right approach? Is there some middle ground here? Need we even
specify rules such as this?
oPath qualification. There is nothing in here about what has been
called path qualification. That is, does a path between two sig-
naling servers or LS's actually exist, and if so, does it have
sufficient quality to carry the call? This is tough, as it strays
within the realm of QoS routing and differentiated services, which
is out of scope.
[Page 12]
Internet Draft gwloc framework October 28, 1998
oAttributes. What attributes should be allow for a gateway?
10 Full Copyright Statement
Copyright (C) The Internet Society (1998). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implmentation 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 Soci-
ety 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 fol-
lowed, 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 MER-
CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
11 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 Standard-
ization Sector of ITU, Geneva, Switzerland, May 1996.
[2] M. Handley, H. Schulzrinne, and E. Schooler, SIP: session initia-
tion protocol, Internet Draft, Internet Engineering Task Force, May
1998. Work in progress.
[3] Y. Rekhter and T. Li, A border gateway protocol 4 (BGP-4),
Request for Comments (Draft Standard) 1771, Internet Engineering Task
Force, Mar. 1995. (Obsoletes RFC1654).
[4] J. Veizades, E. Guttman, C. Perkins, and S. Kaplan, Service loca-
tion protocol, Request for Comments (Proposed Standard) 2165,
[Page 13]
Internet Draft gwloc framework October 28, 1998
Internet Engineering Task Force, June 1997.
[5] W. Yeong, T. Howes, and S. Kille, Lightweight directory access
protocol, Request for Comments (Draft Standard) 1777, Internet Engi-
neering Task Force, Mar. 1995. (Obsoletes RFC1487).
12 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
[Page 14]
