IPTEL Working Group J. Rosenberg, dynamicsoft Internet Draft H. Salama, Cisco Systems draft-rs-trip-gw-03.txt M. Bangalore, Cisco Systems November 2001 D. Shah, Cisco Systems Expiration Date: May 2002 R. Kumar, Cisco Systems 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. Rosenberg, Salama, Bangalore, Shah [Page 1] Internet Draft draft-rs-trip-gw-03.txt November 2001 1. Introduction In typical VoIP networks, Internet Telephony Administrative Domains (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, including their availability, remaining call capacity, and cost for Rosenberg, Salama, Bangalore, Shah [Page 2] Internet Draft draft-rs-trip-gw-03.txt November 2001 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 looks at usage of SIP REGISTER [1], and Section 3 looks at TRIP [3,4]. We then describe the details of a TRIP solution in Section 4. It is assumed that the reader is familiar with these protocols. The requirements referenced in the sections that follow as "REQ #" are defined in [6]. 2. 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 REQ 6. 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 REQ 2 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 REQ 7. However, the SIP REGISTER mechanism is different from the desired mechanisms for gateways in many respects: - 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. Therefore, REGISTER does not actually meet requirement REQ 6. - 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 Rosenberg, Salama, Bangalore, Shah [Page 3] Internet Draft draft-rs-trip-gw-03.txt November 2001 would need to be completely changed in order to support this different semantic. Therefore, REGISTER does not actually meet requirement REQ 2. - 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. - 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. 3. TRIP TRIP was engineered as a tool for interdomain route exchange. At first glance, it may 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 resource availability 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 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 Rosenberg, Salama, Bangalore, Shah [Page 4] Internet Draft draft-rs-trip-gw-03.txt November 2001 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: - The initial OPEN phase, exchange of keepalive timers, and the process of bringing up the state machine. - Sending of an UPDATE containing the routes and parameters of the gateways. - Sending of a periodic keepalive. Its worth noting that these functions are not substantially more complex than sending a periodic REGISTER. 4. 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 specification, so that a TRIP-GW speaker is a conformat TRIP speaker. In this section, we begin by discussing the Motivation for incorporating Carrier information in the Gateway-LS communications, both as an attribute and as an address family. Then, we proceed to define the attribute and the address family. This will be followed by a discussion of attributes that will be used in the address family that is introduced. The gateway and proxy behaviors are discussed in more details in sections 5.2 and 5.3 respectively. Rosenberg, Salama, Bangalore, Shah [Page 5] Internet Draft draft-rs-trip-gw-03.txt November 2001 4.1. Motivation for advertising Carrier information In the telephone networks of today, when a residential customer places a call, the local telephone company processes the call and gets information about the customer's long-distance carrier from the subscriber record and routes the call to that long-distance carrier's network. The Local telephone company or Local Exchange Carrier (LEC) interconnects with different long distance carriers, also called Interexchange Carriers (IXC). Each long distance carrier is assigned a unique numeric code called the Carrier Identification Code (CIC) by the North American Numbering Plan (NANP). When a call is placed, the CIC tells the local telephone company which long distance carrier to route the call over. Subscribers can also select a specific long distance carrier on a per-call basis by dialing the CIC along with the number. Example: 101XXXX, where the last 4 digits represent the CIC. Applying the same principles to Voice over IP networks, we need to device schemes to incorporate call routing based on Carrier preferences. Voice over IP gateways that connect to the PSTN can potentially interconnect with network facilities from different Carriers. Consequently, the gateways can provide routes to the same telephony destinations through different carriers. Therefore, there arises a need for the gateways to advertise the carrier information in addition to the telephony destinations, to the LS. TRIP provides a simple and straight-forward mechanism to advertise the different telephony destinations that it can terminate. We need to extend this for the gateway to be able advertise Carrier information in conjunction with the telephony destinations that it can provide service to. This information can be used by the LS to route calls based on a combination of E.164 prefix and Carrier. Hence we need to introduce a new attribute to represent the Carrier information. As Voice over IP networks get larger and deployments increase, a natural fallout will be an increase in internet telephony service offerings. Different internet telephony service providers (ITSP) and Application Service Providers (ASP) would potentially interconnect with each other and collaborate in offering different subscriber services. Gateway Wholesalers and Location Server providers could interconnect in different configurations: Confederations, Clearing Houses, etc. The Carrier Identification Code(CIC) that is used for Interexchange carriers in the PSTN, could be logically extended to ITSPs as well going into the future. We have seen the motivation for the need to advertise carrier information. Going one step further, let us explore if there is value in advertising information from the gateway at a greater granularity. In addition, we will also investigate if it makes sense in defining an address family based on carrier. In typical VoIP networks, Internet Telephony Administrative Domains (ITADs) will Rosenberg, Salama, Bangalore, Shah [Page 6] Internet Draft draft-rs-trip-gw-03.txt November 2001 deploy numerous gateways for the purposes of geographical diversity, capacity, and redundancy. When calls arrive at a POP, the decision about which gateway to use depends on many factors like availability, remaining call resources, etc. Taking a closer look at a gateway, we see that each gateway can can house several telephony trunks and, trunks with similar signaling characteristics can be logically grouped together for ease of management. Each of these trunk groups, identified by a unique label, can, typically terminate calls to several telephony destinations, the information for which is provisioned on the gateway. A gateway can potentially connect to different carrier networks, through one or more trunk groups with each carrier. Trunks within a carrier may be grouped based on geographical considerations, or maybe, on the basis of different grades of service that are offered by the carrier to its customers, etc. For example: there could be a carrier trunk group terminating calls to prefixes on the East coast where there is a different group for numbers on the west coast. There could be a carrier trunk group provisioned for least cost routing with not much emphasis on quality, while there could be a different one that provides superior Quality of Service at a higher cost. It is not uncommon in Service provider environments to have the ability to control routing of calls at the granularity of a trunk group, rather than just at the level of carrier. Hence, we see that there is a heirarchical relationship in some sense, between Carriers, Trunk Groups, and Prefixes. To express this relationship, the E.164 address family seems inadequate. We need a separate address family that can associate information like gateway resource availability and some other dynamic characteristics, as properties of a Carrier or, to a combination of Carrier and Trunk Group rather than that of a telephony prefix. This level of granularity provides better flexibility in managing gateway resources, reduces potential update traffic between the GW and the LS, and provides a framework for a scalable architecture. In the sections that follow, we proceed to define an attribute to advertise Carrier/TrunkGroup in conjunction with a E.164 destination. Following that, an address family based on the Carrier and Trunk Code combination will be defined. 4.2. CarrierCode-TrunkGroup Attribute Mandatory: False. Required Flags: optional, transitive Potential Flags: None. TRIP Type Code: TBD. The CarrierCode-TrunkGroup attribute is an optional attribute used Rosenberg, Salama, Bangalore, Shah [Page 7] Internet Draft draft-rs-trip-gw-03.txt November 2001 between a gateway and its peer LS responsible for managing that gateway. The CarrierCode-TrunkGroup attribute represents two pieces of information about the route being advertised. The CarrierCode or CIC which is the first component of the attribute, is a numeric code that can uniquely identify a carrier/service provider offering service for the destination in question. This enables the LS managing the gateways to route calls based on a combination of the E.164 prefix and the Carrier. In the US, the CIC, currently represented by a 4- digit code, identifies the inter-exchange carrier that offers POTS service. This can potentially be extended in the future to include VoIP carriers or Internet Telephony Service Providers (ITSP) and be used to control call routing to prefered provider networks . This attribute provides a way to provide information about the telephony service provider(s) that can terminate calls to the prefix(s) listed in the ReachableRoutes attribute. This component of the attribute can be used to route calls based on Carrier preferences. The second component in the attribute, the Trunk Group, represents a logical grouping of physical interfaces, for example, multiple DS0/DS1 interfaces with similar signaling characteristics, that can be provisioned as the target of an outbound route for a telephony destination(s). Multiple trunk groups may be provisioned per gateway. Also, trunk groups can potentially span multiple gateways. The actual selection of a channel or port within the trunk group at the time of placing an outbound call is left to the gateway. Example of a logical grouping could be the set of carrier trunks provisioned to terminate calls to a particular geographic region. An alphanumeric string, that is unique across the ITAD, serves as an identifier for a trunk group. Trunk groups facilitate easier management of trunks on a gateway by providing the ability to provision them as groups by referencing them with a common label. This attribute is potentially useful beyond the first-hop LS managing the gateway, in I-TRIP and E-TRIP. There may be good reasons to propogate this attribute in I-TRIP. For example, Routing based on Carrier and/or Trunk Group preferences could be provisioned on a policy server(s) that resides in the ITAD. The LS managing the gateway can interact with the policy server(s) and communicate the gateway-provided Carrier/Trunk Group information on I-TRIP. On E-TRIP, the LS may propogate only the Carrier component of the attribute but not the TrunkGroup label. Policies can be applied to peering relationships to control propogation of carrier information with specific neighboring ITADs. By propogating the Carrier component between different ITADs, a service provider can exchange information about the different carriers that it interconnects with. This allows different providers to route calls based on a combination Rosenberg, Salama, Bangalore, Shah [Page 8] Internet Draft draft-rs-trip-gw-03.txt November 2001 of E.164 prefix and the Carrier. The motivation behind combining the Carrier Identification Code and the trunk group as a unit is to provide the flexibility of reporting information like Available Capacity or the Call Success Rate (discussed in later Sections) as properties of this combined unit rather than that of a telephony prefix. The ability to provide this kind of granularity is in line with, and representative of typical gateway provisioning requirements in Service Provider environments. 4.2.1. CarrierCode-TrunkGroup Syntax The CarrierCode-TrunkGroup attribute is a variable length attribute that is composed of a sequence of CarrierCode-TrunkGroup segments. Each CarrierCode-TrunkGroup segment is represented as a length-value pair. The syntax of each such segment is shown in Figure 2. 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+--------------+----------------+ | CIC-TGrp Segment value length | CIC-TGrp Segment value (variable)... +---------------+---------------+--------------+----------------+ Figure 2: CIC Trunk-Group Segment format The format of the Segment value field is shown in Figure 3 below: 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+--------------+----------------+ | Carrier Identification Code (CIC) | +---------------+---------------+--------------+----------------+ | TrunkGroup label (variable)... +---------------+---------------+--------------+----------------+ Figure 3: Syntax of CIC-TrunkGroup Segment value field The length is a 2-octet field and represents the total size of the value field in bytes. The value field is encoded as two components. The first component is the Carrier Identification Code (CIC) and has a fixed length of 4 octets. This represents a unique code assigned to the carrier or telephony service provider offering the service. The second component of the value portion, the TrunkGroup label, is represented as an alphanumeric string and can have a maximum length of 64 octets. This component denotes a trunk group label that is provisioned on the gateway. The size of the TrunkGroup label in bytes Rosenberg, Salama, Bangalore, Shah [Page 9] Internet Draft draft-rs-trip-gw-03.txt November 2001 will be the value in the length field less 4. This TrunkGroup label provides a virtual abstraction to manage a group of physical interfaces on a gateway with similar chacteristics that are logically bundled together. 4.2.2. Route Origination and CarrierCode-TrunkGroup Routes MAY be originated containing the CarrierCode-TrunkGroup attribute. The gateway can choose to include all CarrierCode-trunk group combinations that provide service to the routes being advertised in the same UPDATE. It is possible that trunk groups are not provisioned on the gateway or that trunk groups are provisioned without any carrier associations. When trunk groups are not provisioned, only the Carrier information is propogated and the length field will be set to 4. In the other case when trunk groups are not associated with a Carrier, then the gateway uses a default carrier code in association with these trunk groups in the CarrierCode-TrunkGroup attribute. A Carrier Code value of zero is reserved and is used to denote the default carrier. 4.2.3. Route Selection and CarrierCode-TrunkGroup The CarrierCode-TrunkGroup attribute MAY be used for route selection. This will be primarily used for routing based on Carrier preferences and/or Trunk Group labels. The LS may apply local policy or communicate with a policy server to determine a prefered carrier and/or trunk group and and forward the call to the appropriate gateway to service the call. 4.2.4. Aggregation and CarrierCode-TrunkGroup An LS MAY aggregate all routes to a given prefix that carry this attribute. The aggregated attribute will be a list which is the union of the attribute values across the different routes. 4.2.5. Route Dissemination and CarrierCode-TrunkGroup The CarrierCode-TrunkGroup attribute could be used for routing based on either the Carrier, the trunk group label, or a combination of the two. There are different Service Provider requirements where these different methods could potentially be used. This attribute may be propogated by the LS within the ITAD to its I-TRIP peers. While doing so, the LS may choose to propogate only the CarrierCode component or the entire attribute to its internal peers. For E-TRIP associations, Rosenberg, Salama, Bangalore, Shah [Page 10] Internet Draft draft-rs-trip-gw-03.txt November 2001 the Trunk Group portion of the attribute MUST NOT be propogated. The Carrier code portion, however, may be propogated to its E-TRIP peers. 4.3. CarrierCode-TrunkGroup Address Family In a TRIP-GW association between the gateway and the LS responsible for managing that gateway, there are some pieces of information that are attributes of the reachable routes (prefixes) that are advertised, For example: the carriers that are provisioned on the gateway, and there are others that more naturally fit in as properties of a Carrier or trunk group rather than that of a reachable route(prefix), For example: the resource availability information on a trunk group connected to a Carrier's network. A gateway can have trunks connecting to different carriers. Each of these carriers could potentially bundle trunks associated with the carrier into different logical groups, possibly based on geographical considerations, or maybe, on the basis of different grades of service that are offered by the carrier to its customers, etc. A trunk group provisioned on a gateway can potentially terminate calls to several telephony prefixes. Hence, we can connect Carriers, Trunk Groups, and Prefixes by a heirarchical relationship. To express this relationship, the E.164 address family seems inadequate. We need a separate address family that can associate certain properties like gateway resource availability information to a Carrier or, to a combination of Carrier and Trunk Group. A possible model that could be used as a result is the following: - Using the E.164 address family, the gateway advertises telephony prefixes that it can terminate along with the CarrierCode- TrunkGroup attribute and hence establish the association between a prefix and the CarrierCode-TrunkGroup provisioned for that telephony destination. If more than one carrier offers services to the same prefix, it would appear in the UPDATE as a list of CarrierCode-TrunkGroup pairs. - Following this, the gateway reports other information like resource availability and Call Success Rate as attributes in the CarrierCode-TrunkGroup address family effectively treating them as properties of that CarrierCode-TrunkGroup combination. The primary benefits of this model are as follows: Rosenberg, Salama, Bangalore, Shah [Page 11] Internet Draft draft-rs-trip-gw-03.txt November 2001 - It allows a service provider to route calls based strictly on the CarrierCode - it facilitates more accurate reporting of attributes of a dynamic nature like resource availability by providing the ability to manage resources at the granularity of a Carrier or CarrierCode- TrunkGroup combination. - Gateways can get really large with the ability to provision hundreds or a few thousand circuits and this can increase the potential for traffic that reports dynamic resource information between the gateway and the LS. The model introduced can potentially alleviate this UPDATE traffic hence increasing efficiency and providing a scalable gateway management model. 4.3.1. Address Family Syntax Let us consider the generic TRIP route format from TRIP[3] shown below and discuss how the new address family based on the combination of Carrier Code and Trunk Group fits into this scheme. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+--------------+----------------+ | Address Family | Application Protocol | +---------------+---------------+--------------+----------------+ | Length | Address (variable) ... +---------------+---------------+--------------+----------------+ Figure 4: Generic TRIP Route Format The Address Family field will be used to represent the type of the address associated for this family, which is based on the CarrierCode-Trunk combination. The code for this family will be obtained from IANA The Application Protocol field is currently not used and will be ignored The Length field represents the total size of the Address field, which is the combination of CarrierCode and TrunkGroup label in this address family The value in the Address field represents the CarrierCode-TrunkGroup combination and serves as an identifier for the advertised route. It has two components, the Carrier Identification Code(CIC) and the Trunk Group label component, and the encoding is as follows: The first component, the Carrier Identification Code (CIC) has a Rosenberg, Salama, Bangalore, Shah [Page 12] Internet Draft draft-rs-trip-gw-03.txt November 2001 fixed length of 4 octets. This represents a unique code assigned to the carrier or telephony service provider offering the service. The second component of the address field, the TrunkGroup label, is an alphanumeric string and can have a maximum length of 64 octets. The size of the TrunkGroup label in bytes will be the value in the Length field less 4. This component represents a trunk group label that is provisioned on the gateway and provides a virtual interface to manage a group of physical interfaces(trunks) on the gateway with similar chacteristics as one unit. If a gateway supports this address family, it should include this address family as one of the Route types supported in the OPEN message capability negotiation phase. The following attributes are currently defined to be used with this address family and will be advertised as a property of the CarrierCode-TrunkGroup identifier. - AvailableCircuits Attribute - TotalCircuitCapacity Attribute - CallSuccessRate Attribute It is recommended that the above attributes be used by the gateway with the CarrierCode-TrunkGroup address family, if possible. This will potentially offer a more accurate and efficient resource reporting framework, and a scalable model for gateway management. However, when the gateway is not using Carriers or trunk groups, it may use the above attributes with the E.164 address family. If they are advertised with both the address families, the behavior is not defined. These attributes will be discussed in the sections that follow. 4.4. AvailableCircuits Attribute Mandatory: False. Required Flags: optional, non-transitive Potential Flags: None. TRIP Type Code: TBD. The available circuits 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 MUST NOT be propagated unless the LS is sure that it is relatively static. Rosenberg, Salama, Bangalore, Shah [Page 13] Internet Draft draft-rs-trip-gw-03.txt November 2001 This attribute is intended to be primarily used in association with a route in the CarrierCode-TrunkGroup address family as it provides a more accurate picture of the resource utilization on the gateway and gives better control to the LS in managing the gateway resources. The current circuit capacity identifies the number of PSTN circuits that are currently available on the given Carrier's trunk group. This effectively represents the number of calls for the set of prefixes reachable through that carrier's trunk group. The number of additional calls sent to this trunk group on the gateway can not exceed the available circuits indicated. If it does, the signaling protocol will likely generate errors, and calls will be rejected. AvailableCircuits is measured in integral number of calls. It changes very dynamically. 4.4.1. AvailableCircuits Syntax The CircuitCapacity attribute is a 4-octet unsigned numeric 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 be forwarded on this route. 4.4.2. Route Origination and AvailableCircuits This attribute is intended to be primarly used with the CarrierCode- TrunkGroup address family. Routes MAY be originated containing the AvailableCircuits 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 threshold. 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.4.3. Route Selection and AvailableCircuits The AvailableCircuits 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 (amongst 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 Rosenberg, Salama, Bangalore, Shah [Page 14] Internet Draft draft-rs-trip-gw-03.txt November 2001 ensure that re-running this selection process never results in propagation of a new route to other peers. 4.4.4. Aggregation and AvailableCircuits Not applicable 4.4.5. Route Dissemination and AvailableCircuits Routes MUST 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. 4.5. TotalCircuitCapacity Attribute Mandatory: False. Required Flags: optional, transitive Potential Flags: None. TRIP Type Code: TBD. The Total circuit capacity attribute is used to reflect the static capacity as opposed to the availability at a given point in time as provided by the AvailableCircuits attribute. Because of its relatively static nature, this attribute may be propogated beyond the LS that receives it, hence making this attribute transitive. The Total circuit capacity attribute is intended to be primarily used in association with the CarrierCode-TrunkGroup address family. This attribute represents the total number of PSTN circuits available to terminate calls on the specified Carrier and trunk group combination. This effectively represents the total number of circuits available for routes reachable via this trunk group on the associated Carrier. This is used in conjunction with the AvailableCircuits attribute in gateway selection by the LS. The total number of calls sent to the specified trunk group on the gateway cannot exceed this total circuit capacity. TotalCircuitCapacity is measured in integral number of calls. This is not expected to change frequently. This can change, for instance, when certain telephony trunks on the gateway are taken out of service for maintancence purposes. Rosenberg, Salama, Bangalore, Shah [Page 15] Internet Draft draft-rs-trip-gw-03.txt November 2001 4.5.1. TotalCircuitCapacity Syntax The Total CircuitCapacity attribute is a 4-octet unsigned numeric value. It represents the total number of circuits available for terminating calls through this trunk group. This attribute represents a potentially achievable upper bound on the number of calls which can be terminated on this trunk group in total. 4.5.2. Route Origination and TotalCircuitCapacity Routes MAY be originated containing the TotalCircuitCapacity attribute. This attribute adds value when used in combination with the AvailableCircuits attribute. 4.5.3. Route Selection and TotalCircuitCapacity The TotalCircuitCapacity attribute MAY be used for route selection. Since this attribute represents the total static capacity for a Carrier's trunk group on a gateway, it can be used to distribute calls to different gateways in rough proportion of their Total number of circuits registered with this label if TrunkGroup based routing is used or the distribution could be based on the Carrier's total capacity across the different gateways if routing is done based solely on the Carrier component information. When more than one gateway has the same circuits available at a given point of time, this attribute may be used in making a judicious choice. 4.5.4. Aggregation and TotalCircuitCapacity An LS MUST aggregate routes to the same prefix which contain a TotalCircuitCapacity attribute. This guarantees that if the decision process is rerun, the route that is disseminated to peers is unchanged. 4.5.5. Route Dissemination and TotalCircuitCapacity Since this attribute reflects the static capacity of the gateway's circuit resources, it is not expected to change frequently. Hence the LS receiving this attribute may disseminate it to other peers, both internal and external to the ITAD. Rosenberg, Salama, Bangalore, Shah [Page 16] Internet Draft draft-rs-trip-gw-03.txt November 2001 4.6. CallSuccessRate Attribute Mandatory: False. Required Flags: optional, non-transitive Potential Flags: None. TRIP Type Code: TBD. The Call Success Rate attribute is a non-transitive attribute used ONLY between a gateway and its peer LS responsible for managing that gateway. If it is received in a route, it MUST NOT be propagated. The Call Success Rate attribute represents the percentage of normally terminated calls out of the total number of attempted calls. The motivation for this attribute is drawn from Answer-seizure ratio(ASR) used in PSTN networks. The difference however is that ASR is the ratio of successfully connected calls to attempted calls. This implies that a call would be termed successful only if it transitions to the Established state before being torn down. The drawback of this scheme is that a call, for instance, that moves into the Alerting phase and does not get connected because the called party is unavailable is accounted as a failed call. The results from this can, consequently, be skewed because in some countries calls would encounter a device such as an answering machine whereas in several other countries the calls would just ring and subsequently get disconnected. The definition of a successful call in the Call Success Rate would be determined based on the Disconnect cause code at the time of the call being torn down. For instance, a call that reaches the Alerting stage but does not get connected because of called party being unavailable is accounted as a successful call. Similar is the case when the called party is busy. On the other hand, a call that gets disconnected because of a Circuit or Resource being unavailable is accounted as a failed call. The Call Success Rate is used by the LS to keep track of failures in reaching certain telephony destinations through a gateway(s) and use that information in the gateway selection process to enhance the probability of successful call termination. This attribute is intended to be primarily used in association with the CarrierCode-TrunkGroup address family and this is the recommended usage by the gateway whenever possible. The gateway may also selectively use this attribute to report repeated failure to specific telephony destinations in association with the E.164 address family. This information can be used by the LS to consider other alternative gateways to terminate calls to those destinations with better success rates. Rosenberg, Salama, Bangalore, Shah [Page 17] Internet Draft draft-rs-trip-gw-03.txt November 2001 4.6.1. CallSuccessRate Syntax The Call Success Rate attribute is represented as an unsigned 2-octet numeric value. It is computed as the ratio of normally terminated calls to the total attempted calls as a percentage that is multiplied 100 times. This encoding is used to have the ability to advertise this information as an integer. The LS receiving this information has to divide the received number by 100 to get the percentage value, represented in essence, by the attribute. For example: If the call success rate is 92.5 expressed as a percentage, then the numeric value 9250 is used for the CallSuccessRate attribute. The LS that receives this attribute, divides the value 9250 by 100 to get 92.5 4.6.2. Route Origination and CallSuccessRate Routes MAY be originated containing the CallSuccessRate attribute. This attribute is expected to get statistically significant with passage of time as more calls are attempted. Therefore, it is RECOMMENDED that the gateway make a choice based on local thresholds to determine when to report this attribute in an UPDATE. 4.6.3. Route Selection and CallSuccessRate The CallSuccessRate attribute MAY be used for route selection. This attribute represents the rate of success to telephony destination(s) or at the granularity of Carrier or CarrierCode-Trunk Group combinations or to specific telephony destinations depending on the Address family that this attribute is associated with. This information may be used to select from amongst a set of alternative routes to increase the probability of successful call termination. This may lead to call routing attempts on alternative trunk groups, carriers, or gateways by the LS. 4.6.4. Aggregation and CallSuccessRate Not applicable 4.6.5. Route Dissemination and CallSuccessRate Routes MUST NOT be disseminated with the CallSuccessRate attribute. Its potential to change dynamically does not make it suitable to disseminate in most cases. Rosenberg, Salama, Bangalore, Shah [Page 18] Internet Draft draft-rs-trip-gw-03.txt November 2001 4.7. Other attribute considerations 4.7.1. Cost/Pricing attribute In exploring attributes suitable for the GW-LS communications, Pricing is another attribute that was considered. Though at first glance, it seems like a useful piece of information to be advertised by the gateway to express the price offered by carriers to different destinations, in reality, the computation of pricing can get quite complex. For example, the price offered by a provider can vary by time of day, it can be based on an agreement between two service providers interconnecting with each other, it could be based on one price for the first 'n' minutes and a different price after that, Least Cost routing choices and Grades of service offered by a carrier can affect pricing. There could be other factors as well. Expressing this complex interplay between different factors that determine pricing is non-trivial to represent. It will be a subject of further investigation to determine whether advertising pricing associated with carriers in its simple form without any dependencies adds value to be included as an attribute in the TRIP-GW communications. 4.8. 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. 4.8.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. Rosenberg, Salama, Bangalore, Shah [Page 19] Internet Draft draft-rs-trip-gw-03.txt November 2001 4.8.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. The Gateway also sends any Carrier/Trunk Group associated with the E.164 destinations. The Gateway also sends an initial resource update for each CarrierCode-TrunkGroup combination reflecting the current circuit availability and total circuit capacity. 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 gateway reports resource availability changes, against the different CarrierCode-TrunkGroup combinations, using local thresholding schemes. 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. 4.8.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]. 4.8.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.8.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. Rosenberg, Salama, Bangalore, Shah [Page 20] Internet Draft draft-rs-trip-gw-03.txt November 2001 4.8.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.8.7. Route Selection and Aggregation TRIP's route selection and aggregation operations MUST NOT be implemented by TRIP-GW gateways. 4.9. 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 Rosenberg, Salama, Bangalore, Shah [Page 21] Internet Draft draft-rs-trip-gw-03.txt November 2001 shown in Figure 5. +-----+ | | .................................... --| GW | . +-------------.------------+ --- +-----+ . | +--------+ .+--------+ | -- . | |TRIP | .|TRIP | +-- +-----+ . |/|Instance| .|Instance|--| | | . / | | .| |--+-------- | GW | . /| | | .| |--| +-----+ . / | +--------+ .+--------+ +--- . / | LS. | --- +-----+ . / +-------------.------------+ -- | | . / . | GW | . +----------+ . +-----+ . | | . . | | . . | LS | . . | | . . | | . . +----------+ . +-----+ . . | | . . -- | GW | . +-------------.------------+ -- +-----+ . | +--------+ .+--------+ | --- . | |TRIP | .|TRIP | +- +-----+ . | |Instance| .|Instance|--| | | . | | | .| |--+---------| GW | . | | | .| |--| +-----+ . | +--------+ .+--------+ +--- . | LS. | --- +-----+ . +-------------.------------+ -- | | . ITAD . | GW | .................................... +-----+ Figure 5: LS Architecture for TRIP-GW Rosenberg, Salama, Bangalore, Shah [Page 22] Internet Draft draft-rs-trip-gw-03.txt November 2001 5. Validation against requirements In this section, we will verify if the definition of TRIP-GW to address the Gateway registration problem satisfies the requirements stated in [6] 5.1. Fast TRIP-GW facilitates propogation of routing information as soon as it changes and is out of band with call setup. Hence it does not require communication exchanges between the GW and the LS during call set up. 5.2. Failure detection There is a keep-alive mechanism provided by TRIP-GW for the session between the GW and the LS. This is through a short keepalive message, that is sent fairly frequently that period for which can be negotiated at the time of session startup. 5.3. Startup detection When a failed gateway recovers, it attempts to establish a session with the LS based on its provisioned information. In the meanwhile, if the gateway that recovers receives a connection from the LS, it is accepted. 5.4. Capacity Knowledge TRIP-GW has introduced attributes that the Gateway can use to provide resource availability information to the LS. The gateway can implement local thresholding schemes to control the frequency of reporting resource availability updates. 5.5. Secure TRIP-GW can be run over IPSec or TLS between the GW and the LS, providing authentication, integrity, and privacy. Rosenberg, Salama, Bangalore, Shah [Page 23] Internet Draft draft-rs-trip-gw-03.txt November 2001 5.6. Convey Routing Preferences TRIP-GW provides a mechanism to advertise reachability information, supplementing it with capacity information, and Call Success Rate at different levels of granularity. 5.7. Timeliness In TRIP-GW, all the routes to the different telephony destinations that the GW terminates are exchanged once when the session is established. Route updates after that need to be sent only when they change. 5.8. Extensible Attributes TRIP-GW advertises attributes describing a route some of which report dynamically changing information like resource availability and Call Success Rate. TRIP, from which TRIP-GW borrows the basic model, provides a well-defined way to add new attributes. 5.9. Efficient TRIP-GW requires to send route updates on changes only, after they are advertised the first time. A short keepalive message provides a heart-beat mechanism the frequency for which can be negotiated. The attributes provided for reporting resource availability information can be advertised at different levels of granularity hence reducing the potential update traffic between the GW and the LS. 5.10. Proxy Control The different gateways in a domain advertise routes using TRIP-GW along with the resource availability and other information. It is entirely upto the proxy to use this information and any other network policies provisioned into it to determine a suitable gateway at the time of the call Rosenberg, Salama, Bangalore, Shah [Page 24] Internet Draft draft-rs-trip-gw-03.txt November 2001 5.11. Independent Policies There is nothing in TRIP-GW that would prevent different different proxies make their own decisions as regards to the gateway to be used for a call(s). This could be controlled based on different policies provisioned on the individual proxies so as to select different gateways for the same telephony prefix, to load balance between gateways, for instance. 5.12. Discovery TRIP and TRIP-GW would extensively be used in Service Provider environments, which are managed networks, where the associations between the participating entities would be statically provisioned. At this time, we do not see a strong reason to support discovery of gateways by Location Servers. If there are applications that warrant this requirement, we can investigate to incorporate this capability within TRIP-GW. Alternatively, some other discovery protocols can be employed for this purpose, independently of TRIP-GW, and once the entities are discovered, they can establish a TRIP-GW peering session for registration of routes from the gateway to the LS. In summary, TRIP-GW provides an efficient, robust, and scalable solution for route communications between the Gateway and Location Server. Hence, it makes a good candidate for addressing the gateway registration problem. 6. IANA Considerations - The Address Family Code for the new family defined is to be assigned by IANA - The Attribute Type Codes for the new attributes defined are to be assigned by IANA 7. Changes since -02 - Removed the requirements section. - Discussed the motivation for introducing Carrier information into TRIP. - Defined a new attribute for the E.164 address family - Defined a new address family for CarrierCode-TrunkGroup combination Rosenberg, Salama, Bangalore, Shah [Page 25] Internet Draft draft-rs-trip-gw-03.txt November 2001 - Defined new attributes to advertise dynamic gateway characteristics like resource availability, and call success rate. - Added as section to validate the TRIP-GW solution against the requirements in [6]. 8. Changes since -01 - Added requirements. - Added more formal analysis of REGISTER and added analysis of SLP. - Removed circuit capacity attribute. 9. Changes since -00 - Added text to stress the value of this proposal for managing a gateway cluster - Added attributes for circuit capacity and DSP capacity - Added section on LS operation, discussing aggregation issue 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 SJC-24/3/2 170 W. Tasman Drive San Jose, CA 95134 email: hsalama@cisco.com Manjunath Bangalore Cisco Systems Mail Stop SJC-21/2/2 771 Alder Drive Milpitas, CA 95035 email: manjax@cisco.com Rosenberg, Salama, Bangalore, Shah [Page 26] Internet Draft draft-rs-trip-gw-03.txt November 2001 Dhaval N. Shah Cisco Systems Mail Stop SJC-21/2/2 771 Alder Drive Milpitas, CA 95035 email: dhaval@cisco.com Rajneesh Kumar Cisco Systems Mail Stop SJC-21/2/2 771 Alder Drive Milpitas, CA 95035 email: rajneesh@cisco.com Acknowledgments We wish to thank Randy Baird and Cullen Jennings for their insightful comments and suggestions. References [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 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. [6] J. Rosenberg, "Requirements for Gateway Registration," Internet Draft, Internet Engineering Task Force, Nov. 2001. Work in progress Rosenberg, Salama, Bangalore, Shah [Page 27] Internet Draft draft-rs-trip-gw-03.txt November 2001 Full Copyright Statement Copyright (C) The Internet Society (1999). 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. Rosenberg, Salama, Bangalore, Shah [Page 28]