One document matched: draft-ietf-iptel-gwloc-framework-00.txt
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 developing a protocol for IP
telephony gateway location. It defines the problem in detail, and
overviews features and requirements for a protocol solution. It also
defines some baseline terms and presents an architectural view of the
problem.
2 Introduction
While there seems to be agreement that a protocol mechanism is needed
[Page 1]
Internet Draft gwloc framework July 7, 1998
to assist in routing IP telephony calls to remote gateways, there is
not yet consensus on exactly what this means, or what the require-
ments for such a protocol are. This document defines the problem,
proposes an architecture for discussion, defines common terms, and
presents a set of requirements.
3 Problem Definition
We can state the problem in its most general terms as follows:
There exist some set of IP telephony gateways, each of which are
characterized by a set of attributes. An IP host, which we generi-
cally call a gateway location client, wishes to complete an IP tele-
phony call through one of these gateways. The client has requirements
concerning values for some of the attributes. Some protocol mechanism
is required to allow the client to determine at least one gateway
among the set which meet the criteria. As new gateways become opera-
tional, old ones go offline, or attributes of existing gateways
change, this information should become available to the client in an
automatic way through the protocol. The information is made available
by having other hosts, called gateway location servers, propagate
information about some subset of the gateways for which each has
authority. If this subset is of size 1, the gateway itself may act as
a server. Otherwise, some proxy which obtains information about the
gateways out of band may act as a server. The protocol must provide
for discovery. That is, it should be possible for a new client to
join the system, and be able to learn about the gateways advertised
by the various servers, without having to establish an explicit con-
nection with each server.
This general problem can be instantiated in a number of specific
instances, as defined below. These instances are not meant to be
exhaustive or required. The protocol generically defines operation
between gateway location clients and gateway location servers. Its
specific usage in any or none of the scenarios below is entirely the
choice of the implementor.
3.1 H.323 Gatekeeper to Gatekeeper Interzone
The gateway location protocol can be used with ITU H.323 [1]. This
scenario is depicted in Figure 1. There are a large number of zones,
each of which has one or more gatekeepers. Each gatekeeper is respon-
sible for some set of the gateways in each zone. Responsibility,
here, implies that the gatekeeper know (1) whether the gateway is up
or down, and (2) the attributes for each gateway. The means by which
this is known may be through RAS, using the gateway location protocol
again, on a smaller scale, as described below, or via some other
means, such as SNMP.
Each gatekeeper acts as both a gateway location client and gateway
location server. While acting as server, it distributes information
[Page 2]
Internet Draft gwloc framework July 7, 1998
about the gateways its responsible for, via the protocol mechanism.
This information is then obtained by the other gatekeepers, acting as
gateway location clients.
Zone 1 Zone 2 Zone 3 Zone N
---------- ---------- ---------- ----------
| | | | | | | |
| GW GW | | GW GW | | GW GW | | GW GW |
| | | | | | | |
| GW GW | | GW GW | | GW GW | .. | GW GW |
| | | | | | | |
| GK | | GK | | GK GK | | GK |
| /\ | | /\ | |/\ /\ | | /\ |
----||---- -----||---- -||---||-- -----||---
|| || || || ||
-||--------------||---------||---||-------------||--
| \/ \/ \/ \/ \/ |
| Protocol Operation |
| |
-----------------------------------------------------
Figure 1: Interzone Operation
As new zones come up, they can join protocol operation and automati-
cally learn about gateways in other zones.
To make use of the protocol, an H.323 terminal would make a gate-
keeper routed call through its local gatekeeper. The alias address
listed in the setup message would be a telephone number. The gate-
keeper receiving the setup would then make use of the gateway loca-
tion protocol, acting as a client, and determine the appropriate
gateway for completing the call. The attributes for this gateway
might include its gatekeeper. The setup message could then be for-
warded to this gatekeeper, which would finally forward the call to
the destination gateway. Call setup would then proceed normally for
the gatekeeper to gatekeeper routed call.
Alternatively, an H.323 terminal might send a RAS LRQ (Location
Request) message to its gatekeeper, containing the desired telephone
number in the alias address. The gatekeeper could then act as a gate-
way location client, and determine the gateway appropriate for reach-
ing the given number. The call signaling address of the gateway (or
its gatekeeper) can then be returned in the response to the LRQ.
[Page 3]
Internet Draft gwloc framework July 7, 1998
Note that the above diagram does not imply that all zones in the
Internet are participating in the protocol operation. It should be
possible to support many instances of the protocol, with some (possi-
bly overlapping) subset of zones participating in each instance.
Zones would only participate in an instance of the protocol if they
are interested in sharing gateway information with other zones par-
ticipating in that instance. For example, a set of service providers
may get together to form a confederation, sharing gateways and using
some coordinated billing agreements. There are many examples of such
confederations in existence today. The confederation may run a single
instance of the protocol. Each participating ISP would have its own
gatekeepers act as both gateway location clients and gateway location
servers in that instance. An ISP who is a member of multiple confed-
erations might participate in two instances of the protocol, one for
each confederation of which it is a member.
3.2 H.323 Intra Zone Discovery
The protocol can also be used to allow a gatekeeper to discover the
gateways inside of its own zone. This scenario is depicted in Figure
2
---- ---- ---- ----
| GW | | GW | | GW | | GW |
-|-- -|-- -|-- -|--
| | | |
\/ \/ \/ \/
------------------------------------------
| Protocol Operation |
------------------------------------------
| |
| |
\/ \/
---- ----
| GK | | GK |
---- ----
Figure 2: Intra Zone Discovery
Here, the gateways inside of the zone act as gateway location
clients, and the gatekeepers act as gateway location servers. As the
protocol is really engineered for wide area operation, its usage in
this scenario is more useful when a zone is extremely large,
[Page 4]
Internet Draft gwloc framework July 7, 1998
containing many gateways and gatekeepers. It is also most useful when
it is desired for each gatekeeper to learn about each gateway.
3.3 Wide Area SIP Operation
As it is desirable to make the gateway location protocol independent
of the underlying IP telephony signaling protocol, it can be used
with SIP [2] (or any of the many proprietary mechanisms still in
use). Its usage with SIP is depicted in Figure 3.
Domain a.com Domain b.com
- - - - - - - - - - - - - - - - - - - - -
| ---- ---- | | ---- ---- |
| GW | | GW | | GW | | GW |
| -|-- -|-- | | -|-- -|-- |
| | | |
| | ---- | | | | ---- | |
| | SV | | | | SV | |
| | ---- | | | | ---- | |
| /\ | | /\ |
| | | | | | | | | |
- - - - - - - - - - - - - - - - - - - - -
| | | | | |
\/ | \/ \/ | \/
------------------------------------------
| Protocol Operation |
------------------------------------------
Figure 3: SIP Operation
Here, gateways in each domain act as gateway location servers. They
each propagate information about their own attributes, via the proto-
col, over the wide area network. SIP Servers (SV in the diagram)
obtain these attributes. When a client (not shown) makes a call to
the PSTN, it forwards the SIP INVITE to its local proxy server, with
the Request URI and To field containing a telephone URL. This proxy
server can then use the protocol to determine the appropriate gate-
way. The gateway can then be returned to the client using a SIP redi-
rect response, or the server can forward the call to the gateway
directly, acting as a proxy.
4 Requirements
[Page 5]
Internet Draft gwloc framework July 7, 1998
Here, we discuss the requirements of the protocol to solve the
defined problem. Note that many of these are similar to the require-
ments for discovering wide area services in general [3]:
oMulti-criteria. The client desires a gateway which can be charac-
terized by a number of attributes. The client should be able to
express the desired attributes of the gateway, and get back a
gateway whose service meets the criteria. There should be no arbi-
trary restriction on the type, values, or number of attributes
which can potentially characterize a gateway. Obviously, some kind
of standardization of baseline attributes, and their syntax and
semantics, will be required for interoperability. However, it must
be possible for implementors to define and register their own
attributes. The protocol must provide a way to maintain minimum
interoperability when a gateway location client does not under-
stand some of the attributes sent by the server.
oLocation Independent. It should not be necessary for the gateway
location client to know the domain, zone, IP address, administra-
tor, or any other type of name of a gateway in order to locate and
use it.
oAuto Configured. It should be straightfoward to configure new
clients and servers to use the protocol. A new gateway should
automatically be discoverable, requiring no new configuration on
the part of existing clients, and little or no setting of
addresses or other parameters in the new gateway (or the server
representing it).
oRapid Availability. When a gateway is first brought on line, it
should become visible and accessible to clients rapidly.
oAutomated. The location process should be automated, and not rely
on interactive input from a user to satisfy a reasonable query.
However, the protocol should not prevent interactive sessions.
oRapid. The gateway location process should occur as rapidly as
possible. It is one component of many in the post-dial delay. It
is therefore desirable to avoid wide area, distributed database
searches in order to determine a suitable gateway.
oPolicy Support. The protocol must support policy. This means that
it must be possible for a client to eliminate certain gateways
from the selection process based on any desired combination of
attributes. It must also be possible for a server to specify pol-
icy, so that it can restrict the set of clients which can access
it.
[Page 6]
Internet Draft gwloc framework July 7, 1998
oWorldwide. The location of a desired gateway can be anywhere, as
can be the client. The protocol should be internationalized, sup-
porting queries and attributes in different languages.
oScalable. There can be millions of clients, servers, and gateways,
and the protocol will still operate correctly.
oMildly Dynamic. The attributes which characterize the service pro-
vided by the gateway do not change on small timescales. However,
they may change on larger timescales, and this should be handled
appropriately.
oSecurity. Encryption of messages must be supported. Authentication
and non-repudiation of attributes for gateways must be supported.
oMultiple Instances. It should be possible to run multiple
instances of the protocol, so that gateway location servers in an
instance make their gateways available only to those gateway loca-
tion clients running in the instance.
oSignaling Protocol Independent. The protocol should be independent
of the underlying IP telephony signaling protocol, be it H.323,
SIP, or some other proprietary protocol.
4.1 Possible Attributes
As the protocol involves selection of gateways based on attributes,
it is necessary to define a base set of attributes. Below are a par-
tial list of potential attributes:
oPhone Prefixes Allowed: The set of phone number prefixes which
this gateway is permitted to call.
oGateway Address: The IP address of the gateway.
oCodecs Supported: List of codecs supported by the gateway.
oSignaling Protocols Supported: List of signaling protocols and
versions supported.
oCost Plan: Some kind of cost structure describing how much the
gateway will bill for calls based on time of day, destination,
etc.
oBilling Methods: Tokens which describe the ways in which calls
through the gateway can be billed. Examples include credit and
debit cards, clearinghouse, e-cash, etc.
[Page 7]
Internet Draft gwloc framework July 7, 1998
oConfederation or ClearingHouse Memberships: Membership in various
confederations.
oAdministrator: Name of the corporation that administers the gate-
way.
oTotal Capacity: Number of lines supported by the gateway.
oAvailable Capacity: Estimate of the number of lines still avail-
able through the gateway.
oFeatures Supported: Supplementary telephony services supported by
the gateway, such as multiparty calling, transfer, and forward.
oGatekeeper: The gatekeeper for the gateway.
5 Security Considerations
Security is a critical requirement for a protocol solution. Encryp-
tion, authentication, and non-repudiation are minimal requirements.
6 Conclusion
We have defined the problem of gateway location, proposed a framework
for discussing solutions, and defined a set of key requirements for a
solution.
7 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.
[Page 8]
Internet Draft gwloc framework July 7, 1998
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."
8 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, Mar.
1998. Work in progress.
[3] J. Rosenberg, H. Schulzrinne, E. Guttman, and R. Moats, WASRV
architectural principles, Internet Draft, Internet Engineering Task
Force, Feb. 1998. Work in progress.
9 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 9]
| PAFTECH AB 2003-2026 | 2026-04-24 08:28:18 |