INTERNET DRAFT Weibin Zhao draft-zhao-iptel-gwloc-slp-02.txt Henning Schulzrinne October 2, 2001 Columbia University Expires: April 2, 2002 Locating Internet Telephony Gateways via SLP Status of This Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract This document describes how to use the Service Location Protocol (SLP) to locate Internet telephony gateways. It defines the 'service:iptel-gw:' template for the Internet telephony gateway service, and discusses the different usage scenarios and the applicability of SLP for the Internet telephony gateway location. Zhao, Schulzrinne Expires: April 2, 2002 [Page 1] Internet Draft Gateway Location via SLP October 2, 2001 1. Introduction In the Internet telephony networks, an administrative domain has one or multiple location servers [1], and has numerous gateways that link the Internet to the Public Switched Telephone Network (PSTN). When a call arrives, a location server in the domain routes the call to one of these gateways. Figure 1 shows the typical scenario. | incoming call V +-----------------+ +-----| Location Server |-----+ | +-----------------+ | | | | V V V +----------+ +----------+ +----------+ | Gateway1 | | Gateway2 | | Gateway3 | +----------+ +----------+ +----------+ Internet .............|..............|..............|............... V V V +-----------------------------------------------+ | Public Switched Telephone Network (PSTN) | +-----------------------------------------------+ Figure 1. Gateway Selection for Internet Telephony The gateway selection at the location server depends on many factors, including gateway availability, capacity, and cost for terminating a particular call. Obtaining the up-to-date gateway information is critical for a location server to make the proper call routing decision. This document describes how to use the Service Location Protocol (SLP [2]) for the gateway and location server communication. It defines the 'service:iptel-gw:' template for the Internet telephony gateway service, and discusses the different usage scenarios and the applicability of SLP for the Internet telephony gateway location. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [3]. 2. SLP Overview SLP provides a scalable framework for service discovery and selection within one administrative domain. A service is described using a set of attributes, which is defined in the service template [4]. Zhao, Schulzrinne Expires: April 2, 2002 [Page 2] Internet Draft Gateway Location via SLP October 2, 2001 An SLP system has three different entities: User Agent (UA), Service Agent (SA), and Directory Agent (DA). Normally, applications are bound to UAs and services to SAs. DAs may be deployed to cache service registrations from SAs to enhance the system scalability. Without DAs, a UA needs to query all SAs via multicast to discover service information. If DAs are deployed, SAs register services with DAs, and UAs query DAs, both via unicast. SLP achieves further scalability by assigning services and agents into different scopes. In SLP, service information can be distributed in a push fashion, or be requested in a pull fashion. SAs can push service registrations to DAs via unicast, or perform notification to all UAs via multicast [5]. UAs can pull service information from all SAs via multicast, or from a DA via unicast. 3. Template for Internet Telephony Gateway Service The 'service:iptel-gw:' template defines the attributes associated with the Internet telephony gateway service that a client may want to use. The 'service:iptel-gw:' template defined below conforms to the grammar described in "Service Templates and service: Schemes". Please refer to RFC 2609 [4] for detailed explanation of the syntax. Name of submitters: Weibin Zhao Henning Schulzrinne Language of service template: en (English) Security Considerations: When using multicast in SLP, useful information may be exposed to attachers. The standard SLP authentication mechanism SHOULD be used for accepting service registrations and validating DA advertisements. Template Text: ----------------------template begins here----------------------- template-type = iptel-gw template-version = 1.0 template-description = The 'service:iptel-gw:' template describes the attributes supported by the Internet telephony gateway service. template-url-syntax = Zhao, Schulzrinne Expires: April 2, 2002 [Page 3] Internet Draft Gateway Location via SLP October 2, 2001 # service:iptel-gw://: total-capacity = integer # Total number of phone calls that can be supported by the gateway. # # Example: # total-capacity = 1024 remaining-capacity = integer # Number of phone calls that can be further supported by the gateway. # # Example: # remaining-capacity = 312 prefix-list = string M L # A list of phone number prefixes that can be reached from the # gateway. Each phone number prefix MUST be an E.164 number prefix # without visual separators and without the "+" prefix. # # Grammar: # prefix-list = prefix / prefix ',' prefix-list # prefix = 1*DIGIT # DIGIT = %x30-39 # # Example: # prefix-list = 1212,4930,8610 # where 1212 --- New York, NY, USA # 4930 --- Berlin, Germany # 8610 --- Beijing, P.R.China cost-list = string M L # A list of prefix-cost pairs, specifying the cost for reaching # each phone number prefix defined in the "prefix-list" attribute. # # Prefix A MUST precede prefix B if A is more specific than B, # e.g., 1212 MUST precede 1. The last element of this list may omit # the prefix, which represents all unspecified prefixes. # # The cost is given in a relative manner (the smaller the better), # no cost unit is specified here. To determine the cost for reaching # a prefix, use the longest-prefix matching. # # Grammar: # cost-list = cost-info / cost-info ',' cost-list # cost-info = [prefix] ':' cost # prefix = 1*DIGIT # cost = 1*DIGIT # DIGIT = %x30-39 Zhao, Schulzrinne Expires: April 2, 2002 [Page 4] Internet Draft Gateway Location via SLP October 2, 2001 # # Example: # prefix-list = 1,49,86 # cost-list = 1212:5,1:10,:20 # where the costs are as follows: # Prefix Cost # 1212 (New York, NY, USA) 5 # 1 (all other places in USA/Canada) 10 # 49,86 (Germany, P.R.China) 20 asr-list = string M L O # A list of prefix-ASR pairs, specifying the ASR (answer-seizure # ratio) for each phone number prefix defined in the "prefix-list" # attribute. This is an optional attribute. # # Prefix A MUST precede prefix B if A is more specific than B, # e.g., 1212 MUST precede 1. The last element of this list may omit # the prefix, which represents all unspecified prefixes. # # The ASR is given in percentage (0.0 - 100.0). To determine the # ASR for a prefix, use the longest-prefix matching. # # Grammar: # asr-list = asr-info / asr-info ',' asr-list # asr-info = [prefix] ':' asr # prefix = 1*DIGIT # asr = 1*DIGIT ['.' 1*DIGIT] # DIGIT = %x30-39 # # Example: # prefix-list = 1,49,86 # asr-list = 1212:99.9,1:98.1,:95.8 # where the ASRs are as follows: # Prefix ASR # 1212 (New York, NY, USA) 99.9 # 1 (all other places in USA/Canada) 98.1 # 49,86 (Germany, P.R.China) 95.8 -----------------------template ends here------------------------ 4. Locating Internet Telephony Gateway via SLP As a gateway is a service provider for location servers in Internet telephony, each gateway should use an SLP SA to advertise its service. There are two basic models for the gateway and location server interaction: location servers pulling service information from Zhao, Schulzrinne Expires: April 2, 2002 [Page 5] Internet Draft Gateway Location via SLP October 2, 2001 gateways or gateways pushing the information to location servers. As a key constraint for Internet telephony is to minimize the call setup delay, it is important to reduce the time for gateway selection at the location server as much as possible, and it is desirable for a location server to have the required gateway information before a call arrives. Thus, we believe that the push model is more suitable for the gateway and location server interaction. Using SLP, information can be pushed from service providers to clients in two ways. If multicast is supported in the network, the mechanism described in RFC 3082 [5] can be used, where SAs push service information directly to UAs via multicast. When multicast is not available or cannot be used for some reasons, service information can be pushed via unicast using the mechanism described in the next section. 5. Pushing Service Information via Unicast in SLP To enable gateways to push their service information to location servers via unicast, each location server needs to have a dedicated SLP DA. Figure 2 shows the overall architecture, where each gateway sends its updated service information to location servers via unicast whenever it is needed. ......................... ......................... . +-------------------+ . . +-------------------+ . . | Location Server 1 | . . | Location Server 2 | . . +-------------------+ . . +-------------------+ . . | . . | . . +----------+ . . +----------+ . . +---| SLP DA |---+ . . | SLP DA | . . | +----------+ | . . +----------+ . ..|.........|........|... ............|.|.......... | | | | | ................| ........|....... |................| | . +----------+ .| . +----------+ . |. +----------+ .| | . | SLP SA |--+ . | SLP SA | . +--| SLP SA |--+ | . +----------+ .| . +----------+ . . +----------+ . | . | .| . | . . | . | . +----------+ .| . +----------+ . . +----------+ . | . | Gateway1 | .| . | Gateway2 | . . | Gateway3 | . | . +----------+ .| . +----------+ . . +----------+ . | ................| ................ ................ | +-------------------------------------+ Figure 2. Push Gateway Information to Location Servers via Unicast In this architecture, each location server has its own SLP DA. Note Zhao, Schulzrinne Expires: April 2, 2002 [Page 6] Internet Draft Gateway Location via SLP October 2, 2001 that binding applications to DAs is not the common usage model for SLP DAs. This usage is motivated by performance and timeliness requirements of Internet telephony, where a location server needs to frequently consult the gateway information to make routing decisions, and the lookup time must be short. When an SLP DA is used in this special way, the DA SHOULD only operate in a special scope, not in the DEFAULT scope. For the Internet telephony gateway location, the special scope is "iptel-gw". In this way, the dedicated DA for a location server will only respond to gateways that also operate in this special scope of "iptel-gw". When multiple location servers are deployed in a domain, a gateway may need to push its information to several location servers. By using a mesh-enhanced DA [6] for each location server, the gateway registration with multiple location servers can be simplified. Using mesh-enhanced SLP [6], a gateway only needs to push its information to one location server, then the information will be propagated automatically to all other location servers. In general, there is a many-to-many relationship between gateways and location servers, i.e., a location server may use multiple gateways, and a gateway may serve multiple location servers. Normally there are more gateways than location servers in a domain, it is a natural way to let numerous gateways register with a few location servers. 5.1. Gateway Operations Each gateway uses an SLP SA as its front end to perform two basic functions: discovering location servers and registering the gateway information to location servers. A gateway discovers location servers using standard SLP DA discovery mechanism, including static configuration, DHCP [7], and multicast if it is available. A gateway registers its current information to location servers using the 'service:iptel-gw:' template. As the service registration in SLP is soft state, a gateway needs to refresh its registration before the registration expires. The maximum lifetime for a registration in SLP is around 18 hours (65535 seconds). However, a gateway SHOULD NOT register with a location server too often, e.g., the interval between any two registrations MUST be larger than the "min-refresh-interval" if this attribute is present in the DA's DAAdvert message. In addition to keeping a registration at location servers, a gateway SHOULD update its registration whenever it is needed, e.g., the remaining capacity has changed 10%. A gateway SHOULD de-register its Zhao, Schulzrinne Expires: April 2, 2002 [Page 7] Internet Draft Gateway Location via SLP October 2, 2001 information with location servers when its service is no longer available. A gateway registers/de-registers its information with location servers using SLP SrvReg/SrvDeReg messages. A location server replies with a SrvRply message to indicate whether the registration/de- registration is successful. 5.2. Location Server Operations Each location server uses an SLP DA as its front end to accept and store gateway registrations. At the same time, when a call arrives, the location server checks the gateway information, and finds a proper gateway to route the call to the gateway. Normally the front end DA for a location server is a generic SLP DA, and the DA and the location server SHOULD be in the same machine. The location server uses a normal SLP UA to issue SLP requests via LOOPBACK to the local DA (Figure 3). This polling has a lower cost compared with a non-local UA-DA query. +------------------+ | Location Server | | | | | UA ------ DA | +------------------+ | +----+ | SA | +----+ Figure 3. Location Server and its front end SLP DA Further performance enhancement can be achieved at the location server by caching gateway information instead of making an SLP query whenever there is an incoming call. Whether to use caching and its related management is a separate, non-trivial issue and is beyond the scope of this document. Note that when a location server queries its front end DA, the location server SHOULD use the attribute list extension (RFC 3059 [8]) to obtain the attribute information of gateways. 5.3. Discussion In this subsection, we discuss whether pushing service information via unicast in SLP can meet the requirements of the Internet telephony gateway discovery [9]. Zhao, Schulzrinne Expires: April 2, 2002 [Page 8] Internet Draft Gateway Location via SLP October 2, 2001 (1) Fast: Gateway should be discovered fast to minimize the call setup time. Using SLP, gateways send their registrations to location servers before call setup. During a call setup, a location server only needs to query its local SLP DA to find the proper gateway. (2) Failure Detection: Each location server needs to know the availability information of gateways. Using SLP, gateway availability can be decided in two ways. First, as each registration is a soft state, an expired registration will be removed, which indicates the corresponding gateway is not available. Second, a gateway can de- register its service information with location servers by using the SrvDeReg message. (3) Startup Detection: When a failed gateway recovers, the gateway should inform location servers rapidly. Using SLP, a recovered gateway can send a new registration to location servers to notify its availability. (4) Capacity Knowledge: The location server needs to know the capacity of each gateway. Using SLP, the capacity information is carried in the gateway registration, as specified in the 'service:iptel-gw:' service template. (5) Secure: The communication between the location server and gateway needs to be secure. SLP provides authentication mechanism for SrvReg, and SrvDeReg messages. (6) Convey Routing Information: Each location server needs to know the routing information of gateways. Using SLP, the routing information is carried in the gateway registration, which is described via the "prefix-info-list" attribute in the 'service:iptel-gw:' service template. (7) Timeliness: A location server needs to learn the gateway information in a timely fashion. Using SLP, a gateway can update its service registration whenever it is needed. A wide range of updating interval is supported in SLP, from a few seconds to several hours. (8) Extensible Attributes: The location server may need to know other information about the gateways. Using SLP, new attributes for the 'service:iptel-gw:' service template can be defined and be added later. (9) Efficient: Gateway registrations at location servers can be refreshed or updated in a wide range of interval: from a few seconds to several hours. Thus, registration traffic is modest, and is demand-driven in most cases. Also, all registrations are performed in unicast. Furthermore, each location server has its own SLP DA, which Zhao, Schulzrinne Expires: April 2, 2002 [Page 9] Internet Draft Gateway Location via SLP October 2, 2001 means that a location server accesses the gateway information locally (on the same machine). (10) Routing Server Control: It is desirable that a location server is in control of make a decision about where the call should ultimately be routed. Using SLP, gateway information is collected by SLP DAs, each location server makes its own routing decision. (11) Independent Policies: If multiple routing servers exist within one administrative domain, gateways register with all available location servers. Using SLP, location servers can adopt different policies, and make different routing decisions. In summary, we think the mechanism described in this section can fulfill all the requirements of Internet telephony, and is a good choice for the gateway and location server communication. 6. Security Considerations When using multicast in SLP, useful information may be exposed to attachers. The standard SLP authentication mechanism SHOULD be used for accepting service registrations and validating DA advertisements. 7. Acknowledgments The authors would like to thank Erik Guttman, Ira McDonald and James Kempf for their valuable comments and suggestions. 8. References [1] J. Rosenberg and H. Schulzrinne, "A Framework for Telephony Routing over IP", RFC 2871, June 2000. [2] E. Guttman, C. Perkins, J. Veizades and M. Day, "Service location protocol, version 2", RFC 2608, June 1999. [3] S. Bradner, "Key words for use in RFCs to indicate requirement levels", BCP 14, RFC 2119, March 1997. [4] E. Guttman, C. Perkins and J. Kempf, "Service Templates and Service: Schemes", RFC 2609, June, 1999. [5] J. Kempf and J. Goldschmidt, "Notification and Subscription for SLP", RFC 3082, March 2001. [6] W. Zhao, H. Schulzrinne and E. Guttman, "mSLP - Mesh-enhanced Service Location Protocol", Internet-Draft, July 2001. Zhao, Schulzrinne Expires: April 2, 2002 [Page 10] Internet Draft Gateway Location via SLP October 2, 2001 [7] C. Perkins and E. Guttman, "DHCP options for service location protocol", RFC 2610, June, 1999. [8] E. Guttman, "Attribute List Extension for the Service Location Protocol", RFC 3059, February 2001. [9] J. Rosenberg and H. Salama, "Usage of TRIP in Gateways for Exporting Phone Routes", Internet-Draft, July, 2001. 9. Authors' Addresses Weibin Zhao Henning Schulzrinne Department of Computer Science Columbia University 1214 Amsterdam Avenue, MC 0401 New York, NY 10027-7003 Email: {zwb,hgs}@cs.columbia.edu 10. Full Copyright Statement Copyright (C) The Internet Society (2001). 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 implementation 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 Society 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 followed, 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. 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 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Zhao, Schulzrinne Expires: April 2, 2002 [Page 11]