INTERNET DRAFT Weibin Zhao [-draft-zhao-iptel-gwloc-slp-04.txt-] {+draft-zhao-iptel-gwloc-slp-05.txt+} Henning Schulzrinne [-March 25, 2002-] {+[Target Category: Standards Track]+} Columbia University [-Expires: September 25,-] {+August 28,+} 2002 {+Expires: February 28, 2003+} Locating [-Internet-] {+IP-to-Public Switched Telephone Network (PSTN)+} 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 (2002). 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: [-September 25, 2002-] {+February 28, 2003+} [Page 1] Internet Draft Gateway Location via SLP [-March 25,-] {+August 28,+} 2002 1. Introduction In the Internet telephony networks, an administrative domain has one or multiple location servers [-[1],-] {+[RFC2871],+} 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 route phone calls properly. This document describes how to use the Service Location Protocol (SLP [-[2])-] {+[RFC2608])+} for the gateway and location server interaction. 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].-] {+[RFC2119].+} 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]. An SLP system has three different entities: User Agent (UA), Service-] {+[RFC2609].+} Zhao, Schulzrinne Expires: [-September 25, 2002-] {+February 28, 2003+} [Page 2] Internet Draft Gateway Location via SLP [-March 25,-] {+August 28,+} 2002 {+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. If DAs are deployed, SAs register with DAs, and UAs query DAs, both via unicast. SLP uses both push and pull to disseminate service information. SAs can push service registrations to DAs via unicast, or perform notification to all UAs via multicast [-[5].-] {+[RFC3082].+} UAs can pull service information from all SAs via multicast, or from a DA via unicast. 3. Using SLP for Internet Telephony Gateway Location As a key constraint of Internet telephony is to minimize the call setup delay, a location server SHOULD reduce the time of gateway selection as much as possible. It is desirable that a location server has required gateway information before a call arrives. Otherwise, it will incur a longer call setup delay if a location server pulls gateway information after a call has arrived. Thus, the interaction of gateways and location servers shall use a push model: gateways push their information to location servers. To push gateway information to location servers, the mechanism described in RFC 3082 [-[5]-] {+[RFC3082]+} can be used if multicast is supported. When multicast is not available or cannot be used for some reasons, the mechanism described in the next section can be used. 4. Pushing Gateway Information via Unicast To push gateway information to location servers via unicast, each location server needs to use a dedicated SLP DA. Figure 2 shows the architecture. The dedicated DA is a standard SLP DA, but it SHOULD use a special scope for the "iptel-gw" service (this DA may support other scopes if needed). The default value for this special scope is "iptel-gw", but it could be set to some other value administratively. Using a special scope for the "iptel-gw" service can ensure that "service:iptel-gw" registrations are only sent to dedicated DAs at location servers, other service registrations will not be sent to these dedicated DAs if they only support one special scope for the "iptel-gw" service. Note 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 multiple location servers are deployed in a domain, a gateway-] Zhao, Schulzrinne Expires: [-September 25, 2002-] {+February 28, 2003+} [Page 3] Internet Draft Gateway Location via SLP [-March 25,-] {+August 28,+} 2002 {+When multiple location servers are deployed in a domain, a gateway+} may need to push its information to several location servers. By using the SLP mesh-enhancement [-[6],-] {+[mSLP],+} a gateway only needs to push its information to one location server, then the information will be propagated automatically to other location servers. In general, a location server may use multiple gateways, and a gateway may serve multiple location servers. ......................... ......................... . +-------------------+ . . +-------------------+ . . | 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 4.1. Gateway Operations A gateway uses an SLP SA to advertise its service. It registers its information with location servers using the "service:iptel-gw" template, refreshes its registration periodically, updates its registration whenever it is needed, and de-registers its information when its service is no longer available. A gateway discovers location servers using standard SLP DA discovery [-mechanism,-] {+mechanisms,+} including static configuration, DHCP [-[7],-] {+[RFC2610], passively listening for DAAdvert (DA Advertisement) multicast,+} and [-multicast if it is available.-] {+actively sending the "service:directory-agent" SrvRqst (Service Request) multicast.+} 4.2. Location Server Operations A location server uses an SLP DA as its front end to accept and store gateway registrations. Normally the location server and its front end {+Zhao, Schulzrinne Expires: February 28, 2003 [Page 4] Internet Draft Gateway Location via SLP August 28, 2002+} DA are in the same machine. The location server uses an 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. [-Zhao, Schulzrinne Expires: September 25, 2002 [Page 4] Internet Draft Gateway Location via SLP March 25, 2002-] When a call arrives, the location server looks up the gateway information, and routes the call to a gateway properly. To find the best gateway for a call, the location server can use [-the Sort and Selection Extensions [8] in a SrvRqst to ask its front end DA to make the best match. Or it can use the Attribute List Extension (RFC 3059 [9]) in a SrvRqst or use-] a SrvRqst followed by [-a AttrRqst-] {+AttrRqst(s) (Attribute Request)+} to obtain relevant attribute information of gateways, then it makes a choice by itself. {+Note that the location server can use the Attribute List Extension [RFC3059] in the SrvRqst to optimize the above operations.+} +------------------+ | Location Server | | | | | UA ------ DA | +------------------+ | +----+ | SA | +----+ Figure 3. Location Server and its front end SLP DA 5. Template for Internet Telephony Gateway Service The "service:iptel-gw" template defines the attributes associated with the Internet telephony gateway service. Please refer to RFC 2609 [-[4]-] {+[RFC2609]+} 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-] {+Internet telephony gateway services are likely to be paid services, so that there could+} be [-exposed-] {+a particular incentive+} to [-attachers.-] {+modify somebody else's registrations.+} The standard SLP authentication mechanism SHOULD be used for accepting service [-registrations and validating DA advertisements.-] {+registrations.+} Template Text: ----------------------template begins here----------------------- template-type = iptel-gw template-version = 1.0 [-template-description = This template describes the attributes supported by the Internet-] Zhao, Schulzrinne Expires: [-September 25, 2002-] {+February 28, 2003+} [Page 5] Internet Draft Gateway Location via SLP [-March 25,-] {+August 28,+} 2002 {+template-description = This template describes the attributes supported by the Internet+} telephony gateway service. template-url-syntax = ; "service:iptel-gw://" host ":" port ; host = host from section 2.1 of RFC 2609 ; port = port from section 2.1 of RFC 2609 iptel-gw-total-capacity = integer # Total number of phone calls that can be supported by the # gateway. # # Example: # iptel-gw-total-capacity = 1024 iptel-gw-remaining-capacity = integer # Number of phone calls that can be further supported by the # gateway. # # Example: # iptel-gw-remaining-capacity = 312 iptel-gw-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: # iptel-gw-prefix-list = prefix / # prefix "," iptel-gw-prefix-list # prefix = 1*DIGIT # DIGIT = %x30-39 # # Example: # iptel-gw-prefix-list = 1212,4930,8610 # where 1212 --- New York, NY, USA # 4930 --- Berlin, Germany # 8610 --- Beijing, P.R.China iptel-gw-cost-list = string M L # A list of prefix-cost pairs, specifying the cost for reaching # each phone number prefix defined in the "iptel-gw-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-] {+prefixes. To determine the+} cost [-is given in-] {+for reaching+} a [-relative manner (the smaller the better),-] {+prefix, use # longest-prefix matching.+} Zhao, Schulzrinne Expires: [-September 25, 2002-] {+February 28, 2003+} [Page 6] Internet Draft Gateway Location via SLP [-March 25,-] {+August 28,+} 2002 # {+# The cost is given in a relative manner (the smaller the better); #+} no cost unit is specified here. [-To determine the cost-] {+We assume that all gateways are # configured to use some default unit+} for {+cost measurement, which+} # [-reaching-] {+implies that there is+} a [-prefix, use the longest-prefix matching.-] {+common administrator for all gateways # being considered. Similar to SLP, this is designed to be used in # networks under cooperative administrative control.+} # # Grammar: # iptel-gw-cost-list = cost-info / # cost-info "," iptel-gw-cost-list # cost-info = [prefix] ":" cost # prefix = 1*DIGIT # cost = 1*DIGIT # DIGIT = %x30-39 # # Example: # iptel-gw-prefix-list = 1,49,86 # iptel-gw-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 iptel-gw-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 [-#-] "iptel-gw-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. # # {+ASR (Answer Seizure Ratio) is defined in ITU-T Recommendation # E.411 [E411] as the percentage of the number of seizures that # result in an answer signal over the total number of seizures # in a specified period of time. # #+} Grammar: # iptel-gw-asr-list = asr-info / # asr-info "," iptel-gw-asr-list # asr-info = [prefix] ":" asr # prefix = 1*DIGIT # asr = 1*DIGIT ["." 1*DIGIT] # DIGIT = %x30-39 # # Example: {+Zhao, Schulzrinne Expires: February 28, 2003 [Page 7] Internet Draft Gateway Location via SLP August 28, 2002+} # iptel-gw-prefix-list = 1,49,86 # iptel-gw-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 [-Zhao, Schulzrinne Expires: September 25, 2002 [Page 7] Internet Draft Gateway Location via SLP March 25, 2002-] -----------------------template ends here------------------------ 6. Discussion In this section, we show that SLP can meet the requirements of the Internet telephony gateway [-discovery [9].-] {+discovery.+} (1) Fast: Using SLP, gateways send their registrations to location servers in advance. During a call setup, a location server only queries its local SLP DA to find the proper gateway. (2) Failure Detection: 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. (3) Startup Detection: Using SLP, a recovered gateway can send a new registration to location servers to notify its availability. (4) Capacity Knowledge: Using SLP, the capacity information is carried in the gateway registration, as specified in the "service:iptel-gw" service template. (5) Secure: SLP has authentication mechanism. (6) Routing Information: Using SLP, the routing information is carried in the gateway registration, as specified via the "iptel-gw- prefix-list" attribute in the "service:iptel-gw" service template. (7) Timeliness: 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: Using SLP, new attributes for the "service:iptel-gw" service template can be defined and 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 {+Zhao, Schulzrinne Expires: February 28, 2003 [Page 8] Internet Draft Gateway Location via SLP August 28, 2002+} demand-driven in most cases. Also, all registrations are performed in unicast. Furthermore, each location server accesses the gateway information locally (on the same machine). (10) Routing Control: Using SLP, gateway information is collected by SLP DAs, each location server makes its own routing decision. (11) Independent Policies: If multiple location servers exist within [-Zhao, Schulzrinne Expires: September 25, 2002 [Page 8] Internet Draft Gateway Location via SLP March 25, 2002-] one administrative domain, gateways register with all available location servers. Using SLP, location servers can adopt different policies, and make different routing decisions. 7. Security Considerations [-When using multicast in SLP, useful information may-] {+Internet telephony gateway services are likely to+} be [-exposed-] {+paid services, so that there could be a particular incentive+} to [-attachers.-] {+modify somebody else's registrations.+} The standard SLP authentication mechanism SHOULD be used for accepting service [-registrations and validating DA advertisements.-] {+registrations.+} 8. Acknowledgments The authors would like to thank Erik Guttman for his valuable comments. Ira McDonald and James Kempf also gave good [-suggestions for this document.-] {+suggestions.+} 9. {+Normative+} References [-[1] J. Rosenberg and H. Schulzrinne, "A Framework for Telephony Routing over IP", RFC 2871, June 2000. [2]-] {+[RFC2608]+} E. Guttman, C. Perkins, J. Veizades and M. Day, "Service location protocol, version 2", RFC 2608, June 1999. [-[3]-] {+[RFC2119]+} S. Bradner, "Key words for use in RFCs to indicate requirement levels", BCP 14, RFC 2119, March 1997. [-[4]-] {+10. Non-normative References [RFC2871] J. Rosenberg and H. Schulzrinne, "A Framework for Telephony Routing over IP", RFC 2871, June 2000. [RFC2609]+} E. Guttman, C. Perkins and J. Kempf, "Service Templates and Service: Schemes", RFC 2609, June 1999. [-[5]-] {+[RFC3082]+} J. Kempf and J. Goldschmidt, "Notification and Subscription for SLP", RFC 3082, March 2001. [-[6]-] {+[mSLP]+} W. Zhao, H. Schulzrinne and E. Guttman, [-"mSLP - Mesh-enhanced-] {+"Mesh-enhanced+} Service Location Protocol", Internet-Draft, [-November 2001. [7]-] {+August 2002. [RFC2610]+} C. Perkins and E. Guttman, "DHCP options for service location protocol", RFC 2610, June 1999. [-[8] W.-] Zhao, [-H. Schulzrinne, C. Bisdikian, W. Jerome, "Selection and Sort Extension for SLP", Internet-Draft,-] {+Schulzrinne Expires:+} February [-2002. [9]-] {+28, 2003 [Page 9] Internet Draft Gateway Location via SLP August 28, 2002 [RFC3059]+} E. Guttman, "Attribute List Extension for the Service Location Protocol", RFC 3059, February 2001. [-[10] J. Rosenberg, H. Salama, M. Bangalore, D. Shah and R. Kumar, "Usage of TRIP in Gateways for Exporting Phone Routes", Internet-Draft, November 2001. Zhao, Schulzrinne Expires: September 25, 2002 [Page 9] Internet Draft Gateway Location via SLP March 25, 2002 10.-] {+[E411] ITU-T Recommendation E.411: "International Network Management - Operational Guidance", Gen