INTERNET DRAFT Weibin Zhao draft-zhao-iptel-gwloc-slp-00.txt Henning Schulzrinne August 27, 2001 Columbia University Expires: February 27, 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. The 'service:iptel-gw:' service type template is defined for the Internet telephony gateway service. The applicability of SLP for Internet telephony gateway location is also discussed. Zhao, Schulzrinne Expires: February 27, 2002 [Page 1] Internet Draft Gateway Location via SLP August 27, 2001 1. Introduction In VoIP networks, an Internet telephony administrative domain has one or multiple routing servers, and has numerous gateways that link the Internet to the Public Switched Telephone Network (PSTN). When a call arrives, a routing server in the domain routes the call to one of these gateways. Figure 1 shows the typical scenario. | incoming call V +----------------+ +-----| Routing 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 routing server depends on many factors, including gateway availability, workload, capacity, and cost for terminating a particular call. Obtaining the up-to-date gateway information is critical for a routing server to make routing decision correctly. In this document, we will describe how to use the Service Location Protocol (SLP [1]) for the gateway and routing server communication. Also, we will define the 'service:iptel-gw:' service type template for the Internet telephony gateway service, and discuss the applicability of SLP for 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 [2]. 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 [3]. Zhao, Schulzrinne Expires: February 27, 2002 [Page 2] Internet Draft Gateway Location via SLP August 27, 2001 SLP has three different entities: User Agent (UA), Service Agent (SA), and Directory Agent (DA). SLP can be used without DAs, where a UA queries all SAs via multicast. DAs may be deployed to enhance scalability such that SAs register services with DAs, and UAs query DAs, both via unicast. Further scalability can be achieved in SLP 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. When DAs are deployed, SAs push service registrations to DAs. UAs can pull service information from all SAs via multicast, or from a DA via unicast. 3. Architecture To use SLP in the gateway and routing server communication, we need to choose the proper SLP agents for gateways and routing servers. As a gateway is a service provider for routing servers, each gateway should use an SLP SA to advertise its service. For a routing server, it has two options to interact with gateways: it can use an SLP UA to request service information from all gateways via multicast, or it can can use an SLP DA to accept and store service registrations from each gateway via unicast. There are trade-offs in using whether an SLP DA or an SLP UA as the front end of a routing server. Using an SLP UA means that the UA needs to frequently pull the gateway information from SAs via multicast, whereas using an SLP DA means that SAs need to push the gateway information to the DA via unicast. We think the push model is more suitable for the gateway and routing server interaction. First, normally there are more gateways than routing servers in a domain, it is a natural choice to let numerous gateways register with a few routing servers. Second, accepting service registrations via unicast is more efficient than requesting service information via multicast. Third, to minimize the call setup time, it is desirable for a routing server to have the required gateway information before a call arrives. Service registration provides a good support for this working style. Based on the previous analysis, we choose to use an SLP DA as the front end of each routing server to talk to gateways. The overall architecture is shown in Figure 2. This architecture uses the push model where each gateway sends its updated service information to routing servers whenever it is needed. Note that each routing server has its own SLP DA, i.e., DAs are not shared among routing servers. This is mainly for efficiency consideration. As a routing server needs to frequently consult the gateway information to make routing decision, the lookup time must be short. Ideally, a routing server Zhao, Schulzrinne Expires: February 27, 2002 [Page 3] Internet Draft Gateway Location via SLP August 27, 2001 and its front end SLP DA should be in the same machine. ........................ ........................ . +------------------+ . . +------------------+ . . | Routing Server 1 | . . | Routing Server 2 | . . +------------------+ . . +------------------+ . . | . . | . . +----------+ . . +----------+ . . +---| SLP DA |---+ . . | SLP DA | . . | +----------+ | . . +----------+ . ..|.........|........|.. ............|........... | | | | ................| ........|....... |................| . +----------+ .| . +----------+ . |. +----------+ .| . | SLP SA |--+ . | SLP SA | . +--| SLP SA |--+ . +----------+ . . +----------+ . . +----------+ . . | . . | . . | . . +----------+ . . +----------+ . . +----------+ . . | Gateway1 | . . | Gateway2 | . . | Gateway3 | . . +----------+ . . +----------+ . . +----------+ . ................ ................ ................ Figure 2. Using SLP for Gateway and Routing Server Communication When multiple routing servers are deployed in a domain, a gateway may need to push its information to several routing servers. In general, there is a many-to-many relationship between gateways and routing servers, i.e., a routing server may use multiple gateways, and a gateway may serve multiple routing servers. SLP scopes [1] can be used to manage this many-to-many relationship. 4. Gateway Operations Each gateway uses an SLP SA as its front end. The SLP SA has two basic functions: discovering routing servers and registering the gateway information to routing servers. A gateway discovers routing servers using standard SLP DA discovery mechanism, including static configuration, DHCP [4], listening to DAAdvert multicast (passive DA discovery), or multicasting the "service:directory-agent" SrvRqst (active DA discovery). A gateway registers its current information to routing servers using the 'service:iptel-gw:' template (defined Section 6). 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 make its registration with a routing Zhao, Schulzrinne Expires: February 27, 2002 [Page 4] Internet Draft Gateway Location via SLP August 27, 2001 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 routing servers, a gateway SHOULD update its registration whenever its information has a big change, such as workload increases (or decreases) 10%. A gateway SHOULD de-register its information at routing servers when its service is no longer available. A gateway registers/de-registers its information with routing servers using SLP SrvReg/SrvDeReg messages. A routing server replies with a SrvRply message to indicate whether the registration/de-registration is successful. 5. Routing Server Operations A routing server uses an SLP DA as its front end to accept and store gateway registrations. At the same time, when a call arrives, the routing server checks gateway information in its front end SLP DA, and finds a proper gateway to route the call to the gateway. A routing server can tightly couple with its front end SLP DA, where the SLP DA stores the gateway registrations in an external database, and the routing server accesses this gateway information database directly (Figure 3-a). This configuration is efficient, but the routing server needs to understand the database schema. +----------------+ +----------------+ | Routing Server | | Routing Server | +----------------+ +----------------+ | | +----------+ +----------+ | Database | | SLP UA | +----------+ +----------+ | | +------------+ +------------+ | SLP DA | | SLP DA | +------------+ +------------+ (a) Tightly Coupled (b) Loosely Coupled Figure 3. Two Configurations for Routing Server and its SLP DA In a loosely coupled configuration (Figure 3-b), a routing server interacts with its front end SLP DA via an SLP UA. This configuration incurs one more level of overhead, but the SLP DA can use an internal database which is only visible to the DA itself. Zhao, Schulzrinne Expires: February 27, 2002 [Page 5] Internet Draft Gateway Location via SLP August 27, 2001 6. Service Template for Internet Telephony Gateway The 'service:iptel-gw:' service type 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 [3] for detailed explanation of the syntax. Name of submitters: Weibin Zhao Henning Schulzrinne Language of service template: en (English) Security Considerations: As SLP uses multicast for DA discovery, the DA (and thus the routing server) information may be exposed to attachers. A routing server SHOULD use standard SLP authentication mechanism before accepting any gateway registrations. 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 = # service:iptel-gw://: workload = integer # This attribute describes the workload of the gateway. # The range of valid value is an integer 0 to 100, with 0 # indicating the lowest possible workload and 100 the highest capacity = integer # Remaining capacity: number of phone calls can be further supported phone number ranges = string M L # This attribute describes the phone number ranges that can be # reached from the gateway. It is a list of phone number range # in the form of: ,,..., # Zhao, Schulzrinne Expires: February 27, 2002 [Page 6] Internet Draft Gateway Location via SLP August 27, 2001 costs = string M L # This attribute describes the cost for each phone number range # given in the "phone number ranges" attribute. It is a list of # cost in the form of: ,,..., # Note that the number of elements in the "costs" list must be # the same as that of the "phone number ranges" list -----------------------template ends here------------------------ 7. Discussion In this section, we discuss whether SLP can meet the requirements of Internet telephony gateway discovery [5]. (1) Fast: Gateway should be discovered fast to minimize the call setup time. Using SLP, gateways send their registrations to routing servers before call setup. During a call setup, a routing server only needs to query its local SLP DA to find the proper gateway. (2) Failure Detection: Each routing 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 from routing servers by using the SrvDeReg message. (3) Startup Detection: When a failed gateway recovers, the gateway should inform routing servers rapidly. Using SLP, a recovered gateway can send a new registration to routing servers to notify its availability. (4) Capacity Knowledge: The routing 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 routing server and gateway needs to be secure. SLP provides authentication mechanism for SrvReg, SrvDeReg, and DAAdvert messages. (6) Convey Routing Information: Each routing 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 "phone number ranges" attribute in the 'service:iptel-gw:' service template. Zhao, Schulzrinne Expires: February 27, 2002 [Page 7] Internet Draft Gateway Location via SLP August 27, 2001 (7) Timeliness: A routing 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 routing 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 routing 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. Multicast may be needed only for the initial routing server discovery. Furthermore, each routing server has its own SLP DA, which means a routing server can access the gateway information locally (may be within the same machine). (10) Routing Server Control: It is desirable that a routing 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 routing server makes its own routing decision. (11) Independent Policies: If multiple routing servers exist within one administrative domain, gateways register with all available routing servers. Using SLP, routing servers can adopt different policies, and make different routing decisions. In summary, we think SLP can fulfill all the requirements, and is a good choice for the gateway and routing server communication. 8. Security Considerations As SLP uses multicast for DA discovery, the DA (and thus the routing server) information may be exposed to attachers. A routing server SHOULD use standard SLP authentication mechanism before accepting any gateway registrations. 9. References [1] E. Guttman, C. Perkins, J. Veizades and M. Day, "Service location protocol, version 2", RFC 2608, June 1999. [2] S. Bradner, "Key words for use in RFCs to indicate requirement levels", BCP 14, RFC 2119, March 1997. [3] E. Guttman, C. Perkins and J. Kempf, "Service Templates and Zhao, Schulzrinne Expires: February 27, 2002 [Page 8] Internet Draft Gateway Location via SLP August 27, 2001 Service: Schemes", RFC 2609, June, 1999. [4] C. Perkins and E. Guttman, "DHCP options for service location protocol", RFC 2610, June, 1999. [5] J. Rosenberg and H. Salama, "Usage of TRIP in Gateways for Exporting Phone Routes", Internet-Draft, July, 2001. 10. 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 11. 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: February 27, 2002 [Page 9]