[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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

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).


   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 SLP Message Header ...................................... 20 Service Request ......................................... 21 Service Reply ........................................... 23 Service Registration .................................... 22 Service Acknowledgment .................................. 25 Service Update .......................................... 25 Directory Agent Advertisement ........................... 25 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

   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

   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

   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

   Confederation: Memberships in various confederations or

   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

   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)

   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

   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

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


   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

   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 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          \
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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


   <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

   <t>=service:gwloc <s>=DEFAULT <p>=(&(number="14122687195") (codec =

   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: //, 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.


   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. 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

   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


   could be

                            as="345"&codec="G.711 G.723  G.729"&
                            blocking=".10"&qos="RSVP diffserv" 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...\
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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. 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)         \
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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?,
       <!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>
           <h323 entry=""></h323>
           <sip entry=""></sip>
           <url entry="http://gwc.cmu.edu:4545"></url>
           <url entry="gwloc://gwc.cmu.edu:4321"></url>
       <payment payment="N/A"></payment>
       <qos qos="RSVP diffserv"></qos>
       <crypto crypto="RSA DSA"></security>

       <prefix prefix="1412">
           <blocking blocking=".1" period="60"
           <codec codec="G.711 G.723 G.729"></codec>
           <price excess=".1" unit="0" timing="0"

       <prefix prefix="1">
           <price excess=".25" unit=".25" timing="60"

   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"

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.
   String of version number.

<valid start end>
   Validation of the gateway information. This tells SA when this
   information will be valid and expired.
   ISO 8601 date/time format. The starting time when this information
   become effective.
   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.
   X.509 Distinguished Name

<as as>
   Autonomous System number of the gateway domain.
   AS Number.

   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
   The corresponding URL or transport address string. For example:

   h323    entry=""
   sip     entry=""

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.
   Left for further study

<qos qos>
   Quality of Services capabilities supported.
   String of QoS protocols, separated by space. For example,

   qos="RSVP diffserv"

<crypto crypto>
   Security protocols supported by the gateway.
   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.
   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

Agapi, Chiu, Chong, Phillips, Willingham                    INI[Page 30]

Internet-Draft     Gateway Location Service Protocol       November 1998

   2-digit number representing percentage
   4-digit number in unit of minutes. Averaging period.
   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.
   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

   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.
   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

   3-digit number in 1/1000 of currency unit. The charging price per
   timing unit.
   2-digit number in seconds. Timing unit.
   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,


   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:


   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

   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

   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]

Html markup produced by rfcmarkup 1.124, available from https://tools.ietf.org/tools/rfcmarkup/