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]
