Internet Engineering Task Force IPTEL WG Internet Draft J.Rosenberg,H.Salama draft-rs-trip-gw-02.txt dynamicsoft, Cisco July 20, 2001 Expires: February 2002 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 To view the list Internet-Draft Shadow Directories, see 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 networks, Internet Telephony Administrative Domains J.Rosenberg,H.Salama [Page 1]
Internet Draft TRIP for Gateways July 20, 2001 (ITADs) will deploy numerous gateways for the purposes of geographical diversity, capacity, and redundancy. 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. 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, J.Rosenberg,H.Salama [Page 2]
Internet Draft TRIP for Gateways July 20, 2001 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. In this document, we propose the usage of TRIP to communicate this information from the gateways to the proxies that make the call routing decision. Section 2 outlines requirements for this communication. Section 3 looks at usage of SIP REGISTER [1], Section 4 looks at SLP [2], and then Section 5 looks at TRIP [3,4]. We then describe the details of a TRIP solution in Section 6. It is assumed that the reader is familiar with these protocols. 2 Requirements 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. J.Rosenberg,H.Salama [Page 3]
Internet Draft TRIP for Gateways July 20, 2001 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, 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. J.Rosenberg,H.Salama [Page 4]
Internet Draft TRIP for Gateways July 20, 2001 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. 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! 3 SIP REGISTER The SIP REGISTER method has frequently been proposed as a solution for this problem. This is due, in part, to the similarity of the REGISTER method to the H.323 [5] 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, which is close to meeting requirement REQ6. Registrations are also periodically refreshed, allowing a proxy to determine if the address binding becomes stale, perhaps due to a crash or device failure. This might allow requirement REQ2 to be met. The refresh timer (present in the Expires header) can even be negotiated by the proxy, providing for the ability to make information timely, as required by requirement REQ7. 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 J.Rosenberg,H.Salama [Page 5]
Internet Draft TRIP for Gateways July 20, 2001 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. Therefore, REGISTER does not actually meet requirement REQ 6. 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. Therefore, REGISTER does not actually meet requirement REQ 2. 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. Therefore, requirements REQ 4 and REQ 8 are not met. 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. This means that requirement REQ 9 cannot be met simultaneously with requirement REQ 7. For these reasons, we do not believe the SIP REGISTER request is the right tool for gateway route propagation and gateway keepalives. 4 SLP The Service Location Protocol (SLP) provides a means for a client to discover a server resource (the gateway in this case) to terminate the call. We see two potential usage scenarios for SLP. In case 1, the gateways act as service agents, and the proxy acts like a directory agent. There is no SLP user agent. When a call arrives at the proxy, the information learned through SLP service advertisements is used to route the call. This is not the typical usage for SLP. The more typical usage is case 2. In that case, there is no DA. The proxy acts as an SLP user agent (not the same as a SIP user agent!), and sends out SLP ServiceRequest messages when a call arrives. These are multicast, and in them includes criteria about what characteristics of a gateway are needed. Matching gateways respond, and the proxy chooses one. J.Rosenberg,H.Salama [Page 6]
Internet Draft TRIP for Gateways July 20, 2001 In its case 2 usage, SLP meets most of the requirements outlined in Section 2. However, it does not meet REQ 11, which mandates the policy control be in the hands of the proxy independently. This is because in the SLP model, the gateways would be responsible for determining whether to respond to a query for service, and therefore they would have control over service usage policies. This is counter to REQ 11, which mandates that each proxy get to define its own policies for service usage. Another problem for case 2 is requirement REQ 1. This is because SLP would require a query every time a call is made. This will increase call setup time by the query generation, transmission, processing, response, and response processing times. It also is counter to requirement REQ 9, since messaging is generated for each call attempt (and multicast as well). In this usage, SLP also seems inappropriate based on its assumptions about the service. SLP assumes there are lots of clients, who communicate with servers whose location and characteristics are not known to the clients apriori. Requests from any particular client are infrequent and far apart, so usage of persistent SLP connections makes little sense. However, in the gateway registration problem domain, these assumptions are not true. There are a small number of "clients" (proxies in this case), who communicate with servers (gateways) whose locations are known to the clients apriori. Requests from any particular "client" are frequent, so use of persisent communications between the two does make sense. In usage case 1, however, things are different. Requirements REQ 1 and REQ 9 do appear to be met. Its worth noting that it is not clear what the functional differences are between SLP in such an unusual usage case, and TRIP (for which this is its normal operating mode). More investigation is required. 5 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 along with attributes that can express cost and preferences (meeting requirement REQ 6). 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 J.Rosenberg,H.Salama [Page 7]
Internet Draft TRIP for Gateways July 20, 2001 information to a proxy, and it allows TRIP to meet requirements REQ 9 and REQ 7. Since the routing information is sent as soon as it changes, it does not require communications to occur during call setup, and therefore requirement REQ 1 is met. 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 meets requirements REQ 2 and REQ 3. 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. This meets requirements REQ 4 and REQ 8. TRIP can be run over IPSec or TLS between two peers, providing authentication, integrity and privacy. This meets requirement REQ 5. 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. 6 Defining TRIP-GW We call the subset of TRIP needed for this application "TRIP-GW", or TRIP for gateways. We note that this is a valid subset defined by the J.Rosenberg,H.Salama [Page 8]
Internet Draft TRIP for Gateways July 20, 2001 specification, so that a TRIP-GW speaker is a conformat TRIP speaker. New attributes need to be defined, such as circuit capacity (Section 6.1. The gateway and proxy behaviors are discussed in more details in sections 6.2 and 6.3 respectively. 6.1 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. 6.1.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. 6.1.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 below a treshold. It is also RECOMMENDED that the thresholds in each direction (going above a threshold and going below a threshold) be J.Rosenberg,H.Salama [Page 9]
Internet Draft TRIP for Gateways July 20, 2001 different, thus achieving a form of hysterisis. Both of these measures help reduce the messaging load from route origination. 6.1.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. 6.1.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. 6.1.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. 6.2 Gateway Operation The protocol a gateway uses to advertise its E.164 reachability to the its domain's Location Server(s) (LS, which are generally proxies) 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. 6.2.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 J.Rosenberg,H.Salama [Page 10]
Internet Draft TRIP for Gateways July 20, 2001 messages are sent to the TRIP-GW gateway. The remainder of the peer session establishment is identical to TRIP. 6.2.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 [3]. 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 [3]. No further action should be taken. 6.2.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 [3]. 6.2.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.2.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.2.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 J.Rosenberg,H.Salama [Page 11]
Internet Draft TRIP for Gateways July 20, 2001 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. 6.2.7 Route Selection and Aggregation TRIP's route selection and aggregation operations SHOULD NOT be implemented by TRIP-GW gateways. 6.3 LS/Proxy 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. 7 Changes since -01 o Added requirements. o Added more formal analysis of REGISTER and added analysis of SLP. J.Rosenberg,H.Salama [Page 12]
Internet Draft TRIP for Gateways July 20, 2001 +-----+ | | .................................... --| 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 13]
Internet Draft TRIP for Gateways July 20, 2001 o Removed circuit capacity attribute. 8 Changes since -00 o Added text to stress the value of this proposal for managing a gateway cluster o Added attributes for circuit capacity and DSP capacity o Added section on LS operation, discussing aggregation issue 9 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 10 Bibliography [1] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: session initiation protocol," Request for Comments 2543, Internet Engineering Task Force, Mar. 1999. [2] E. Guttman, C. Perkins, J. Veizades, and M. Day, "Service location protocol, version 2," Request for Comments 2608, Internet Engineering Task Force, June 1999. [3] J. Rosenberg, H. Salama, and M. Squire, "Telephony routing over IP (TRIP)," Internet Draft, Internet Engineering Task Force, Nov. 2000. Work in progress. [4] J. Rosenberg and H. Schulzrinne, "A framework for telephony routing over IP," Request for Comments 2871, Internet Engineering J.Rosenberg,H.Salama [Page 14]
Internet Draft TRIP for Gateways July 20, 2001 Task Force, June 2000. [5] 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 15]