Internet Engineering Task Force IPTEL WG Internet Draft J.Rosenberg,H.Salama draft-rs-trip-gw-01.txt dynamicsoft, Cisco July 14, 2000 Expires: January 2001 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. This LS can then manage those gateway resources. 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 J.Rosenberg,H.Salama [Page 1]
Internet Draft TRIP for Gateways July 14, 2000 composed of numerous gateways, softswitches, and proxy servers. 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, their capacity (in terms of circuit and DSP resources) and other attributes, and the telephone numbers each gateway can terminate calls to, the proxy forwards the call to the appropriate gateway. In essence, the LS/proxy is responsible for managing the real-time resources made available by a set of gateways. This configuration is depicted graphically in Figure 1. There are several 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. o The routing proxy will need to route call setup requests to the gateways based on dynamic attributes of those gateways. In particular, the available capacity, measured in terms of both circuit resources and coding resources, is used to properly route calls. The proxy can, for example, perform load balancing by forwarding call setups to the most lightly loaded gateway among a set. No standard mechanism has been specified to do this. J.Rosenberg,H.Salama [Page 2]
Internet Draft TRIP for Gateways July 14, 2000 +---------+ | | | GW | > +---------+ // // // +---------+ // | | // | GW | // +---------+ // +----------+ // TO PSTN | | / +---------+ | Routing | -------> | | -----> -------->| Proxy | ------- | GW | | | -- +---------+ | | -- +----------+ -- --- +---------+ -- | | -- | GW | -- +---------+ --> +---------+ | | | GW | +---------+ Figure 1: Gateway and LS Configuration 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 J.Rosenberg,H.Salama [Page 3]
Internet Draft TRIP for Gateways July 14, 2000 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 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 J.Rosenberg,H.Salama [Page 4]
Internet Draft TRIP for Gateways July 14, 2000 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 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. TRIP can contain attributes describing a route. New attributes can easily be added. The available capacity of a route is needed by the proxies to properly load balance and route to a set of gateways. This capacity can be expressed as an attribute. 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 rest of this document is organized as follows. Section 4 J.Rosenberg,H.Salama [Page 5]
Internet Draft TRIP for Gateways July 14, 2000 discusses a new attribute, circuit capacity, and section 5 discusses another new attribute, DSP capacity. These new attributes contain dynamic capacity of gateways that can be propagated to the LS managing those gateways. Section 6 describes the processing rules needed for a gateway, and section 7 discusses some of the processing needed in an LS. 4 CircuitCapacity Attribute Mandatory: False. Required Flags: optional, non-transitive Potential Flags: None. TRIP Type Code: TBD. The circuit capacity attribute is used only between a gateway and its peer LS responsible for managing that gateway. It is for this reason that this attribute is non-transitive. If it is received in a route, it SHOULD NOT be propagated unless the LS is sure that it is relatively static. The circuit capacity identifies the number of PSTN circuits that are currently available on a route to terminate calls. The number of additional calls sent to that gateway for that route can not exceed the circuit capacity. If it does, the signaling protocol will likely generate errors, and calls will be rejected. Circuit capacity is measured in integral number of calls. It changes very dynamically. 4.1 CircuitCapacity Syntax The CircuitCapacity attribute is a 4-octet unsigned numbeic value. It represents the number of circuits remaining for terminating calls to this route. This attribute represents a potentially achievable lower bound on the number of calls which can additionally forwarded on this route. 4.2 Route Origination and CircuitCapacity Routes MAY be originated containing the CircuitCapacity attribute. Since this attribute is highly dynamic, changing with every call, updates MAY be sent as it changes. However, it is RECOMMENDED that a gateway originating routes with this attribute use thresholds, and that routes are re-originated only when the attribute moves above or J.Rosenberg,H.Salama [Page 6]
Internet Draft TRIP for Gateways July 14, 2000 below a treshold. It is also RECOMMENDED that the thresholds in each direction (going above a threshold and going below a threshold) be different, thus achieving a form of hysterisis. Both of these measures help reduce the messaging load from route origination. 4.3 Route Selection and CircuitCapacity The CircuitCapacity attribute MAY be used for route selection. Since one of its primary applications is load balancing, an LS will wish to choose a potentially different route (amonst a set of routes for the same prefix) on a call by call basis. This can be modeled as re- running the decision process on the arrival of each call. The aggregation and dissemination rules for routes with this attribute ensure that re-running this selection process never results in propagation of a new route to other peers. 4.4 Aggregation and CircuitCapacity An LS MUST aggregate routes to the same prefix which contain a CircuitCapacity attribute. This guarantees that if the decision process is rerun, the route that is disseminated to peers is unchanged. 4.5 Route Dissemination and CircuitCapacity Routes SHOULD NOT be disseminated with the CircuitCapacity attribute. The attribute is meant to reflect capacity at the originating gateway only. Its highly dynamic nature makes it inappropriate to disseminate in most cases. 5 DSPCapacity attribute Mandatory: False. Required Flags: optional, non-transitive Potential Flags: None. TRIP Type Code: TBD. The DSPCapacity attribute is used only between a gateway and its peer LS responsible for managing that gateway. It is for this reason that this attribute is non-transitive. If it is received in a route, it SHOULD NOT be propagated unless the LS is sure it is relatively static in value. The DSPcapacity identifies the amount of DSP resources, in MIPS, that J.Rosenberg,H.Salama [Page 7]
Internet Draft TRIP for Gateways July 14, 2000 are currently available on a route to terminate calls. The metric should be considered as only an approximate. The MIPS are computed based on a specific processor (TBD); other processors will need to perform a conversion to obtain this normalized parameter. It is assumed that the LS is aware of the DSP resource requirements for each call, based on the set of codecs indicated in the messages routed by the LS/proxy. There is lots of handwaving here. Can we usefully define this metric? How to determine how much DSP resources are really required to terminate a call? Also, the codec used may not be known at the time the message is to be routed. This can happen with both SIP (when the SDP in the INVITE is empty), and H.323. How to handle this? DSP capacity is measured in integral number of MIPS. It changes very dynamically. 5.1 DSPCapacity Syntax The DSPCapacity attribute is a 4-octet unsigned numbeic value. It represents the number of MIPS remaining for terminating calls to this route. 5.2 Route Origination and DSPCapacity Routes MAY be originated containing the DSPCapacity attribute. Since this attribute is highly dynamic, changing with every call, updates MAY be sent as it changes. However, it is RECOMMENDED that a gateway originating routes with this attribute use thresholds, and that routes are re-originated only when the attribute moves above or below a treshold. It is also RECOMMENDED that the tresholds in each direction (going above a threshold and going below a threshold) be different, thus achieving a form of hysterisis. Both of these measures help reduce the messaging load from route origination. 5.3 Route Selection and DSPCapacity The DSPCapacity attribute MAY be used for route selection. Since one of its primary applications is load balancing, an LS will wish to choose a potentially different route (amonst a set of routes for the same prefix) on a call by call basis. This can be modeled as re- running the decision process on the arrival of each call. The aggregation and dissemination rules for routes with this attribute ensure that re-running this selection process never results in propagation of a new route to other peers. J.Rosenberg,H.Salama [Page 8]
Internet Draft TRIP for Gateways July 14, 2000 5.4 Aggregation and DSPCapacity An LS MUST aggregate routes to the same prefix which contain a DSPCapacity attribute. This guarantees that if the decision process is rerun, the route that is disseminated to peers is unchanged. 5.5 Route Dissemination and DSPCapacity Routes SHOULD NOT be disseminated with the DSPCapacity attribute. The attribute is meant to reflect capacity at the originating gateway only. Its highly dynamic nature makes it inappropriate to disseminate. 6 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. The reader is assumed to be familiar with TRIP. In our discussion we will skip most of the details common to both versions. 6.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. 6.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 J.Rosenberg,H.Salama [Page 9]
Internet Draft TRIP for Gateways July 14, 2000 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. 6.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]. 6.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. 6.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 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. 6.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 J.Rosenberg,H.Salama [Page 10]
Internet Draft TRIP for Gateways July 14, 2000 selection. 6.7 Route Selection and Aggregation TRIP's route selection and aggregation operations SHOULD NOT be implemented by TRIP-GW gateways. 7 LS Behavior TRIP completely specifies the behavior of the LS as a TRIP speaker. However, the primary question is: is an LS connected to a gateway an internal or external peer of the gateway? The most obvious choice, internal peer, is not the best choice. If an LS has ten peer GWs, all of them advertising reachability to 1408*, it will flood all ten routes to all other LSs in the same ITAD. This won't scale, because each LS in the ITAD will have to create a separate Adj-TRIB-In for each GW in that ITAD. In addition, it doesn't allow a SIP Proxy server or an H.323 GK to load balance among the GWs of its zone/subdomain. A similar problem exists when an LS is an external peer to the gateways, and has direct peering relationships with one or more internal peers. However, an ingress LS to an ITAD does not perform aggregation. Only the egress aggregates routes. Therefore, it is RECOMMENDED that the appropriate architecture is that the LS actually runs two instances of TRIP; one with an external peering relationship to the gateways, and the other with an internal peering relationship with one or more LS's within the ITAD. The interface between these instances is a local matter; routes are exported from one and imported to the other. This architecture is shown in Figure 2. 8 Conclusion We have argued that the problem of managing a set of gateways from a location server is critical. This process of management includes propagation of routes, liveness determination, and propagation of available capacity for the purposes of load balancing. TRIP is ideally suited for these problems. As such, we propose here to define TRIP-GW, a subset of TRIP functionality (yet still 100% compatible with it) for use on gateways to perform this function. 9 Changes since -00 o Added text to stress the value of this proposal for managing a J.Rosenberg,H.Salama [Page 11]
Internet Draft TRIP for Gateways July 14, 2000 +-----+ | | .................................... --| GW | . +-------------.------------+ --- +-----+ . | +--------+ .+--------+ | -- . | |TRIP | .|TRIP | +-- +-----+ . |/|Instance| .|Instance|--| | | . / | | .| |--+-------- | GW | . /| | | .| |--| +-----+ . / | +--------+ .+--------+ +--- . / | LS. | --- +-----+ . / +-------------.------------+ -- | | . / . | GW | . +----------+ . +-----+ . | | . . | | . . | LS | . . | | . . | | . . +----------+ . +-----+ . \ . | | . \ . -- | GW | . \ +-------------.------------+ -- +-----+ . \ | +--------+ .+--------+ | --- . \ | |TRIP | .|TRIP | +- +-----+ . \| |Instance| .|Instance|--| | | . \ | | .| |--+---------| GW | . | | | .| |--| +-----+ . | +--------+ .+--------+ +--- . | LS. | --- +-----+ . +-------------.------------+ -- | | . ITAD . | GW | .................................... +-----+ Figure 2: LS Architecture for TRIP-GW J.Rosenberg,H.Salama [Page 12]
Internet Draft TRIP for Gateways July 14, 2000 gateway cluster o Added attributes for circuit capacity and DSP capacity o Added section on LS operation, discussing aggregation issue 10 Authors Addresses Jonathan Rosenberg dynamicsoft 72 Eagle Rock Avenue First Floor East Hanover, NJ 07936 email: jdrosen@dynamicsoft.com Hussein F. Salama Cisco Systems Mail Stop SJ-6/3 170 W. Tasman Drive San Jose, CA 95134 email: hsalama@cisco.com 11 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 2543, Internet Engineering Task Force, Mar. 1999. [3] J. Rosenberg and H. Schulzrinne, "A framework for telephony routing over ip," Request for Comments 2871, Internet Engineering Task Force, June 2000. [4] International Telecommunication Union, "Packet based multimedia communication systems," Recommendation H.323, Telecommunication Standardization Sector of ITU, Geneva, Switzerland, Feb. 1998. J.Rosenberg,H.Salama [Page 13]