Internet Engineering Task Force IPTEL WG Internet Draft J.Rosenberg draft-rosenberg-iptel-gwreg-req-00.txt dynamicsoft November 14, 2001 Expires: May 2002 Requirements for Gateway Registration 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 To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. Abstract This document presents a set of requirements for the gateway registration protocol being developed in the iptel working group. 1 Introduction In typical VoIP networks, Internet Telephony Administrative Domains (ITADs) will deploy numerous gateways for the purposes of geographical diversity, capacity, and redundancy [1]. When a call arrives at the domain, it must be routed to one of those gateways. Frequently, an ITAD will break their network into geographic POPs, with each POP containing some number of gateways, and a proxy server element that fronts those gateways. The proxy server is responsible for managing the access to the POP, and also for determining which of the gateways will receive any given call that arrives at the POP. J.Rosenberg [Page 1]
Internet Draft gwreg-req November 14, 2001 This configuration is depicted graphically in Figure 1. +---------+ | | | GW | > +---------+ // // // +---------+ // | | // | GW | // +---------+ // +----------+ // TO PSTN | | / +---------+ | Routing | -------> | | -----> -------->| Proxy | ------- | GW | | | -- +---------+ | | -- +----------+ -- --- +---------+ -- | | -- | GW | -- +---------+ --> +---------+ | | | GW | +---------+ Figure 1: Gateway and LS Configuration The decision about which gateway to use depends on many factors, including their availability, remaining call capacity, and cost for terminating to a particular POTS number. For the proxy to do this adequately, it needs to have access to this information in real-time, as it changes. This means there must be some kind of communications between the proxy and the gateways to convey this information. This draft presents a set of requirements for this communications. 2 Requirements J.Rosenberg [Page 2]
Internet Draft gwreg-req November 14, 2001 The mechanism used to communicate between the gateway and the proxy needs to meet several requirements: REQ 1: Fast: Call setup time is affected if the protocol requires communications between the proxy and the gateway at the actual time of call setup. Therefore, such communications should be minimized, ideally occuring before call setup. REQ 2: Failure Detection: One of the most imporant pieces of information for the proxy to know is the availability of the gateway. There must be a way for the proxy to rapidly detect failures of gateways, so that alternates can be used. REQ 3: Startup Detection: When a failed gateway recovers, there must be a way for the proxy to determine this rapidly and automatically, so that it can begin using it again to terminate calls. REQ 4: Capacity Knowledge: The proxy must have a way to determine with high probability, in advance of a call, that the gateway selected has sufficient capacity to terminate the call. Knowing this in advance of the call helps keep call setup delays uniform even during periods of heavy usage. REQ 5: Secure: The communications between the proxy and gateway need to provide mutual authentication and message integrity. Privacy may be required, but it is less critical. The associations between proxies and gateways are long lived. REQ 6: Convey Routing Preferences: Each gateway is configured with set of POTS numbers that is capable of terminating to with a variety of costs. The information on which ranges of phone numbers a gateway can terminate to, and with what relative preference, need to be propagated to the proxy. OPEN ISSUE: It has been argued in the past that in real configurations, the proxy would be directly programmed with this information, rather than having the gateways propagate it to the proxy. As such, we need to debate whether this is really a requirement. REQ 7: Timeliness: The information that the proxy learns about the characterisitcs of the gateway - its availability, J.Rosenberg [Page 3]
Internet Draft gwreg-req November 14, 2001 capacity, and route preferences - must be learned in a timely fashion. Here, timely is on the order of seconds or less. REQ 8: Extensible attributes: The proxy may need to know other information about the gateways - ISUP variant support, codec support, etc., in order to route a call to a gateway. The protocol has to provide a way for this kind of information to be easily added. OPEN ISSUE: This requirement may be moot if its decided that REQ 6 is not really a requirement. Effectively, if REQ 6 is not a requirement, we don't need propagation of static information from the gateway to the proxy. That would include additional attributes such as the ones mentioned here. OPEN ISSUE: Are these attributes characteristic of routes, or of the gateway itself? TRIP defines them as attributes of routes, and this means that they would be copied for each route that gets propagated. For other attributes, like capacity, it could not be copied, and the capacity would have to be divided amongst routes. How would that be done? Points to a potential open hold in TRIP usage for this application. REQ 9: Efficient: The protocol should not generate too much traffic. OPEN ISSUE: Need to quantify this. REQ 10: Proxy Control: The protocol should put the proxy in control of making a decision about where the call should ultimately be routed. This facilitates distribution of information (from the gateways) but centralization of policy. REQ 11: Independent Policies: The protocol should allow two different proxies within the same ITAD to make different decisions on which gateway to use for the same call. This might be desirable for load balancing purposes, for example. J.Rosenberg [Page 4]
Internet Draft gwreg-req November 14, 2001 OPEN ISSUE: This is an important one to discuss, since it is the main differentiator between a routing protocol and a database protocol. If we don't need different proxies to get different answers about gateway availability depending on which proxy asks, its not a routing problem, and then TRIP may not be the ideal candidate for this usage! REQ 12: Discovery: The protocol should allow the proxy to dynamically discover the set of gateways that it can route to. OPEN ISSUE: Its not clear that this really needed. Static configuration is most common today. This requirement has a strong impact on the solution which is chosen. 3 Authors Address Jonathan Rosenberg dynamicsoft 72 Eagle Rock Avenue First Floor East Hanover, NJ 07936 email: jdrosen@dynamicsoft.com 4 Bibliography [1] J. Rosenberg and H. Schulzrinne, "A framework for telephony routing over IP," Request for Comments 2871, Internet Engineering Task Force, June 2000. J.Rosenberg [Page 5]