INTERNET DRAFT Weibin Zhao draft-zhao-iptel-gwloc-slp-06.txt Henning Schulzrinne [Target Category: Experimental] Columbia University February 16, 2004 Expires: August 16, 2004 Locating 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 (2004). 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: August 16, 2004 [Page 1]
Internet Draft Gateway Location via SLP February 16, 2004 1. Introduction In the Internet telephony networks, an administrative domain has one or multiple location servers [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) [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 [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 [RFC2609]. Zhao, Schulzrinne Expires: August 16, 2004 [Page 2]
Internet Draft Gateway Location via SLP February 16, 2004 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 [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 [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. Zhao, Schulzrinne Expires: August 16, 2004 [Page 3]
Internet Draft Gateway Location via SLP February 16, 2004 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 [RFC3528], 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 mechanisms, including static configuration, DHCP [RFC2610], passively listening for DAAdvert (DA Advertisement) multicast, and 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: August 16, 2004 [Page 4]
Internet Draft Gateway Location via SLP February 16, 2004 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. 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 a SrvRqst followed by 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 [RFC2609] for detailed explanation of the syntax. Name of submitters: Weibin Zhao <zwb@cs.columbia.edu> Henning Schulzrinne <hgs@cs.columbia.edu> Language of service template: en (English) Security Considerations: Internet telephony gateway services are likely to be paid services, so that there could be a particular incentive to modify somebody else's registrations. The standard SLP authentication mechanism SHOULD be used for accepting service registrations. Template Text: ----------------------template begins here----------------------- template-type = iptel-gw template-version = 1.0 Zhao, Schulzrinne Expires: August 16, 2004 [Page 5]
Internet Draft Gateway Location via SLP February 16, 2004 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. To determine the cost for reaching a prefix, use # longest-prefix matching. Zhao, Schulzrinne Expires: August 16, 2004 [Page 6]
Internet Draft Gateway Location via SLP February 16, 2004 # # The cost is given in a relative manner (the smaller the better); # no cost unit is specified here. We assume that all gateways are # configured to use some default unit for cost measurement, which # implies that there is a 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 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. To determine the ASR for a prefix, # use 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: August 16, 2004 [Page 7]
Internet Draft Gateway Location via SLP February 16, 2004 # 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 -----------------------template ends here------------------------ 6. Discussion In this section, we show that SLP can meet the requirements of the Internet telephony gateway 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: August 16, 2004 [Page 8]
Internet Draft Gateway Location via SLP February 16, 2004 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 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 Internet telephony gateway services are likely to be paid services, so that there could be a particular incentive to modify somebody else's registrations. The standard SLP authentication mechanism SHOULD be used for accepting service registrations. 8. Acknowledgments The authors would like to thank Erik Guttman, Ira McDonald and James Kempf for their valuable comments. 9. Normative References [RFC2608] E. Guttman, C. Perkins, J. Veizades and M. Day, "Service location protocol, version 2", RFC 2608, June 1999. [RFC2119] S. Bradner, "Key words for use in RFCs to indicate requirement levels", BCP 14, RFC 2119, March 1997. 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. [RFC3082] J. Kempf and J. Goldschmidt, "Notification and Subscription for SLP", RFC 3082, March 2001. [RFC3528] W. Zhao, H. Schulzrinne and E. Guttman, "Mesh-enhanced Service Location Protocol (mSLP)", RFC 3528, April 2003. [RFC2610] C. Perkins and E. Guttman, "DHCP options for service location protocol", RFC 2610, June 1999. Zhao, Schulzrinne Expires: August 16, 2004 [Page 9]
Internet Draft Gateway Location via SLP February 16, 2004 [RFC3059] E. Guttman, "Attribute List Extension for the Service Location Protocol", RFC 3059, February 2001. [E411] ITU-T Recommendation E.411: "International Network Management - Operational Guidance", Geneva, 1993. 11. 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 12. Full Copyright Statement Copyright (C) The Internet Society (2004). 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: August 16, 2004 [Page 10]
