[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 04 05 rfc2871                                     
Internet Engineering Task Force                                 IPTEL WG
INTERNET-DRAFT                                        Jonathan Rosenberg
draft-ietf-iptel-gwloc-framework-00.txt                Bell Laboratories
                                                     Henning Schulzrinne
                                                             Columbia U.
                                                            July 7, 1998
                                                Expires: January 7, 1999


              A Framework for a Gateway Location Protocol

STATUS OF THIS MEMO

   This document is an Internet-Draft. Internet-Drafts are working docu-
   ments of the Internet Engineering Task Force (IETF), its areas, and
   its working groups.  Note that other groups may also distribute work-
   ing documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference mate-
   rial or to cite them other than as ``work in progress''.

   To learn the current status of any Internet-Draft, please check the
   ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or
   ftp.isi.edu (US West Coast).

   Distribution of this document is unlimited.

1 Abstract

   This document serves as a framework for developing a protocol for IP
   telephony gateway location. It defines the problem in detail, and
   overviews features and requirements for a protocol solution. It also
   defines some baseline terms and presents an architectural view of the
   problem.

2 Introduction

   While there seems to be agreement that a protocol mechanism is needed

                                                              [Page 1]


Internet Draft              gwloc framework                 July 7, 1998


   to assist in routing IP telephony calls to remote gateways, there is
   not yet consensus on exactly what this means, or what the require-
   ments for such a protocol are. This document defines the problem,
   proposes an architecture for discussion, defines common terms, and
   presents a set of requirements.

3 Problem Definition

   We can state the problem in its most general terms as follows:

   There exist some set of IP telephony gateways, each of which are
   characterized by a set of attributes. An IP host, which we generi-
   cally call a gateway location client, wishes to complete an IP tele-
   phony call through one of these gateways. The client has requirements
   concerning values for some of the attributes. Some protocol mechanism
   is required to allow the client to determine at least one gateway
   among the set which meet the criteria. As new gateways become opera-
   tional, old ones go offline, or attributes of existing gateways
   change, this information should become available to the client in an
   automatic way through the protocol. The information is made available
   by having other hosts, called gateway location servers, propagate
   information about some subset of the gateways for which each has
   authority. If this subset is of size 1, the gateway itself may act as
   a server. Otherwise, some proxy which obtains information about the
   gateways out of band may act as a server. The protocol must provide
   for discovery. That is, it should be possible for a new client to
   join the system, and be able to learn about the gateways advertised
   by the various servers, without having to establish an explicit con-
   nection with each server.

   This general problem can be instantiated in a number of specific
   instances, as defined below. These instances are not meant to be
   exhaustive or required. The protocol generically defines operation
   between gateway location clients and gateway location servers. Its
   specific usage in any or none of the scenarios below is entirely the
   choice of the implementor.

3.1 H.323 Gatekeeper to Gatekeeper Interzone

   The gateway location protocol can be used with ITU H.323 [1]. This
   scenario is depicted in Figure 1. There are a large number of zones,
   each of which has one or more gatekeepers. Each gatekeeper is respon-
   sible for some set of the gateways in each zone. Responsibility,
   here, implies that the gatekeeper know (1) whether the gateway is up
   or down, and (2) the attributes for each gateway. The means by which
   this is known may be through RAS, using the gateway location protocol
   again, on a smaller scale, as described below, or via some other
   means, such as SNMP.

   Each gatekeeper acts as both a gateway location client and gateway
   location server. While acting as server, it distributes information


                                                              [Page 2]


Internet Draft              gwloc framework                 July 7, 1998


   about the gateways its responsible for, via the protocol mechanism.
   This information is then obtained by the other gatekeepers, acting as
   gateway location clients.



     Zone 1    Zone 2    Zone 3     Zone N
    ----------     ----------     ----------      ----------
   |          |   |          |   |          |    |          |
   | GW  GW   |   | GW  GW   |   | GW  GW   |    | GW  GW   |
   |          |   |          |   |          |    |          |
   |  GW  GW  |   |  GW  GW  |   |  GW  GW  | .. |  GW  GW  |
   |          |   |          |   |          |    |          |
   |    GK    |   |    GK    |   | GK  GK   |    |    GK    |
   |   /\     |   |    /\    |   |/\   /\   |    |    /\    |
    ----||----     -----||----    -||---||--      -----||---
        ||              ||         ||   ||             ||
       -||--------------||---------||---||-------------||--
      |  \/              \/         \/   \/             \/ |
      |            Protocol Operation                      |
      |                                                    |
       -----------------------------------------------------

                  Figure 1: Interzone Operation




   As new zones come up, they can join protocol operation and automati-
   cally learn about gateways in other zones.

   To make use of the protocol, an H.323 terminal would make a gate-
   keeper routed call through its local gatekeeper. The alias address
   listed in the setup message would be a telephone number. The gate-
   keeper receiving the setup would then make use of the gateway loca-
   tion protocol, acting as a client, and determine the appropriate
   gateway for completing the call. The attributes for this gateway
   might include its gatekeeper. The setup message could then be for-
   warded to this gatekeeper, which would finally forward the call to
   the destination gateway. Call setup would then proceed normally for
   the gatekeeper to gatekeeper routed call.

   Alternatively, an H.323 terminal might send a RAS LRQ (Location
   Request) message to its gatekeeper, containing the desired telephone
   number in the alias address. The gatekeeper could then act as a gate-
   way location client, and determine the gateway appropriate for reach-
   ing the given number. The call signaling address of the gateway (or
   its gatekeeper) can then be returned in the response to the LRQ.


                                                              [Page 3]


Internet Draft              gwloc framework                 July 7, 1998


   Note that the above diagram does not imply that all zones in the
   Internet are participating in the protocol operation. It should be
   possible to support many instances of the protocol, with some (possi-
   bly overlapping) subset of zones participating in each instance.
   Zones would only participate in an instance of the protocol if they
   are interested in sharing gateway information with other zones par-
   ticipating in that instance. For example, a set of service providers
   may get together to form a confederation, sharing gateways and using
   some coordinated billing agreements. There are many examples of such
   confederations in existence today. The confederation may run a single
   instance of the protocol. Each participating ISP would have its own
   gatekeepers act as both gateway location clients and gateway location
   servers in that instance. An ISP who is a member of multiple confed-
   erations might participate in two instances of the protocol, one for
   each confederation of which it is a member.

3.2 H.323 Intra Zone Discovery

   The protocol can also be used to allow a gatekeeper to discover the
   gateways inside of its own zone. This scenario is depicted in Figure
   2



      ----        ----        ----        ----
     | GW |      | GW |      | GW |      | GW |
      -|--        -|--        -|--        -|--
       |           |           |           |
      \/          \/          \/          \/
     ------------------------------------------
    |         Protocol Operation               |
     ------------------------------------------
                 |           |
                 |           |
                \/          \/
                ----        ----
               | GK |      | GK |
                ----        ----

                   Figure 2: Intra Zone Discovery




   Here, the gateways inside of the zone act as gateway location
   clients, and the gatekeepers act as gateway location servers. As the
   protocol is really engineered for wide area operation, its usage in
   this scenario is more useful when a zone is extremely large,


                                                              [Page 4]


Internet Draft              gwloc framework                 July 7, 1998


   containing many gateways and gatekeepers. It is also most useful when
   it is desired for each gatekeeper to learn about each gateway.

3.3 Wide Area SIP Operation

   As it is desirable to make the gateway location protocol independent
   of the underlying IP telephony signaling protocol, it can be used
   with SIP [2] (or any of the many proprietary mechanisms still in
   use). Its usage with SIP is depicted in Figure 3.



        Domain a.com              Domain b.com
     - - - - - - - - - -    - - - - - - - - - - -
   |  ----        ----  |  |   ----        ----  |
     | GW |      | GW |       | GW |      | GW |
   |  -|--        -|--  |  |   -|--        -|--  |
       |           |            |           |
   |   |   ----    |    |  |    |    ----   |    |
       |  | SV |   |            |   | SV |  |
   |   |   ----    |    |  |    |    ----   |    |
       |    /\     |            |     /\    |
   |   |     |     |    |  |    |      |    |    |
     - - - - - - - - - -    - - - - - - - - - - -
       |     |     |            |      |    |
      \/     |    \/           \/      |   \/
     ------------------------------------------
    |         Protocol Operation               |
     ------------------------------------------

              Figure 3: SIP Operation




   Here, gateways in each domain act as gateway location servers. They
   each propagate information about their own attributes, via the proto-
   col, over the wide area network. SIP Servers (SV in the diagram)
   obtain these attributes. When a client (not shown) makes a call to
   the PSTN, it forwards the SIP INVITE to its local proxy server, with
   the Request URI and To field containing a telephone URL. This proxy
   server can then use the protocol to determine the appropriate gate-
   way. The gateway can then be returned to the client using a SIP redi-
   rect response, or the server can forward the call to the gateway
   directly, acting as a proxy.

4 Requirements



                                                              [Page 5]


Internet Draft              gwloc framework                 July 7, 1998


   Here, we discuss the requirements of the protocol to solve the
   defined problem. Note that many of these are similar to the require-
   ments for discovering wide area services in general [3]:

     oMulti-criteria. The client desires a gateway which can be charac-
      terized by a number of attributes. The client should be able to
      express the desired attributes of the gateway, and get back a
      gateway whose service meets the criteria. There should be no arbi-
      trary restriction on the type, values, or number of attributes
      which can potentially characterize a gateway. Obviously, some kind
      of standardization of baseline attributes, and their syntax and
      semantics, will be required for interoperability. However, it must
      be possible for implementors to define and register their own
      attributes. The protocol must provide a way to maintain minimum
      interoperability when a gateway location client does not under-
      stand some of the attributes sent by the server.

     oLocation Independent. It should not be necessary for the gateway
      location client to know the domain, zone, IP address, administra-
      tor, or any other type of name of a gateway in order to locate and
      use it.

     oAuto Configured. It should be straightfoward to configure new
      clients and servers to use the protocol. A new gateway should
      automatically be discoverable, requiring no new configuration on
      the part of existing clients, and little or no setting of
      addresses or other parameters in the new gateway (or the server
      representing it).

     oRapid Availability. When a gateway is first brought on line, it
      should become visible and accessible to clients rapidly.

     oAutomated. The location process should be automated, and not rely
      on interactive input from a user to satisfy a reasonable query.
      However, the protocol should not prevent interactive sessions.

     oRapid. The gateway location process should occur as rapidly as
      possible. It is one component of many in the post-dial delay. It
      is therefore desirable to avoid wide area, distributed database
      searches in order to determine a suitable gateway.

     oPolicy Support. The protocol must support policy. This means that
      it must be possible for a client to eliminate certain gateways
      from the selection process based on any desired combination of
      attributes. It must also be possible for a server to specify pol-
      icy, so that it can restrict the set of clients which can access
      it.



                                                              [Page 6]


Internet Draft              gwloc framework                 July 7, 1998


     oWorldwide. The location of a desired gateway can be anywhere, as
      can be the client. The protocol should be internationalized, sup-
      porting queries and attributes in different languages.

     oScalable. There can be millions of clients, servers, and gateways,
      and the protocol will still operate correctly.

     oMildly Dynamic. The attributes which characterize the service pro-
      vided by the gateway do not change on small timescales. However,
      they may change on larger timescales, and this should be handled
      appropriately.

     oSecurity. Encryption of messages must be supported. Authentication
      and non-repudiation of attributes for gateways must be supported.

     oMultiple Instances. It should be possible to run multiple
      instances of the protocol, so that gateway location servers in an
      instance make their gateways available only to those gateway loca-
      tion clients running in the instance.

     oSignaling Protocol Independent. The protocol should be independent
      of the underlying IP telephony signaling protocol, be it H.323,
      SIP, or some other proprietary protocol.

4.1 Possible Attributes

   As the protocol involves selection of gateways based on attributes,
   it is necessary to define a base set of attributes. Below are a par-
   tial list of potential attributes:

     oPhone Prefixes Allowed: The set of phone number prefixes which
      this gateway is permitted to call.

     oGateway Address: The IP address of the gateway.

     oCodecs Supported: List of codecs supported by the gateway.

     oSignaling Protocols Supported: List of signaling protocols and
      versions supported.

     oCost Plan: Some kind of cost structure describing how much the
      gateway will bill for calls based on time of day, destination,
      etc.

     oBilling Methods: Tokens which describe the ways in which calls
      through the gateway can be billed. Examples include credit and
      debit cards, clearinghouse, e-cash, etc.



                                                              [Page 7]


Internet Draft              gwloc framework                 July 7, 1998


     oConfederation or ClearingHouse Memberships: Membership in various
      confederations.

     oAdministrator: Name of the corporation that administers the gate-
      way.

     oTotal Capacity: Number of lines supported by the gateway.

     oAvailable Capacity: Estimate of the number of lines still avail-
      able through the gateway.

     oFeatures Supported: Supplementary telephony services supported by
      the gateway, such as multiparty calling, transfer, and forward.

     oGatekeeper: The gatekeeper for the gateway.

5 Security Considerations

   Security is a critical requirement for a protocol solution. Encryp-
   tion, authentication, and non-repudiation are minimal requirements.

6 Conclusion

   We have defined the problem of gateway location, proposed a framework
   for discussing solutions, and defined a set of key requirements for a
   solution.

7 Full Copyright Statement

   Copyright (C) The Internet Society (1998). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implmentation may be prepared, copied, published and
   distributed, in whole or in part, without restriction of any kind,
   provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.

   However, this document itself may not be modified in any way, such as
   by removing the copyright notice or references to the Internet Soci-
   ety or other Internet organizations, except as needed for the purpose
   of developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be fol-
   lowed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.


                                                              [Page 8]


Internet Draft              gwloc framework                 July 7, 1998


   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MER-
   CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."

8 Bibliography

   [1] International Telecommunication Union, Visual telephone systems
   and equipment for local area networks which provide a non-guaranteed
   quality of service, Recommendation H.323, Telecommunication Standard-
   ization Sector of ITU, Geneva, Switzerland, May 1996.

   [2] M. Handley, H. Schulzrinne, and E. Schooler, SIP: Session initia-
   tion protocol, Internet Draft, Internet Engineering Task Force, Mar.
   1998.  Work in progress.

   [3] J. Rosenberg, H. Schulzrinne, E. Guttman, and R. Moats, WASRV
   architectural principles, Internet Draft, Internet Engineering Task
   Force, Feb. 1998.  Work in progress.

9 Authors Addresses


   Jonathan Rosenberg
   Lucent Technologies, Bell Laboratories
   101 Crawfords Corner Rd.
   Holmdel, NJ 07733
   Rm. 4C-526
   email: jdrosen@bell-labs.com

   Henning Schulzrinne
   Columbia University
   M/S 0401
   1214 Amsterdam Ave.
   New York, NY 10027-7003
   email: schulzrinne@cs.columbia.edu












                                                              [Page 9]