Internet DRAFT - draft-agapi-ini-gwloc
draft-agapi-ini-gwloc
INTERNET-DRAFT C. Agapi
Noverber 18, 1998 C. Chiu
Expires: May 18, 1999 T. Chong
H. Phillips
B. Willingham
Information Networking Institute, CMU
Internet Telephony Gateway Location Service Protocol
draft-agapi-ini-gwloc-00.txt
Status of this Memo
This document is an Internet-Draft. 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."
To view the entire list of current Internet-Drafts, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
Europe), ftp.nic.it (Southern Europe), munnari.oz.au (Pacific Rim),
ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
Abstract
The development of IP to PSTN gateways has made it possible for users
of the two disparate networks to place 'telephone' calls between the
two networks with little effort. Users placing calls from an IP
network to the PSTN network must choose a gateway to act as a bridge
between the two networks. Selection of a gateway can be based on any
number of criteria, such as price, codecs, version, billing, etc. In
this draft we propose a gateway location service for this purpose.
The gateway location service protocol is an instantiation of the
Service Location Protocol that has been modified to run in a wide
area network across many administrative domains.
Table of Contents
1. Introduction ................................................... 2
Agapi, Chiu, Chong, Phillips, Willingham INI[Page 1]
Internet-Draft Gateway Location Service Protocol November 1998
1.1. Literature Review ............................................ 3
2. Overview of the Protocol ....................................... 4
2.1. Interaction of Clients with Gateway Location Servers ......... 5
2.2. Interaction of Gateways with Gateway Location Servers ........ 6
2.2.1. Possible Attributes ........................................ 7
2.3. Interactions between Gateway Location Servers ................ 9
2.4. Business Models ............................................. 10
3. Features of the Protocol ...................................... 11
3.1. Scalability ................................................. 11
3.2. GLS Service Load and Caching ................................ 14
3.3. Thrashing ................................................... 15
4. Overview of SLP ............................................... 16
4.1. Gateway Location Service as an SLP Service .................. 17
4.1.1. Protocol Overview ......................................... 17
4.1.2. Structure of Required GLSP Messages ....................... 20
4.1.2.1. SLP Message Header ...................................... 20
4.1.2.2. Service Request ......................................... 21
4.1.2.3. Service Reply ........................................... 23
4.1.2.4. Service Registration .................................... 22
4.1.2.5. Service Acknowledgment .................................. 25
4.1.2.6. Service Update .......................................... 25
4.1.2.7. Directory Agent Advertisement ........................... 25
4.1.2.8. Zone Transfers .......................................... 26
4.2. Modified SLP Messages ....................................... 26
4.2.1. Using XML for Service Registration ........................ 27
4.2.2. Attributes Descriptions ................................... 28
4.2.3. Extended URL for Service Reply ............................ 32
5. Security Considerations ....................................... 33
6. Conclusion .................................................... 35
7. Abbreviations ................................................. 36
8. Acknowledgments ............................................... 36
9. References .................................................... 37
1. Introduction
Traditional phone service uses a circuit switched network referred to
as the public switched telephone network or PSTN. For a call to be
established in this network, a path from the caller to the callee
must be reserved. This reserved connection consumes a constant
bandwidth of 64kbps along the path between the users. IP telephony
is fundamentally different because it uses a packet switched network
architecture. Calls can be established using reliable TCP
connections, and voice signals can be transmitted using unreliable
protocols like UDP. Our purpose here is not to argue the pros and
cons of these two architectures, but to stress the importance of
being able to make calls between the two networks.
Agapi, Chiu, Chong, Phillips, Willingham INI[Page 2]
Internet-Draft Gateway Location Service Protocol November 1998
In the recent past, IP telephony devices could only be used to place
calls to other users who operated similar IP devices. Similarly,
standard phones could only be used to call other users connected to
the PSTN. Fortunately, the need for interoperability was realized
and Gateways were developed that could connect the two networks.
These IP to PSTN Gateways act as protocol converters that can extract
encoded voice from an IP packet and transmit the signal as a standard
PSTN voice call. The Gateway can of course packetize PSTN signals
into IP packets also. The PSTN currently carries a vast majority of
telephony traffic. To achieve widespread use of Internet telephony,
there must be seamless interoperability between the two networks.
One difficulty in connecting the two networks is defining a name or
number for calling IP devices. This problem is being handled by
other groups and is frequently referred to as the "E.164 number
resolution problem", because they are trying to associate telephone
numbers (defined by ITU standard E.164) with Internet standard IP
addresses. One solution that is being examined is to designate a
special country code for use by IP telephony devices [1]. Another
approach is to use some sort of directory service, such as DNS, to
lookup an E.164 number and return the associated IP address [2].
This paper discusses what happens when an IP telephony user wants to
place a call to a PSTN user. We define a gateway location service
protocol so IP telephony users can find suitable gateways for
completing calls.
1.1. Literature Review
In the IETF draft "A Framework for a Gateway Location Protocol (GLP)"
[3], the proposed protocol defines a location server (LS) for
assisting the setup of Internet telephony calls. Location servers
and gateways are grouped into administrative domains and gateway
information may be propagated between location servers.
Each location server maintains a database of information about
gateways, which it can forward to other location servers. Every
gateway is defined to have an originating location server. The paper
proposes the use of the Service Location Protocol (SLP) for obtaining
information about gateways that are coresident with location servers
[4].
Location servers exchange gateway information, also called gateway
objects, amongst themselves. Each object contains at least a range
of reachable telephone numbers and a next hop IP address. Additional
information such as features supported, capacity, protocols, and cost
metrics may also be part of the gateway object.
In the paper "Internet Telephony Gateway Location", Rosenberg and
Agapi, Chiu, Chong, Phillips, Willingham INI[Page 3]
Internet-Draft Gateway Location Service Protocol November 1998
Schulzrinne introduced the Brokered Multicast Advertisements (BMA)
protocol architecture [5]. The BMA architecture is similar to the
Service Location Protocol (SLP), but is applied specifically to the
problem of gateway location over a wide area network.
The main benefits of IP telephony as compared to PSTN, are better
user interfaces, flexible integration with other tools such as web
browsers and personal mobility. If situated at the Network layer, a
gateway translates routing and addressing information. Application
layer gateways behave as end systems on both the IP and PSTN
networks. The issue of gateway location has often been compared to
DNS server location over the Internet. However, the nature of the
services provided by an IP gateway make such a comparison
inappropriate, because a DNS server relies on static configuration
while choosing an appropriate gateway involves dynamic variables such
as cost, blocking probability, and billing support. Whereas there
are no per-access charges associated with DNS lookups, there is a
cost associated with completing the call. Locating an IP gateway as
close to the PSTN callee as possible thus makes sense as this would
make the cheapest cost passed on to the client. In other cases, an
end user may opt for the best quality possible.
Thus, a good gateway location protocol must be dynamic, distributed,
bandwidth efficient, scalable, open to competitive business
environments, and secured. The pros and cons of several possible
solutions are discussed in the BMA paper.
From these considerations, BMA emerges as a hybrid, scalable and
robust mechanism. The BMA architecture is composed of a client and a
broker (whose role is similar to that of a Directory Agent in SLP).
Brokers are grouped into multicast groups, collecting announcements
and storing them in local databases. The BMA model makes use of
scalable wide area multicasting for gateway advertisements. The
broker handles the collection, storage and processing of
advertisements. This minimizes lookup delays and allows rapid updates
of advertisements. Multicast groups can be grouped according to
country codes or selection policies.
Based on any criteria, a broker can selectively drop advertisements
from certain gateways. Such policy-based selection is not possible
with single database storing. The main limitation of the BMA is the
number of records to be searched. To maintain scalability, the size
of the database must be restricted or they must be distributed.
2. Overview of the Protocol
Before the Gateway Location Service is used the IP telephony user
Agapi, Chiu, Chong, Phillips, Willingham INI[Page 4]
Internet-Draft Gateway Location Service Protocol November 1998
must know the E.164 number of the user she is calling. We then
assume that the IP telephony program she is running has discovered
from the resolution phase whether the call is going to an IP or PSTN
endpoint. In the trivial case where the number being called maps to
an IP address, the call will be set up using IP to IP protocols. In
the latter case where the number being called is for a PSTN endpoint
the program must invoke a protocol to look-up a directory service
provider that knows of all the available gateways.
In the Gateway Location Service protocol there are three types of
devices: clients (endpoints and Gatekeepers), Gateways, and Gateway
Location Servers. The ITU-T has defined the H.323 standard for
setting up calls between endpoints and gateways [6]. However, there
is currently no standard describing how endpoints are supposed to
find gateways. The following sections outline the Gateway Location
Service, a protocol for keeping track of gateways. We will first
describe the requirements for interaction between endpoints and GLSs.
Second we will discuss the communications between Gateways and a
GLSs. Finally, we briefly discuss the benefits of having a protocol
for communication between multiple Gateway Location Servers.
2.1. Interaction of Clients with Gateway Location Servers
Any call that starts on the Internet but ends on the PSTN must use a
gateway to convert between the disparate protocols. To discover
which gateway is best suited for an individual call the device
originating the call must become a client of the Gateway Location
Service. Common examples of such devices include computer telephony
programs, IP phones, and H.323 gatekeepers. While computer telephony
devices and gatekeepers have large amounts of memory and processing
power, most IP telephones are relatively simple, scaled-down devices.
For this reason, some IP telephones might rely on Gatekeepers to
represent them to Gateway Location Servers. Doing so would ease the
burden on IP telephones and might also lead to scalability benefits
by allowing caching at the Gatekeeper level.
When a user places a call from an IP phone he should not need to know
if the person he is calling uses an IP telephony device or a PSTN
phone. There are many organizations currently working on developing
this transparency, which is often referred to as E.164 resolution [1,
2, 7]. The idea is that the number will be sent to a system that
will determine if the end device is an IP or PSTN device. In the
former case the call can be completed between the endpoints directly
and in the latter case the call setup will be passed to a Gateway
Location Server.
Once it has been determined that the call must go though a gateway
there are many questions the caller might ask the gateway before a
Agapi, Chiu, Chong, Phillips, Willingham INI[Page 5]
Internet-Draft Gateway Location Service Protocol November 1998
connection can be established, such as: "what codecs do you support?"
or "what price will you charge me to reach the number and how do you
accept payment?" If a caller had to query every gateway for answers
to these questions at the start of every call he would have to wait
an unreasonable amount of time and would be causing wasteful network
traffic. It would be much better if there existed an omniscient
device that the caller could contact and say: "you know everything
about every gateway so tell me which one can complete my call using
codec g.711 at the lowest cost?" The Gateway Location Service, while
not omniscient, is designed to be able to answer queries from clients
with current information about which gateways are available for the
job. It is important to return results to the client quickly since
further call setup between the client and the gateway is necessary
before the call can begin.
A client must be able to verify the authenticity of the GLS that is
returning the results of its query. This will allow the client to
make sure the results are coming from a trusted entity. If
authentication is not used, a malevolent GLS operator could take
advantage of the customer in many ways. An easy to image scheme
would be to guide calls to an expensive gateway while claiming it is
the least expensive gateway available.
2.2. Interaction of Gateways with Gateway Location Servers
The protocol above describes in general terms the dissemination of
knowledge from the gateway location server to the endpoints. This
section discusses the assimilation of that knowledge from the
individual gateways. Every gateway should talk to every GLS to
ensure state consistency across the system. Although the GLSs can
communicate with each other, as explained in the next section, it is
better for each gateway to talk with all of them.
If the GLS is run on the public Internet, GLSs should accept
information from all gateways. To do otherwise could end in unfair
treatment of some gateways. For this reason, GLSs are not allowed to
aggregate or delete any records that they receive. It is therefore
very important that the information within the records sent by
gateways be compact. For example, a gateway serving only one area
code should send a single price for all calls that match that area
code instead of sending ten million phone numbers all showing the
same price.
The concept of a gateway as a distributed entity, consisting of a
gateway controller and various media gateways has also been
introduced [8]. The gateway controller will present itself to the
GLS as a single gateway, but will in fact be representing the pooled
resources of any number of media gateways. This was designed for
Agapi, Chiu, Chong, Phillips, Willingham INI[Page 6]
Internet-Draft Gateway Location Service Protocol November 1998
gateways within a single administrative domain so that the underlying
network deployment would not be obvious to other system providers and
for aggregation. It is acceptable for a gateway controller to
aggregate and delete information about the media gateways that it
represents because doing so does not defeat the interests of other
providers.
The use of gateway controllers in the GLS system has a beneficial
effect on the scalability of the protocol. Gateway controllers
function as a single point of contact for a large number of media
gateways, simplifying the communication of gateway information. The
total amount of information sent to the GLSs will be approximately
the same, but the number of transmissions will be reduced. There
could also be a reduction in the amount of information if the gateway
controller uses aggregation or policy to reduce the information. For
example, a gateway controller representing fifty media gateways that
are dispersed across the United States could send a single record for
calls to the US country code rather than fifty separate records.
This reduction in information simplifies the records stored in the
GLSs, which improves the speed of searches. Opportunities for
caching are also greatly enhanced when a single gateway controller
can reach a large number of phones via its gateways.
It is extremely important that this portion of the protocol be highly
secure because it directly effects the revenue of operating gateways.
If the protocol was left insecure, an attacker could distribute false
pricing information causing calls to be directed away from a gateway
thus eliminating any revenue for that provider. Encryption of the
records being sent is not necessary since that information will be
publicly available from the gateway location service. However,
methods of authorizing gateways and of authenticating records are
necessary.
The information that describes a gateway, such as domain name,
supported codecs, and signaling protocols, is relatively stable.
Because of this, the amount of information that needs to be sent to
the GLSs on a periodic basis is minimal. When the first contact
between a gateway and a GLS is made all of these nonvolatile
attributes will be stored at the GLS. After the gateway is entered
in the GLS's database, the gateway will continue to send periodic
updates with information about projected blocking probabilities and
changes in prices. Gateways are responsible for sending this
information to the GLSs. GLSs may advertise themselves to gateways,
but are not allowed to request information from them.
2.2.1. Possible Attributes
The Gateway Location Service selects appropriate gateways for clients
Agapi, Chiu, Chong, Phillips, Willingham INI[Page 7]
Internet-Draft Gateway Location Service Protocol November 1998
based on attribute information. The common ground is that these
attributes must be gateway-specific. Most of the potential attributes
discussed here were first introduced in the gwloc framework paper
[3]. However, we present a slightly different set of possible
attributes with corresponding justifications.
Identifier of Gateway: This will be the ID of the gateway service
provider. Some possible identifiers are IP address, DNS domain name,
or an ASCII string. Using an IP address as the identifier is not a
good idea since a gateway may have more than one IP appearance. An
X.400 Distinguished Name as it appears in the gateway's X.509 public
key certificate may be the most appropriate choice, since this ID can
be used to authenticate identity.
Signaling Protocol: There are many protocols, such as H.323 and SIP,
which may be used in setting up calls between endpoints and gateways.
Including this attribute allows endpoints to find only gateways with
which they share a common protocol.
Point of Contact: The point of contact often varies between
protocols. In the H.323 protocol the contact address could be a
gatekeeper representing a gateway. In the SIP protocol the point of
contact might be the terminating gateway itself. The point of
contact format could be a transport address or a URL. An explicit IP
listing is preferred since clients could avoid querying a DNS for IP
resolution during call setup, hence shortening the call setup time.
Autonomous System of Gateway: This is the BGP AS number of the
network the gateway is located on [9]. This attribute would likely be
used when some inference could be made about the expected path
quality based upon the AS of the caller and the gateway.
Quality of Service Capability: This attribute indicates what quality
of service protocols are supported by the gateway's ITSP. Some
possibilities are RSVP, diffserv, other bandwidth reservation
protocols or methods of providing virtual circuits.
Payment Method: If gateways are to be used for carrying public
traffic, they will likely need a method of collecting money from
their users. This attribute is a business issues and thus should not
be strictly specified by the protocol. It should allow gateways to
offer clients the choice of per-usage billing using credit cards or
electronic cash, or possibly the client would set up a billing
account in the gateway's administrative domain ahead of time.
E.164 Prefix: The phone number prefixes that the gateway can reach.
The gateway location service will use maximum prefix matching to
search its database and return appropriate results.
Agapi, Chiu, Chong, Phillips, Willingham INI[Page 8]
Internet-Draft Gateway Location Service Protocol November 1998
Blocking Probability: This parameter provides clients a way to know
the probability of the gateway refusing a call because all its lines
are busy. Clients can then make calls based on port availability of
the gateway. Unlike the gwloc framework which uses total and
available line probability, we define blocking probability as the
probability that not all trunks of the gateway are occupied during a
period of time. Defining the blocking probability this way allows
providers to keep the information about the capacity of their network
private. The averaging period used in calculating the blocking
probability should be short enough to provide useful state
information, but long enough to prevent excessive network traffic and
possible thrashing problems.
Price: Price defines the charges assessed by the gateway provider per
call. The gateway location service should allow gateways to update
their pricing plans at any time. This allows for dynamic pricing, but
the protocol also allows for the caching of gateway records to
improve scalability. The time between price updates and the
usefulness of caches is positively correlated, so implementers should
choose update intervals carefully.
Codecs Supported: This attribute indicates what codecs are supported
by a given prefix within a gateway.
Features Supported: The features supported attribute would hold
information about telephony services above basic call connection that
a gateway could perform, such as call forwarding or conference
calling.
Confederation: Memberships in various confederations or
clearinghouses.
Proximity: Proximity allows a caller to choose a gateway near to
herself, instead of near the callee. The issue here is picking a
gateway so the caller can make the best quality phone calls.
Shortening the geographic distance from the caller to the gateway
does not guarantee performance, the hop-counts between them and
bandwidth among interconnections set the result. We leave this issue
alone since these are not properties of the gateway but of the
caller-gateway pair, and as such can not readily be represented in a
gateway location server.
2.3. Interactions between Gateway Location Servers
Allowing gateway location servers to communicate among one another
speeds the propagation of state through out the system. For example,
when a new GLS comes online it can request a full transfer from
another GLS, instead of building its' own database from communication
Agapi, Chiu, Chong, Phillips, Willingham INI[Page 9]
Internet-Draft Gateway Location Service Protocol November 1998
with gateways. This feature is also useful for gatekeepers or other
GLS clients that operate as aggregation services. They can request a
full transfer of a GLS's records, but parse out and discard records
that do not match their criteria. This allows them to keep a
complete cache of gateways that meet their requirements without
maintaining direct communication with the gateways. Domain Name
Servers have a similar method of divulging information via zone
transfers.
A zone transfer from a functioning GLS to a new GLS acts as a
snapshot of the current state. If the new GLS wants to remain
current, it must actively seek information from gateways. The
easiest way for this to happen is for the new GLS to advertise itself
to each gateway that was mentioned in the zone transfer. Thus a GLS
starting from scratch can quickly and efficiently begin servicing
client queries.
The requirements for security of this portion of the protocol
parallel those described in the previous section.
2.4. Business Models
Different business models affect the interactions among all elements
involved in a gateway location service protocol. Moreover, business
model dominates the successful implementation of a gateway location
service protocol. We do not know what kind of business models will be
actually used, so we briefly discuss possible models and related
issues here.
Gateway service providers may form coalitions. In this model there is
not much interaction between GLSs. Each GLS would contain only a set
of gateway information come from the coalition to which it belongs.
So there will be limited choices left for end users or their agents
to make further decisions. The GLS could decide a single 'best'
gateway for its users. The amount of network traffic can be largely
reduced, and total response time is also shortened. The function of
GLS becomes less important in this model, and service providers could
even design proprietary protocols for their own use.
Another model is to treat GLSs as Clearinghouses. Every GLS will
provide services to users in its own domain, then exchange its
information with other GLSs periodically. The gateway location
problem is concentrated on GLS interactions in this model. The
interactions among GLSs could be something like the Network News
Transport Protocol, or DNS zone transfer. It is possible that users
and GLSs would be unable to get timely information, such as blocking
probability, and will not be able to respond to dynamic gateway price
updates. This model is similar to the one described in the gwloc
Agapi, Chiu, Chong, Phillips, Willingham INI[Page 10]
Internet-Draft Gateway Location Service Protocol November 1998
framework [15].
There can also be many administratively independent gateway domains.
Companies may prefer to run GLSs on their own. In this model the
number of GLSs is large and the network traffic between GLS and
gateway domains are heavy, hence multicast capabilities such as
described in BMA [5] is required. Since user base is reduced, GLS
could provide more heavy-load services for their clients, such as
sorting out a best gateway based on different criteria.
3. Features of the Protocol
This section is an overview of some problems that may be faced by the
implementers of this protocol. The Gateway Location Service, an
extension of the Service Location Protocol, is designed to work in a
wide area network. However, SLP was originally designed to run on
Local Area Networks under a single administrative domain. The
sections on scalability and caching discuss the benefits and
drawbacks of expanding SLP to a WAN environment. The GLS protocol is
designed so that endpoints can select gateways based on specific
criteria, such as price or codec. GLS also allows gateways to update
those attributes frequently. There is potential for thrashing to
occur if one of the attributes, price for instance, becomes the
dominant selection attribute in endpoint queries. If all endpoints
requested the lowest cost gateway, that gateway would soon run out of
capacity and start blocking calls. At this point all the calls would
be routed to the next lowest cost gateway that has a lower blocking
probability. The section on thrashing and update intervals further
explains this problem.
3.1. Scalability
The GLS protocol is meant to be an open standard, which may be
implemented and operated by anyone. It is likely that the same
people who operate gateways, which today includes ISPs, Corporations,
CLECs, ILECs, and IXCs will run Gateway Location Servers. Carriers
of IP or PSTN traffic will be the most likely GLS providers. The
number of gateways being tracked by the protocol is also highly
dependent on the entities running the gateways. Corporations are
likely to have private gateways that they operate the same as PBX
systems. These gateways would represent a small number of phones,
but there would be many of them. ILECs and IXCs would run carrier
grade gateways that could handle hundreds of thousands of
simultaneous calls. If carriers use gateway controllers to represent
their networks, a single gateway controller might represent millions
of phone numbers. The issues of who will run gateways and how many
they will run are difficult to quantify, so the following argument is
Agapi, Chiu, Chong, Phillips, Willingham INI[Page 11]
Internet-Draft Gateway Location Service Protocol November 1998
based upon available calling statistics obtained from the FCC.
When talking about gateways, it is important to remember that they
are merely bridges between the PSTN and IP networks. This means that
gateways will never be responsible for carrying one hundred percent
of call traffic. Lets consider the four possibilities of
origination-destination pairs; IP-IP, IP-PSTN, PSTN-IP, PSTN-PSTN.
Current call patterns place a huge majority of calls in the PSTN-PSTN
category, but IP traffic is becoming more popular. For the sake of
this argument, we will assume that all calls will eventually be IP-
IP. In the transition from the PSTN-PSTN dominated call scenario to
the IP-IP dominated call scenario, there will be a point where the IP
and PSTN networks carry the same number of calls per year. At this
point gateways will be responsible for carrying at most fifty percent
of all calls. The graph shown in Figure 1 below illustrates gateway
use assuming that the likelihood that a caller from an IP (PSTN)
phone wishes to reach a callee on the IP (PSTN) network is
proportional to the fraction of all phones that are IP (PSTN)
respectively.
The maximum number of calls that gateways will have to handle per
year can be predicted by making assumptions about the growth of
overall traffic and the growth of IP traffic. If use the statistic
that world wide call traffic increases by 12.1% percent per year and
assume that IP traffic will match PSTN traffic in fifteen years, we
can predict the maximum calls that must be handled by the gateways to
be around 6.25 trillion calls per year [10]. This assumes current
call levels of 2.25 trillion calls per year, and uses the argument
that at most fifty percent of calls will require gateways. If we use
an average call length of three minutes, there will be close to 12
million calls proceeding at any given time. To compensate for the
higher volume of calls during busy times of day this number should be
multiplied by 5, giving 60 million simultaneous calls.
The number of gateways and Gateway Location Servers required to
handle this volume of calls can be found with only a few more
assumptions. If the average capacity of a gateway is 500 calls, then
there will be at most 120 thousand gateways. Many of those will be
small corporate gateways and some will be very large carrier
gateways. The number of Gateway Location Servers will likely be
proportionate to this number, but the exact ratio will vary over
time. For this example, we assume a ratio of one GLS for every fifty
gateways, giving 2400 GLSs.
These numbers represent the estimated upperbound for the number of
gateways and GLSs. If we look more closely at our assumption about
which network calls terminate on, we will see that the percentage of
calls requiring a gateway will never reach 50%. This is because of a
Agapi, Chiu, Chong, Phillips, Willingham INI[Page 12]
Internet-Draft Gateway Location Service Protocol November 1998
selection bias caused by communities of interest. For example, if
the San Fransisco Bay Area is a community of interest, a large
percentage of calls originating from the Bay Area will also terminate
there. If San Fransisco becomes a 100% IP community, then a majority
of calls will be IP-IP, within-the-area calls. Only calls to PSTN
communities of interest would require a gateway. This argument is
also true for PSTN communities, leading to the overall conclusion
that IP-IP and PSTN-PSTN calls are favored over calls requiring a
gateway.
The amount of network traffic caused by running the GLS at this
upperbound scale can be calculated using the estimated numbers of
gateways and GLSs. For this part of the example, we will assume the
gateways and GLSs are arranged in a fully connected graph. This
means that each gateway is required to register with and send updates
to each GLS. If gateways send a 1kB packet every thirty minutes to
each GLS, then each gateway is generating 10.6kb/s of traffic. Each
GLS would receive a large number of updates every half-hour, equaling
530kb/s of traffic. The maximum network traffic for GLS registration
and updates will be 1.3Gb/s across the global IP infrastructure. The
amount of bandwidth consumed is inversely proportional to the amount
of time between messages. For example, if the update interval were
reduced to 1 minute instead of 30 minutes, then the total consumed
bandwidth would be almost 40Gb/s. It is therefore important to set
the timing variables in the protocol very carefully to prevent over
consumption of network resources. Although the 1.3Gb/s of traffic
might seem large by modern standards, it will likely seem negligible
to the networks of fifteen years from now.
Although this protocol is designed to run as a single large-scale
system, it is possible that the protocol could be adapted as an
internal standard run by private companies. For example, each IXC,
ILEC, and PTT might run its own private GLS, and there would only be
communications between administrative domains when an appropriate
business relationship had been established. We can illustrate the
effects of this model on network traffic caused by the protocol, by
assuming that the number of GLSs and gateways stays the same as
above, but that they are equally divided among the GLS providers. If
there are N providers, then the traffic on each provider's network
will equal the total network traffic calculated above divided by N
squared. This happens because each provider runs 1/Nth of the total
gateways and each gateway only need to communicate with 1/Nth of the
total GLSs. If we sum the traffic for all N providers, we see that
total network traffic for this model equals the traffic of the
previous model divided by N.
Other than bandwidth consumption, the major concern about using SLP
to run GLS is that SLP was designed to run on a LAN in a single
Agapi, Chiu, Chong, Phillips, Willingham INI[Page 13]
Internet-Draft Gateway Location Service Protocol November 1998
administrative domain. Expanding SLP to operate in a WAN environment
raises many manageability concerns. Security is probably the most
profound of these concerns and thus merits its own section (Sec. 5)
for an expanded discussion. Other problems focus mainly on discovery
and consistency across the system, such as how does a gateway find
out about GLSs to advertise to and visa versa. There is also the
possibility that the state carried by different GLSs may be different
at any given time. These concerns are addressed in Section 4.1, "GLS
as an SLP Service."
3.2. GLS Service Load and Caching
We have made the argument above that SLP can be scaled up to run in a
WAN environment. In this section we discuss how caching of
information can be used to reduce the load on the GLSs, making
large-scale implementation more feasible. Allowing service replies
from the GLSs to be cached by the endpoints will reduce the number of
queries that must be preformed by the GLSs. If we tap in to the
previous argument's findings, we can characterize the benefits of
using caching. Using the numbers of 6.25 trillion calls per year, a
busy hour factor of five, and 2400 GLSs, allows us to calculate a
service rate of 415 service requests per second per GLS during busy
hour calling. These service requests can be arbitrarily complex and
can require a large amount of processor cycles to resolve the query.
Using caching in the system will not speed queries, but it will
reduce the number of service requests.
If a single endpoint that is an IP phone caches all of its service
replies, it is not likely to experience many benefits. The benefits
will only come if the user calls a small set of numbers and calls
them more frequently than the service replies expire. If the caching
endpoint is a gatekeeper, the benefits of caching are more
substantial. For example, a corporation that has a gatekeeper
represent all of its IP phones would be able to cache information
about all of the corporate gateways employed by any of its callers.
So calls from headquarters to branch offices would not require
sending a service request to the GLS because the request could be
served out of the gatekeeper's cache.
The expected reduction in service requests that must be served by the
GLS can be calculated by making some assumptions about the likelihood
of an acceptable service reply being in an endpoint's cache. For
this argument we establish three service levels for caching; no
cache, small cache, and large cache. If local carriers are running
GLSs, it is likely that they will cache information about how to
terminate all local calls. For this reason we have used information
showing that 75% of calls are local, 10% are intralata, and the
remaining 15% are interlata, international, etc. [10]. So for this
Agapi, Chiu, Chong, Phillips, Willingham INI[Page 14]
Internet-Draft Gateway Location Service Protocol November 1998
argument, we assume 15% of endpoints do not use caching, 10% have a
small cache, and 75% use large caches, with respective cache hit
probabilities of 0%, 30%, and 80%. Under these assumptions, the
service rate of service requests per second per GLS during busy hour
calling is reduced to around 150. Recall that this is a worst case
analysis. Given any communities of interest the number of setup
queries will be greatly reduced.
For caching to be at all useful there must be a reasonably high
probability that a record will be in cache when a call setup attempt
occurs. The easiest way to increase the cache-hit probability is to
increase the lifetime of a record. This allows the caching device to
hold on to the record for a longer period of time. In the above
analysis the assumption that 75% of users will use large caches was
based on the statistic that 75% of calls are made to a local number.
For this type of calling we suspect the users will use a carriers
gatekeeper, and that such gatekeepers have large stable caches. This
is because the gatekeeper is run by the same entity that administers
many of the local gateways, and the entity can thus increase the
lifetime of gateway records to increase the usefulness of its caching
systems.
3.3. Thrashing
Ideally, each gateway should stand an equal chance of being selected
by a random user. In reality, every end-user's calling requirements
differ and may in fact show a certain level of bias towards some
attributes. If the number of users sharing the same preferences is
substantial, this may result in a specific gateway being requested by
more users than it can handle. This results in the gateway being
overloaded in a very short period of time and causes it to be blocked
since all ports are in use, forcing users to redirect their traffic
to alternative gateways. When the gateway becomes available again, it
will soon be flooded with requests, assuming that the users' profile
remain unchanged at any given random time. This phenomenon is known
as thrashing.
Thrashing occurs if most users' basis of gateway selection is common.
One possible cause of thrashing is when most users request to
complete their call through the lowest-cost gateway. This will
potentially route most network traffic to that gateway domain and
cause an oscillation problem as described.
It is possible that vendors would introduce business practices to
limit thrashing. For example, long term volume agreements with
clients would serve as an incentive to choose the same gateway over
another. A coalition can be formed in advance to predetermine the
vendor. However, this would shift the gateway location service to the
Agapi, Chiu, Chong, Phillips, Willingham INI[Page 15]
Internet-Draft Gateway Location Service Protocol November 1998
coalition, as they would wield much influence on which gateways will
be chosen. This results in a simplified version of the GLS.
A better solution would be to prescribe a specific mechanism within
the GLS that minimizes the likelihood of thrashing. If the blocking
probability were to be reported not as an absolute number but with
courser granularity, this would result in more gateways meeting the
same selection criteria. Thus, the selection of gateway would become
apparent to the user. What the user perceives as identical will in
fact be a random choice. This improves load balancing among the
gateways. In the same fashion, an increase in the granularity of
price has a dampening effect on competition between GLSs, as users
will have more information to make a selection.
If we require longer averaging periods for reporting blocking
probability, second-to-second gateway information updating would
become irrelevant. Coarser granularity for the update interval would
reduce oscillation. It also increases the likelihood of cache hits.
On the other hand, if there were less frequent updates, reported
information would more often be out of date or stale.
4. Overview of SLP
The Service Location Protocol (SLP) is simplifies the discovery and
use of network resources and is suited for establishing connections
between network peers that offer or consume generic services. An
important feature of the SLP is the provision for the dynamic
location of available resources.
Service Location Protocol defines three types of agents: 1) User
Agents, which acquire service handles for user applications; 2)
Service Agents, which advertise service handles 3) Directory Agents,
which collect together service handles in specified scopes.
Applications running at a host are represented by a user agent which
understands the service and resource needs of the application, and
each network service is represented by a service agent which makes it
available to user agents. SLP offers support for allowing network
resources to be collected together into administrative domains called
"scopes". Resources under a common administrative control are good
candidates for inclusion in the same scope. User agents are typically
configured (dynamically by DHCP, or as derived from initial computer
setup) with the name of their administrative scope. Afterwards, each
user agent includes its configured scope in service requests, which
enables access to services configured to operate within that scope.
Scopes may also indicate geographic proximity or network topology.
Service Location is also designed for both interactive and non-
Agapi, Chiu, Chong, Phillips, Willingham INI[Page 16]
Internet-Draft Gateway Location Service Protocol November 1998
interactive use. As user agents are deployed that can manage their
applications needs automatically, they can take advantage of the
robust and efficient mechanism afforded by Service Location. As
services are replaced or taken out of service, such User Agents will
simply discover alternate or replicated servers and continue
operation. On the other hand, interactive use of Service Location
gives the user the most complete possible information about the
services available and configured for use within their local domain.
The two main functions are: - Obtaining service handles for User
Agents - Maintaining the directory of advertised services
The three auxiliary functions are: - Discovering available service
attributes - Discovering available Directory Agents - Discovering the
available types of Service Agents
4.1. Gateway Location Service as an SLP Service
Terminology
User Agent (UA) A process working on the user's behalf to establish
contact with some service. The UA retrieves service information from
the Service Agents or Directory Agents. The User agents are the H.323
devices - clients (endpoints and Gatekeepers)
Service Agent (SA) A process working on the behalf of one or more
services to advertise the services. The Service Agents are the
Gateways.
Directory Agent (DA) A process which collects service advertisements.
There can only be one DA process running on a given host. The
Directory Agents are the Gateway Location Servers.
Service Type Each type of service has a unique Service Type string.
The Service Type is service:gwloc
URL: A Universal Resource Locator [8].
4.1.1. Protocol Overview
The User Agent (Gatekeeper or H.323. endpoint) sends a Unicast
Service Request to the Directory Agent (Gateway Location Server)
specifying the E.164 number it wants to reach and optionally a
predicate that specifies other criteria the Gateway(s) must satisfy.
Gateway Location Servers responds by sending a Unicast Service Reply
which contains the URLs of Gateways that can reach the specified
number and satisfies the criteria specified in the predicate.
Agapi, Chiu, Chong, Phillips, Willingham INI[Page 17]
Internet-Draft Gateway Location Service Protocol November 1998
+------------+ ---unicast SrvRqst---> +-------------------------+
| Gatekeeper | | Gateway location Server |
+------------+ <---Unicast SrvRply--- +-------------------------+
The URLs contain the information about the attributes specified in
the predicate.
SLP provides a feature that allows a User Agent to discover the
location of the Gateway Location Server. This is done either by
sending out a multicast Service Request with the scope specified or
consulting a certificate authority that signs certificates for the
GLS (see section on Security). Gateway Location Servers send back a
unicast Service Reply which contains information on their location.
Gateway Location Servers will frequently send out unsolicited
DAAdvert multicast messages
+------------+ --Multicast SrvRqst--> +-------------------------+
| Gatekeeper | | Gateway location Server |
| | <--unicast DAAdvert--- | |
+------------+ <--Multicast DAAdvert- +-------------------------+
SLP also provide the feature where Service Agents (Gateways)
advertise themselves by sending out SAAdvert messages. This must not
be done in the Gateway Location Service Protocol.
Gateways send information about the services that they provide to
Gateway Location Servers using the server-registration message. This
is a unicast SrvReg message. The attribute- list field in the message
will contain an XML document string that contains all this
information. The Gateway Location Server responds by sending back a
unicast SrvAck.
+------------+ ---unicast SrvReg----> +-------------------------+
| Gateway | | Gateway location Server |
+------------+ <---unicast SrvAck---- +-------------------------+
Gateways discover the locations of the Gateway Location Server in the
same way as Gatekeepers do.
+------------+ --Multicast SrvRqst--> +-------------------------+
| Gateway | | Gateway location Server |
| | <--unicast DAADvert--- | |
+------------+ <-Multicast DAAdvert-- +-------------------------+
List of Messages used by GWLSP
Message Type Abbrev F-ID Origin Dest. Type
Agapi, Chiu, Chong, Phillips, Willingham INI[Page 18]
Internet-Draft Gateway Location Service Protocol November 1998
Service Request SrvRqst 1 UA GWLS Unicast
Service Request SrvRqst 1 UA/GW GWLS Mulitcast
Service Reply SrvRply 2 GWLS GK Unicast
Service Registration SrvReg 3 GW GWLS Unicast
Service Acknowledge SrvAck 5 GWLS GW Unicast
DA Advertisement DAAdvert 8 GWLS GWLS/GK/UA Multicast
Service Deregister SrvDeReg 4
Attribute Request AttrRqst 6
Attribute Reply AttrRply 7
Service Type Request SrvTypeRqst 9
Service Type Reply SrvTypeRply 10
SA Advertisement SAAdvert 11
SLP provides this list of messages.
In SLP, SAs and UAs MUST support SrvRqst, SrvRply and DAAdvert. SAs
MUST also support SrvReg, SAAdvert and SrvAck.. For UAs and SAs,
support for other messages are OPTIONAL.
List of GWINFO Tags and corresponding Attributes:
+------------------------+------------------+-------------------+
| GWINFO tag | attribute | Possible Values |
+------------------------+------------------+-------------------+
| <dtd ver> | ver | |
+------------------------+------------------+-------------------+
| <valid start end> | start | |
| | end | |
+------------------------+------------------+-------------------+
| <id id> | id | |
+------------------------+------------------+-------------------+
| <as as> | as | |
+------------------------+------------------+-------------------+
| <contact> | Point of Contact | |
| <H.323 entry> | entry | H.323 Signaling |
| | | Protocol |
| <SIP entry> | | SIP signaling |
| | | Protocol |
| <URL entry> | | URL format |
+------------------------+------------------+-------------------+
| <payment payment> | payment | |
+------------------------+------------------+-------------------+
| <qos qos> | qos | RSVP diffserv |
+------------------------+------------------+-------------------+
| <crypto crypto> | crypto | DSA RSA |
+------------------------+------------------+-------------------+
| <prefix prefix> | prefix | |
Agapi, Chiu, Chong, Phillips, Willingham INI[Page 19]
Internet-Draft Gateway Location Service Protocol November 1998
+------------------------+------------------+-------------------+
| <blocking blocking | blocking | |
| period endtime> | period | |
| | endtime | |
+------------------------+------------------+-------------------+
| <codec codec> | codec | |
+------------------------+------------------+-------------------+
| <price excess unit | excess | |
| timing currency | unit | |
| | timing | |
| | currency | |
+------------------------+------------------+-------------------+
List of Attribute Parameters used by service request and reply:
+-----------------------+-------------------+-------------------+
| Attrparam | Scope | Comments |
+-----------------------+-------------------+-------------------+
| number | Query only | |
+-----------------------+-------------------+-------------------+
| prefix | GWINFO | |
+-----------------------+-------------------+-------------------+
| id | GWINFO | |
+-----------------------+-------------------+-------------------+
| as | GWINFO | |
+-----------------------+-------------------+-------------------+
| crypto | GWINFO | |
+-----------------------+-------------------+-------------------+
| blocking | GWINFO | |
+-----------------------+-------------------+-------------------+
| price | GWINFO | the price can be |
| excess | | calculated based |
| unit | | on parameters, or |
| timing | | return parameters |
| currency | | for further |
| | | processing |
+-----------------------+-------------------+-------------------+
| payment | GWINFO | |
+-----------------------+-------------------+-------------------+
| qos | GWINFO | |
+-----------------------+-------------------+-------------------+
| lm | Reply only | longest match |
+-----------------------+-------------------+-------------------+
4.1.2. Structure of Required GLSP Messages
4.1.2.1. SLP Message Header
Agapi, Chiu, Chong, Phillips, Willingham INI[Page 20]
Internet-Draft Gateway Location Service Protocol November 1998
All GLSP messages begin with the standard SLP header as required
(shown below)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Function-ID | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length, contd.|O|F|R| reserved |Next Ext Offset|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Extension Offset, contd.| XID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Language Tag Length | Language Tag \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.1.2.2. Service Request
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Location header (function = SrvRqst = 1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of <PRList> | <PRList> String \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of <service-type> | <service-type> String \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of <scope-list> | <scope-list> String \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of predicate string | Service Request <predicate> \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of <SLP SPI> string | <SLP SPI> String \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The user Agent (the H.323 gatekeeper) issues a Service Request
(SrvRqst). The structure of the SrvRqst is shown above.
<PRList> is the Previous Responder List
<service-type> String: This is the type of service required by the
Gatekeeper. In our case, the service-type is GWLOC <t> represents the
service type
<scope-list> String. The primary use of Scopes is to provide the
ability to create administrative groupings of services. Scope in
GWLSP will be used to defined as a GWLOC protected scope. This shall
be the default scope. Therefore, for our protocol, the Service
Request is considered to of DEFAULT scope. Hence our SCOPE is
DEFAULT <s> gives the <scope-list>
Agapi, Chiu, Chong, Phillips, Willingham INI[Page 21]
Internet-Draft Gateway Location Service Protocol November 1998
<predicate> is a LDAPv3 search filter [14]. In our protocol, this is
the field present, and where we specify our query. The values in this
field are compared to each registered service. If the attribute in
the filter has been registered with multiple values, the filter is
compared to each value and the results are ORed together. Note the
matching is case insensitive. For the predicate, the only compulsory
attribute for a non-empty predicate string shall be NUMBER.
<p> is the predicate string
Examples
<t>=service:gwloc <s>=DEFAULT <p>=(empty String)
This is a minimal request. It matches all GWLOC services advertised
<t>=service:gwloc <s>=DEFAULT <p>=(number="14122687195")
This is a request for the gateways that can reach the number
14122687195. A match will be done based on the number and the
longest prefix match found for this number. This returns the URLs of
the gateways that can reach this number. No conditions are specified
here.
<t>=service:gwloc <s>=DEFAULT <p>=(&(number="14122687195") (codec =
"G.711"))
This request specifies the codec required to complete the call. This
returns the URLs of Gateways that reach this location and support the
codec G.711.
<t>=service:directory-agent <s>=DEFAULT <p>=(service-type="GWLOC")
This request is used by the gatekeeper to discover the all the DAs
that are GWLOCs
These queries will be answered by the SrvRply message. The returned
information will be inserted into the URL entries as specified below.
Examples of more complex queries
These are examples of questions that we will like to answer. For
gateway with URL sip: //128.2.1.22:2333, supporting codec G.711,
What is the name of the Gateway?
What AS do you belong to?
What are your prices?
What currency do you accept?
What payment method do you accept?
Agapi, Chiu, Chong, Phillips, Willingham INI[Page 22]
Internet-Draft Gateway Location Service Protocol November 1998
What is your blocking probability?
What is the endtime for this blocking probability?
What are your QoS capabilities?
For what period is this valid?
However, due to the limitations of LDAPv3, questions like "What is
the cheapest Gateway that can reach phone number xxx xxx xxxx
supporting G.7xx?" cannot be answered easily. The concept of minimum
and maximum does not exist in LDAPv3, hence they should be avoided.
Queries using wild cards are supported.
Eg.
<t>service:gwloc<s>=DEFAULT<p>(&(number="14122687195")
(codec="G.711")(blocking<"0.50")(qos="RSVP"))
This is a request for a Gatekeeper that can complete a call to
14122687195, that supports G.711, has a blocking probability of less
than 0.5, and that supports RSVP.
4.1.2.3. Service Reply
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Location header (function = SrvRply = 2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code | URL Entry count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| <URL Entry 1> ... <URL Entry N> \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The service reply contains one or more URL Entries that satisfy the
SrvRqst and contain information that was requested in the service
request message. Several URLs may be returned that satisfy the
SrvRqst.
URL Entries
SLP reports URLs in protocol elements called URL Entries, which
associate a length, a lifetime, and possibly authentication
information along with the URL. The GWLSP uses URL Entries in two
ways. One is in the Service Reply message. When used here, we call
the URL entry the URL entry with Extended URL(s), since the URL
portion contains other information as well as the URL. The other use
is in Service Registration Messages, where the URL portion contains
just the URL. The URL syntax, as shown below can be used in both
cases. However we must not forget that these are two different
entities - URL entries for Service Registration Messages, and URL
Agapi, Chiu, Chong, Phillips, Willingham INI[Page 23]
Internet-Draft Gateway Location Service Protocol November 1998
Entries with Extended URLs for Service Reply Messages.
For the Service Reply message, the reported URL entries MUST contain
information about the attributes specified in the predicate of the
corresponding service request. Also, the Service Reply messages must
always contain the 'as no' along side the URL, whether or not it was
included in the Service Request predicate.
The valid start end attributes in the GWINFO will be used to
calculate the value for the Lifetime field.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Lifetime | URL Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|URL len, contd.| URL(var length incld attrib. values in SrvReq)\
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|# of URL auths | Auth. blocks (if any) \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Examples A response to the predicate in the Service Request Message
above
<t>service:gwloc<s>=DEFAULT<p>(&(number="14122687195")
(codec="G.711")(blocking<"0.50")(qos="RSVP"))
could be
http://gwl.cmu.edu:1212/?prefix="1412268"&lm="yes"&
as="345"&codec="G.711 G.723 G.729"&
blocking=".10"&qos="RSVP diffserv"
4.1.2.4. Service Registration
Gateways register with the Gateway Location Servers with messages
that contain the attributes of the service they provide.
<URL entry>
The <service-type> is the same service type specified in the Service
Request Message. In our case, the service-type is GWLOC
The <scope-list> is the same as specified in the Service Request
Message. We assign DEFAULT to <scope-list>
<attr-list> This will contain the XML document string that contains
all the information about the particular gateway. The format of XML
Agapi, Chiu, Chong, Phillips, Willingham INI[Page 24]
Internet-Draft Gateway Location Service Protocol November 1998
document string, and examples are given in section 4.XXX A detailed
description of the attributes is given in Section 4.YYYY.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Location header (function = SrvReg = 3) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| <URL-Entry> \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of service type string | <service-type> \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of <scope-list> | <scope-list> \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of attr-list string | <attr-list> \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|# of AttrAuths |(if present) Attribute Authentication Blocks...\
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.1.2.5. Service Acknowledgment
The Gateway Location Server (Directory Agent) returns a unicast
Service Acknowledgment message to the Gateway (Service Agent) on
receipt of a Service Request. It contains a 2-byte error code
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Location header (function = SrvAck = 4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.1.2.6. Service Update
We define our own message, Service update. It is identical to the
Service Registration Message in all respects except one. The REFRESH
flag in the header format is NOT set. This is termed incremental
service registration in SLP (see section 9.3. Incremental Service
Registration). The rule for incremental service registration We
believe signed updates are appropriate to reduce traffic, hence the
rule should be relaxed. We should allow incremental updates for GWLS
with restricted scope. This is discussed further in the section on
security.
4.1.2.7. Directory Agent Advertisement
Agapi, Chiu, Chong, Phillips, Willingham INI[Page 25]
Internet-Draft Gateway Location Service Protocol November 1998
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Location header (function = DAAdvert = 8) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code | DA Stateless Boot Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|DA Stateless Boot Time,, contd.| Length of URL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| URL \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length of <scope-list> | <scope-list> \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length of <attr-list> | <attr-list> \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length of <SLP SPI List> | <SLP SPI List> String \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # Auth Blocks | Authentication block (if any) \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.1.2.8. Zone Transfers
When a new Gateway Location Server comes online, it can request a
full transfer of information from another Gateway Location Server.
The New GWLS discovers existing GWLS's by listening for multicast
DAAdverts that they send out. The new GWLS responds to the first
DAAdvert it hears by sending out a unicast zone transfer message to
that GWLS. The old GWLS then transfers all the information it has to
the new GWLS. The new GWLS then sends out unicast DAAdverts to the
Gateways that it now has information on, so that they can in turn
send out Srv Reg messages to it to update its information. We
therefore have to define two new message types that will be used for
the zone transfer requests and the actual zone transfers.
4.2. Modified SLP Messages
As stated above, when applying SLP to provide gateway location
service, DA receives packets containing gateway information from SA
and sends packets containing contact information to UA upon queries.
To use SLP for the gateway location service, we need to modify or
clarify some SLP message formats. In this section we discuss the
following SLP message formats to tailor SLP to suit the gateway
location service:
Message Type Abbreviation Function-ID
-------------------- ------------ -----------
Service Reply SrvRply 2
Service Registration SrvReg 3
Agapi, Chiu, Chong, Phillips, Willingham INI[Page 26]
Internet-Draft Gateway Location Service Protocol November 1998
Service Update SrvReg 3
Note that the Service Update message has the same format with Service
Registration. All SLP messages begin with same header format, Service
Update is achieved by NOT setting the FRESH flag in header. This is
called incremental service registration in SLP.
4.2.1. Using XML for Service Registration
The Extensible Markup Language [13] is a meta-language that allow us
to design our own markup language. Information will be more
accessible and reusable, because the more flexible markup of XML. XML
document is more readable than flat attributes list and is clearer to
show relations among attributes by defining tag elements.
There might be an interoperability concern also. A H.323 gatekeeper
is likely to provide UA or SA service along with the Call Processing
Language [14] service, which provides some sort of scripts to
customize signaling operations. The IPTEL working group is also
proposing to use XML to define a language for CPL. The interaction
between gateway location and CPL services deserve further discussion.
We propose to use VALID XML here. A Document Type Definition is
required for valid XML documents. Service registration and update
should use the same DTD definition in order to support incremental
service registration easily.
The DTD for gateway location service is listed below. The detailed
description of gateway-specific attributes is explained in the next
section, 4.2.2.
<!-- Gateway Information DTD -->
<?xml version="1.0" standalone="no"?>
<!DOCTYPE gwinfo [
<!ELEMENT dtd>
<!ELEMENT valid (id, as?, contact?, payment?, qos?, crypto?,
prefix*)>
<!ELEMENT contact (h323?, sip?, url*)>
<!ELEMENT prefix (blocking?, codec?, price?)>
]>
When SA is composing a SrvReg message, the <attr-list> field is
replaced by the XML gateway document string. Here is a sample XML
document for service registration:
<!-- gwinfo registration -->
<dtd ver="0.1"></dtd>
<valid start="1998-10-20T08:00-5:00" end="1998-10-20T20:00-5:00">
Agapi, Chiu, Chong, Phillips, Willingham INI[Page 27]
Internet-Draft Gateway Location Service Protocol November 1998
<id id="Carnegie Mellon University"></id>
<as as="200"></as>
<contact>
<h323 entry="128.2.1.2:1234"></h323>
<sip entry="128.2.1.22:2333"></sip>
<url entry="http://gwc.cmu.edu:4545"></url>
<url entry="gwloc://gwc.cmu.edu:4321"></url>
</contact>
<payment payment="N/A"></payment>
<qos qos="RSVP diffserv"></qos>
<crypto crypto="RSA DSA"></security>
<prefix prefix="1412">
<blocking blocking=".1" period="60"
endtime="1998-10-20T07:00-5:00"></blocking>
<codec codec="G.711 G.723 G.729"></codec>
<price excess=".1" unit="0" timing="0"
currency="USD"></price>
</prefix>
<prefix prefix="1">
<price excess=".25" unit=".25" timing="60"
currency="USD"></price>
</prefix>
</valid>
For SrvReg incremental update messages, the format is basically the
same but it could includes only required and updated attributes:
<!-- gwinfo update -->
<dtd ver="0.1"></dtd>
<valid start="1998-10-20T20:00-5:00" end="1998-10-21T08:00-5:00">
<id id="Carnegie Mellon University"></id>
<prefix prefix="1">
<price excess="0" unit=".1" timing="60"
currency="USD"></price>
</prefix>
</valid>
4.2.2. Attributes Descriptions
<dtd ver>
The version number of the DTD of gateway information. This is a
required attribute. A valid XML document contains DTD definition
before document contents. Since the DTD of gateway information should
be well known, we use this tag to identify the DTD version used by SA
and DA. By this way we can reduce data packet size and provide the
capability for future function changes. If SA sends a DTD version
Agapi, Chiu, Chong, Phillips, Willingham INI[Page 28]
Internet-Draft Gateway Location Service Protocol November 1998
that is not supported by DA, DA will return an error code to SA.
Service update must follow the same DTD version used by the gateway
registration. Re-registration is required to change DTD versions.
ver
String of version number.
<valid start end>
Validation of the gateway information. This tells SA when this
information will be valid and expired.
start
ISO 8601 date/time format. The starting time when this information
become effective.
end
ISO 8601 date/time format. The expiration time.
<id id>
Identifier of the gateway. This is a required attribute for either
gateway information registration or update. This should exactly the
same id as the gateway's authentication-verification id. This id
tells the name of the gateway service provider, and also be used for
checking identity during authentication phase.
id
X.509 Distinguished Name
<as as>
Autonomous System number of the gateway domain.
as
AS Number.
<contact>
Point of Contact. The transport address or URL of the contact point.
Based on different signal protocols supported, the returning address
could be different. The choice of different signaling protocols
supported by the gateway is made available by analyzing those tags of
point of contacts. Explicit IP listing is preferred since user can
avoid querying DNS for IP resolution, hence shorten the entire call
setup time.
<h323 entry>
H.323 signaling protocol
<sip entry>
SIP signaling protocol
<url entry>
URL format
entry
The corresponding URL or transport address string. For example:
h323 entry="128.2.1.2:1234"
sip entry="128.2.1.22:2333"
Agapi, Chiu, Chong, Phillips, Willingham INI[Page 29]
Internet-Draft Gateway Location Service Protocol November 1998
url entry="http://gwc.cmu.edu"
url entry="iptel://gwc.cmu.edu:4321"
<payment payment>
Payment Method. There are many possible payment methods can be used
here. Users may have a default billing account as usually they have
for their PSTN services. Credit card and e-cash might also be used.
In the latter way, we can even be able to tell whom we are going to
pay for, by the billing company's merchant number. Since there are
different possibilities here, we do not have a specific syntax for
now. But this attribute must exist in the protocol.
payment
Left for further study
<qos qos>
Quality of Services capabilities supported.
qos
String of QoS protocols, separated by space. For example,
qos="RSVP diffserv"
<crypto crypto>
Security protocols supported by the gateway.
crypto
String of cryptographic standards, separated by space. For example,
crypto="RSA DSA"
<prefix prefix>
Prefix of E.164 numbers that the gateway provides services. DA will
use maximum prefix-matching to search the gateway information
database, so this is definitely a key in DA's database.
prefix
String of consecutive numbers
<blocking blocking period endtime>
Blocking Probability. The probability that not all trunks of the GW
are occupied during a period of time. The averaging period is the
time in minutes that the GW used for calculating blocking
probabilities, and the latest end time is also noted. Clients are
allowed to get blocking probability results that produced within a
certain amount of time. For example,
prefix blocking period endtime
------ -------- ------ ------------------------
1412 .1 60 1998-10-05T20:00:00-5:00
1 .05 120 1998-10-04T08:00:00-5:00
blocking
Agapi, Chiu, Chong, Phillips, Willingham INI[Page 30]
Internet-Draft Gateway Location Service Protocol November 1998
2-digit number representing percentage
period
4-digit number in unit of minutes. Averaging period.
endtime
ISO 8601 date/time format. The end time of the averaging period.
<codec codec>
Codec Support. This attribute indicates what kinds of codecs are
supported by some prefix of a gateway. Note that it is associated
with prefixs instead of an entire gateway. A gateway controller
domain can have many physically independent gateways, each in charge
of some prefixs respectively.
codec
String of codecs, separated by space. For example,
suppot="G.711 G.723"
<price excess unit timing currency>
Price. Here is the pricing model used by PSTN telephony. The cost for
setting up a call via an ITG is e + ceiling(t / u) * p, where e is
the excess charge (call originating chagre) for one call, u is the
charging unit of time (in seconds), and variable t is the total time
(also in seconds) for the duration of the call. Then p is the cost
per timing unit. The ISO currency code is also a parameter here.
prefix excess(e) unit(p) timing(u) currency
------ --------- ------- --------- --------
1412 .1 0 0 USD
1 .25 .25 60 USD
1 .25 .025 6 USD
The second and third prefix-1 examples illustrate different
representations of same pricing basis. Note that users should prefer
the later one since they pay less from smaller (more accurate) timing
units.
Another characteristic of the price attribute is the pricing
schedule. Prices may be different from business hours, economy/night
hours, weekend discounts, competitions... etc. This requirement is
incorporated into the <valid> tag in our XML gwinfo format, which
indicates the validation of gateway information (starting/ending
time). The date/time format conforms to the ISO 8601 standard.
Clients, or user agents, are not necessary to know contents in
different validation time windows. Instead, they may get an
expiration time for the current validation.
excess
3-digit number representing 1/1000 of currency unit. Setup charge per
Agapi, Chiu, Chong, Phillips, Willingham INI[Page 31]
Internet-Draft Gateway Location Service Protocol November 1998
call.
unit
3-digit number in 1/1000 of currency unit. The charging price per
timing unit.
timing
2-digit number in seconds. Timing unit.
currency
ISO 3-characters currency code
4.2.3. Extended URL for Service Reply
The way DA accessing gateway information in databases depends on its
own database implementation. DA is responsible to retrieve and search
its gateway database properly, based on UA's query criteria. Here we
discuss the required modifications on service request and service
reply messages for use by UA and DA interactions. The detailed
message formats and fields are introduced on section 4.1.
For the service request message, first we need to define an abstract
service type "gwloc" for the required <service-type> field in
SrvRqst. Then all URLs have the format "service:<abstract-
type>:<concrete-type>". For example,
service:gwloc:h323://128.2.1.2:1234
service:gwloc:sip://128.2.1.22:2333
service:gwloc:http://gwc.cmu.edu
service:gwloc:iptel://gwc.cmu.edu:4321
SrvRqst also defines a <predicate> list, which is a LDAPv3 search
filter. This allows UA to specify different searching attribute
parameters together in a single query. A required attribute parameter
is the phone number of the callee. Note that <number> is used to
match prefixes by DA, and is a new attribute parameter for the
predicate list only. Other attribute parameters are as defined in the
service registration section. Depending on different possible
business models used, an UA may prefer the DA to return one best
matched result or a list of URLs meeting its searching criteria.
However LDAP filter does not provide maximum/minimum operator to
constrain the searching criteria. This will prevent UA from getting
single best result.
To deal with this limitation, we can either prohibit the UA from
submitting max/min queries or add a max/min operator into LDAP
predicates. Note that searching for extreme values will require the
DA to do CPU-intensive sorting which decreases system performance
significantly. On the other hand, there is also an XML Query Language
specification (work just started) that might be able to allow us to
replace the LDAP predicate list in the future. We would assume both
Agapi, Chiu, Chong, Phillips, Willingham INI[Page 32]
Internet-Draft Gateway Location Service Protocol November 1998
single and multiple results can be returned and leave further issues
open here.
The SrvRply message contains a list of variable-length URL entries,
which associate a length, a lifetime, and possibly authentication
information with the URL. In order to give the UA more information
for it to use in selecting from among multiple service replies, we
need to associate extra attribute parameters to each URL, in the
following format:
srvtype://addrspec?attrparam="value"&
attrparam="value"&attrparam="value"...
Attribute parameters would be returned only for those attributes
which appear in the UA's service request predicate list. The UA can
further process the results using these attribute values. There are
two required attribute parameters for the extended URL. <prefix>
returns the matched prefix where this entry is found, and a new <lm>,
longest match, indicates if this prefix is already the longest prefix
in the DA database or not. This would be very useful for caching
purpose, UA can avoid querying DA again and again if it knows there
is no better prefix matching possible for new queries from end users.
5. Security Considerations
It is not the object of this paper to describe a security protocol
that could be used with the GLP. However, the importance of this
subject cannot be overlooked and we would like to comment on some of
the issues. Since the security of transmission is considered within
the H.323 protocol, the focus on security in the GLP falls on
authentication, trust, and their application in a real-time
environment.
Is there a need for authentication? Who needs to participate in
authentication to verify that the participating entities are who they
say they are? Just imagine a GW or DA impersonator, trying to route
all calls through him to reap great benefits. Definitely, the UA
needs to know that it is talking to a known DA. When initiating a
call, the users do not need to authenticate themselves when
contacting a DA, but the DA has to. The UA should be able to verify
a certificate of a DA but it is not necessary to have its own
public/private key or certificate. A private key and SLP [4] can be
used, but this mechanism will add computational burden and it would
not scale. Since it would be computationally expensive for the DA to
sign every service reply, one solution would be to use a scheme based
on secret sharing.
Agapi, Chiu, Chong, Phillips, Willingham INI[Page 33]
Internet-Draft Gateway Location Service Protocol November 1998
While the communication between the GW and the DA can be done using
ESP, it is not possible to do so over the UA - DA communication
because the UA does not need to have a certificate. One mechanism
that would solve the problem of proposing the secret could be the use
of a secure TCP/TLS channel. The UA proposes a secret by sending it
to the DA. The DA then replies with a signed message accepting the
secret. The DA needs a certificate from a Certified Authority (e.g.
VeriSign). The Certified Authority will distribute certificates to
all DAs and GWs. It is important to realize that during a call
setup, only one authentication takes place: only the DA needs to be
authenticated by the UA: there will be a one way identification of
the DA to the UA.
In the initial registration with the GLS, the GW needs to register
using public/private key. There is a cryptographic burden associated
with the signature using a private key. A solution would be to use a
lighter weight signature scheme that relies on secret sharing, using
SLP. Having the registration completed, a shared secret is
established. Furthermore, the initial registration includes a key
generation number and a key as attributes defined in XML. The shared
secret generated by the GW is authenticated by private key signature
authentication block on registration. The secret is protected during
the transmission using ESP. When sending advertisements, the GW has
to be authenticated by the DA. All updates transmitted from the GW to
the GLS should be signed using keyed HMAC, which will increase
performance, because HMAC is fast, lightweight having keyed hashing.
The GW should be authenticated asynchronously, at the time of the
advertisements and not during call setup. This provision will cut in
the call setup time.
Simply knowing who an entity is does not mean that that entity can be
trusted. The issue of trust is closely related to the business model
in which the entities of the GLP operate. Since interconnection is
mandatory as specified by the Telecommunications Act of 1996, almost
any entity (ISP, LEC, IXC, etc.) can operate a GW or a DA. In this
environment, even if authentication is valid, the question remains
whether to trust an entity or not. Consider for example the case
where a UA authenticates successfully the DA belonging to, say AOL.
Should the UA trust the entity to route the call to the best of its
knowledge? Is there a threat that AOL will try to benefit by
directing calls to some preferred GW? Consider another example in
which a Gateway of the company XYZ advertises a very good price. In
this free market environment, should a UA trust company XYZ? What if
a GLS is not in a UA's administrative domain? Should the UA trust
the GLS and give out the user's preferences compromising the privacy
of the user?
The answer to the trust problem lies in the way of how trust is
Agapi, Chiu, Chong, Phillips, Willingham INI[Page 34]
Internet-Draft Gateway Location Service Protocol November 1998
established currently in the IP or PSTN domain. In the IP domain, the
systems which can generate digital signatures are those which have
been configured by administrators in advance. The agents who verify
signatures may assume the data is trustworthy since administrators
have ensured the cryptographic keying of SAs, UAs or DAs reflect
trustworthiness.
For the PSTN, in the U.S. Common Carriers (CC) need to be certified
by the FCC or state regulatory commission, in order to establish a
minimal trust. This established trust carries on as CCs interconnect
with other carriers and business relationships are formed. If
complaints surface about the operations of that CC, its license can
be revoked. By the same token, any new entity willing to operate a
GW or a DA, will have to register with the FCC or an already
registered entity (LEC, IXC, etc.). Once the registration is
completed, the new entity can be trusted until there is reasonable
proof not to do so.
Security protocols like SSL (Secure Socket Layer, is based on RSA
Data Security's approach and which is used by both Netscape Navigator
and Microsoft Internet Explorer to authenticate and encrypt
transmissions over the Internet), digital signatures (used to secure
documents, making them unalterable except by the original sender),
and public key protocols (allow the sender to scramble the data using
the public code advertised by the intended receiver, but only the
receiver can decipher the data using a private code) work fine when
data does not require real time transmission. However, with IP
telephony the communication has to be real time and the computation
for encryption and decryption of packets needs to be optimized to
decrease latency. The use of SSL will have too much overhead over
TCP: 7 packets to establish connection. One solution would be to use
SSL to issue a session key with serial number. A request for a
serial number can be resolved through a cache lookup: is the serial
number in the cache? If it is, then use the session key, otherwise
generate a new key.
6. Conclusion
To solve the gateway location problem, we try to do careful
identification on its requirements and features that span from
application layer to routing layer in the Internet. This document
incorporates ideas from several related protocols and standards,
while some issues are still unsolved here and hence need further
study. Most of the unsolved ones are related to uncertainty on
business models. The gateway location service protocol is capable to
support not only existing PTSN business models, but also new ones
that can be derived from the protocol itself. We will continue to
Agapi, Chiu, Chong, Phillips, Willingham INI[Page 35]
Internet-Draft Gateway Location Service Protocol November 1998
improve what we have done here and hope that our work could have some
contributions to the Internet Telephony society.
7. Abbreviations
AS Autonomous System (BGP)
BGP Border Gateway Protocol
BMA Brokered Multicast Advertisement
BSD Block Structure Descriptor
CC Common Carrier
DA Directory Agent
DHCP Dynamic Host Configuration Protocol
ESP Encapsulating Security Payload
FCC Federal Communications Commission
GK H.323 Gatekeeper
GW Gateway
GWC Gateway Controller
GLP Gateway Location Protocol
GLS Gateway Location Server
GLSP Gateway Location Service Protocol
HMAC Hashed Message Authentication Codes
IP Internet Protocol
ISP Internet Service Provider
ITG Internet Telephony Gateway
ITSP Internet Telephony Service Provider
IXC Interexchange Carrier
LEC Local Exchange Carrier
LS Location Server
PSTN Public Switched Telephone Network
SA Service Agent
SLP Service Location Protocol
SPI Secure Parameter Index
SSL Secure Sockets Layer
TLS Transport Level Security
UA User Agent
URL Universal Resource Locator
XML Extensible Markup Language
8. Acknowledgments
We would like to thank Jonathan Rosenberg and Henning Schulzrinne,
the authors of Brokered Multicast Advertisement, for the work that
they have done in defining the gateway location problem [5]. The
authors take responsibility for any error or omission in the
interpretation of their work. This work reflects the views of the
authors and should not be interpreted as representing the views of
Agapi, Chiu, Chong, Phillips, Willingham INI[Page 36]
Internet-Draft Gateway Location Service Protocol November 1998
Carnegie Mellon University. We would especially like to thank
Professor Marvin Sirbu, our advisor, for his valuable thoughts,
insights, and guidance on various aspects of our research.
9. References
[1] H. Olivier, H. Christian, L. C. Herve, "GSTN/TIPHON interworking
using a country code", ETSI TIPHON, November 1997.
[2] R. Faltstrom, B. Larsson, "Where to terminate a phone call",
draft-faltstrom-e164-00, June 1998. (work in progress).
[3] J. Rosenberg, H. Schulzrinne, "A Framework for a Gateway Location
Protocol", draft-ietf-iptel-gwloc-framework-00.txt, July 1998. (work
in progress)
[4] E. Guttman, C. Perkins, J. Veizades, and M. Day. Service
Location Protocol, Version 2. draft-ietf-srvloc-protocol-v2-09.txt,
October 1998. (work in progress).
[5] J. Rosenberg, H. Schulzrinne, "Internet Telephony Gateway
Location", IEEE, 1998.
[6] International Telecommunication Union, Visual telephone systems
and equipment for local area networks which provide a non-guaranteed
quality of service, Recommendation H.323, Telecommunications
Standardization Sector of ITU, Geneva, Switzerland, May 1996.
[7] A. Brown, "E.164 Resolution Solution Proposal", August 1998.
[8] D. Skran, "Framework for the Proposed Gateway Device Control
Protocol V4.2", ITU, September 1998.
[9] Y. Rekhter, T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC
1771, March 1995.
[10] "Trends in Telephone Service," Federal Communications
Commission, July 1998.
[11] T. Bernes-Lee, L. Masinter, M. McCahill, "Uniform Resource
Locators (URL). RFC 1738, December 1994.
[12] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access
Protocol (v3)", RFC 2251, December 1997.
[13] W3C Recommendation, "Extensible Markup Language (XML) 1.0",
February 1998.
Agapi, Chiu, Chong, Phillips, Willingham INI[Page 37]
Internet-Draft Gateway Location Service Protocol November 1998
[14] J. Lennox, H. Schulzrinne, "Call Processing Language
Requirements", draft-ietf-iptel-cpl-requirements-00.txt, July 1998.
(work in progress)
[15] J. Rosenberg, H. Schulzrinne, "A Framework for a Gateway
Location Protocol", draft-ietf-iptel-gwloc-framework-01.txt, October
1998. (work in progress)
Authors's Addresses
Ciprian Agapi
Email: ciprian@andrew.cmu.edu
Chien-Hsiu Chiu
Email: chiu2@andrew.cmu.edu
Thoong-Shin Chong
Email: tchong@andrew.cmu.edu
Harold Phillips
Email: haroldp@andrew.cmu.edu
Brian Willingham
Email: bdw2@andrew.cmu.edu
Information Networking Institute
Carnegie Mellon University
A020 Hamburg Hall
5000 Forbes Avenue
Pittsburgh, PA 15213
Phone: 412-268-7195
FAX: 412-268-7196
Agapi, Chiu, Chong, Phillips, Willingham INI[Page 38]
