Internet Engineering Task Force IPTEL WG Internet Draft J.Rosenberg,H.Salama draft-rs-trip-gw-00.txt dynamicsoft, Cisco March 10, 2000 Expires: September, 2000 Usage of TRIP in Gateways for Exporting Phone Routes 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. Abstract This document describes a new application of the Telephony Routing over IP (TRIP) protocol. TRIP was engineered as a tool for inter- domain exchange of telephone routing information. However, it can also be used as a means for gateways and soft switches to export their routing information to a Location Server (LS), which may be co-resident with a proxy or gatekeeper. We discuss the motivations for this application, the reasons why other mechanims, such as the SIP REGISTER method, are not appropriate, and then show how a minimal subset of TRIP is needed for this application. 1 Introduction In typical VoIP deployments, a service provider runs a network composed of numerous gateways, softswitches, and proxy servers. J.Rosenberg,H.Salama [Page 1] Internet Draft TRIP for Gateways March 10, 2000 Generally, gateways (both composed and decomposed) are distributed geograpically throughout the network. When a gateway terminates a call to a number, cost to the service provider is incurred. This cost is partly dependent on the cost of making a call over the PSTN from the gateway to the destination number. By placing gateways in numerous locations over the globe, the service provider can be sure it can terminate calls to the PSTN with minimal cost. When calls arrive at the network (either from customers of the provider, or from peer providers desiring termination service), they are first sent to a proxy which acts as a routing engine. Based on the knowledge of available gateways, and the telephone numbers each gateway can terminate calls to, the proxy forwards the call to the appropriate gateway. This configuration is the most commonly used way to route calls within a domain. This configuration is depicted graphically in Figure 1. +---------+ | | | GW | > +---------+ // // // +---------+ // | | // | GW | // +---------+ // +----------+ // TO PSTN | | / +---------+ | Routing | -------> | | -----> -------->| Proxy | ------- | GW | | | -- +---------+ | | -- +----------+ -- --- +---------+ -- | | -- | GW | -- +---------+ --> +---------+ | | | GW | +---------+ J.Rosenberg,H.Salama [Page 2] Internet Draft TRIP for Gateways March 10, 2000 Figure 1 There are two problems that must be solved in order to enable this scenario: o Often, the routing tables in the routing proxies are manually entered. This makes configuration more complex, particularly for large networks with hundreds or even thousands of gateways. In the ideal scenario, each gateway is configured with the numbers it can terminate calls to, and with the address of the routing proxies. The gateways then push their routing information to the proxy. No standard mechanism has been specified to do this. o It is important for the routing proxy to be aware of failures of gateways. This way, an alternate gateway can be selected for new incoming calls. This requires some kind of keepalive between the gateways and the routing proxy. No standard mechanism yet exists for this keepalive. This document discusses how TRIP [1] can be used to solve these two problems. The first section reviews other mechanisms for accomplishing this - namely the SIP [2] REGISTER method, and discusses why TRIP is a much better solution. We assume the reader is familiar with TRIP. An overview of its architecture can be found in [3]. 2 Why not SIP REGISTER? The SIP REGISTER method has frequently been proposed as a solution for these two problems. This is due, in part, to the similarity of the REGISTER method to the H.323 [4] RAS messages. In H.323, RAS messages are used to allow gateways to register telephone number prefixes with a gatekeeper. Many assume that SIP REGISTER should therefore play a similar role. Certainly, the REGISTER mechanism is close to this functionality. REGISTER allows clients to send address bindings (including for telephone numbers) to a proxy. Registrations are also periodically refreshed, allowing a proxy to determine if the address binding becomes stale, perhaps due to a crash or device failure. The refresh timer (present in the Expires header) can even be negotiated by the proxy. However, the SIP REGISTER mechanism is different from the desired J.Rosenberg,H.Salama [Page 3] Internet Draft TRIP for Gateways March 10, 2000 mechanisms for gateways in many respects: o The REGISTER mechanism is used to bind a single incoming URI to one or more outgoing URIs. In the case of a telephony gateway, the binding is between a set of telephone prefixes to the address of a gateway. This is a significantly different binding, and cannot be represented with the syntax or semantics of a SIP REGISTER request. o The keepalive mechanism in REGISTER refreshes the *binding*, not the status of the UA performing the registration. The bindings must be sent each time to keep them alive. In the case of a gateway, the keepalive is for the state of the gateway, not for the routes the gateway terminates. The semantics of REGISTER would need to be completely changed in order to support this different semantic. o There are properties associated with gateway routes that are not associated with URIs. For example, a route may have information like capacity (how many simultaneous calls can be terminated), which does not make much sense for a property of a URI. o Because gateways can handle so many calls, it is important for liveness information to be conveyed very frequently, on the order of seconds. SIP registrations are not meant to be sent that frequently; they can be fairly large messages (particularly if they need to contain the routes when refreshed), resulting in uneeded overheads. For these reasons, we do not believe the SIP REGISTER request is the right tool for gateway route propagation and gateway keepalives. 3 Why TRIP? TRIP was engineered as a tool for interdomain route exchange. It is not a simple protocol, and at first glance, does not seem appropriate for application in a gateway. However, TRIP provides exactly the features needed to solve the problem at hand. TRIP allows one entity (in this case, a gateway) to convey to another (in this case, a proxy) a set of telephone routes which terminate through it. These routes are represented by telephone number prefixes. In TRIP, the routing tables are exchanged once. Only when they change are updates sent. This is exactly the capability needed for a gateway to send its routing information to a proxy. TRIP also supports a keepalive between peers. This keepalive is a J.Rosenberg,H.Salama [Page 4] Internet Draft TRIP for Gateways March 10, 2000 short message, sent fairly frequently. It does not contain routing information. The period of the keepalive is negotiated once at startup time. If one of the entities crashes, the other flushes all routes received from it. This, too, is exactly the mechanism needed for keepalives in a gateway. Another advantage of using TRIP here is that it makes the redistribution of local gateway reachability information into inter- domain TRIP straightforward, because it's the same protocol. While it is true that TRIP is complex, almost all of this complexity is related to the processing of routes *received* from other peers. An element, such as a gateway, which only *sends* routes to a peer (the proxy), does not need to implement any of those functions. In particular, any processing related to aggregation, TRIB updates, route propagation and advertisement, handling of transitivity and unknown routes, or the decision process need not be implemented. The resulting set of functions are very small. They are composed of only: o The initial OPEN phase, exchange of keepalive timers, and the process of bringing up the state machine. o Sending of an UPDATE containing the routes and parameters of the gateways. o Sending of a periodic keepalive. Its worth noting that these functions are not substantially more complex than sending a periodic REGISTER. The sections which follow describe the processing in more detail. 4 Gateway Operation The protocol a gateway uses to advertise its E.164 reachability to the its domain's Location Server(s) (LS)is TRIP. The gateway operates in TRIP Send Only mode since it is only interested in advertising its reachability, but is not interested in learning about the reachability of other gateways and other domains. Also, the gateway will not create its own call routing database. Therefore, the gateway does not need a complete implementation of TRIP. A lightweight version of the protocol is sufficient. In this section we describe the operation of TRIP on a gateway. We refer to the protocol operating in this context as TRIP for Gateways, or TRIP-GW. TRIP-GW is a stripped down version of TRIP, but still completely interoperable with normal TRIP speakers. It is an implementation profile, not an extension or incompatible reduction. J.Rosenberg,H.Salama [Page 5] Internet Draft TRIP for Gateways March 10, 2000 The reader is assumed to be familiar with TRIP. In our discussion we will skip most of the details common to both versions. 4.1 Session Establishment When opening a peering session with a TRIP LS, an TRIP-GW gateway follows exactly the same procedures as any other TRIP speaker. The TRIP-GW gateway sends an OPEN message which includes a Send Receive Capability in the Optional Parameters. The Send Receive Capability is set by the gateway to Send Only. When the TRIP LS receives the gateway's OPEN message, it set its local policy such that no UPDATE messages are sent to the TRIP-GW gateway. The remainder of the peer session establishment is identical to TRIP. 4.2 UPDATE Messages Once the peer session has been established, the gateway sends UPDATE messages to the TRIP LS with the gateway's entire E.164 reachability and its ITAD topology. If the gateway's E.164 reachability or its ITAD topology changes at any point in time, the gateway MUST generate UPDATE message(s) with the change. The frequency of successive UPDATE messages MUST follow the same rules specified for TRIP [1]. The TRIP-GW gateway MUST at least support all mandatory TRIP attributes. If the gateway receives an UPDATE message from the TRIP LS, it MUST silently discard it as specified in [1]. No further action should be taken. 4.3 KEEPALIVE Messages KEEPALIVE messages are periodically exchanged over the peering session between the TRIP-GW gateway and the TRIP LS as specified in Section 5.4 of [1]. 4.4 Error Handling and NOTIFICATION Messages The same procedures used with TRIP, are used with TRIP-GW for error handling and generating NOTIFICATION messages. The only difference is that an TRIP-GW gateway will never generate a NOTIFICATION message in response to an UPDATE message, irrespective of the contents of the UPDATE message. Any UPDATE message is silently discarded. 4.5 TRIP-GW Finite State Machine When the TRIP-GW finite state machine is in the Established state and an UPDATE message is received, the UPDATE message is silently J.Rosenberg,H.Salama [Page 6] Internet Draft TRIP for Gateways March 10, 2000 discarded and the TRIP-GW gateway remains in the Established state. Other than that the TRIP finite state machine and the TRIP-GW finite state machine are identical. 4.6 Call Routing Databases A TRIP-GW gateway may maintain simultaneous sessions with more than one TRIP LSs. A TRIP-GW gateway maintains one call routing database per peer TRIP LS. These databases are equivalent to TRIP's Adj- TRIBs-Out, and hence we will call them Adj-TRIB-GWs-Out. An Adj- TRIB-GW-Out contains the gateway's E.164 reachability information advertised to its peer TRIP LS. How an Adj-TRIB-GW-Out database gets populated is outside the scope of this draft (possibly by manual configuration). The TRIP-GW gateway does not have databases equivalent to TRIP's Adj-TRIBs-In and Loc-TRIB, because the TRIP-GW gateway does not learn routes from its peer TRIP LSs, and hence it does not run call route selection. 4.7 Route Selection and Aggregation TRIP's route selection and aggregation operations SHOULD NOT be implemented by TRIP-GW gateways. 5 Conclusion We have argued that the problem of propagating routes from a gateway to a Location Server, and of maintaining liveness of the gateway, are best handled through TRIP rather than a SIP REGISTER message or H.323 RAS message. 6 Authors Addresses Jonathan Rosenberg dynamicsoft 200 Executive Drive Suite 120 West Orange, NJ 07052 email: jdrosen@dynamicsoft.com Hussein F. Salama Cisco Systems Mail Stop SJ-6/3 170 W. Tasman Drive San Jose, CA 95134 J.Rosenberg,H.Salama [Page 7] Internet Draft TRIP for Gateways March 10, 2000 email: hsalama@cisco.com 7 Bibliography [1] J. Rosenberg, H. Salama, and M. Squire, "Telephony routing over IP (TRIP)," Internet Draft, Internet Engineering Task Force, Jan. 2000. Work in progress. [2] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: session initiation protocol," Request for Comments (Proposed Standard) 2543, Internet Engineering Task Force, Mar. 1999. [3] J. Rosenberg and H. Schulzrinne, "A framework for telephony routing over IP," Internet Draft, Internet Engineering Task Force, Nov. 1999. Work in progress. [4] International Telecommunication Union, "Packet based multimedia communication systems," Recommendation H.323, Telecommunication Standardization Sector of ITU, Geneva, Switzerland, Feb. 1998. Full Copyright Statement Copyright (c) The Internet Society (2000). 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 J.Rosenberg,H.Salama [Page 8] Internet Draft TRIP for Gateways March 10, 2000 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. J.Rosenberg,H.Salama [Page 9]