Network Working Group J. Peterson Internet-Draft NeuStar Expires: August 23, 2002 February 22, 2002 An Architecture for Gateway Registration based on Trunk Groups draft-peterson-iptel-gwreg-arch-00 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. This Internet-Draft will expire on August 23, 2002. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This document presents a framework in which gateways (points of interconnection between the Public Switched Telephone Network and Internet-based telephone systems) register themselves with a location service in order to communicate their own availability and the availability of the resources and services they provide. Unlike previous approaches to this problem, this document considers trunk groups as a resource which gateways register. Peterson Expires August 23, 2002 [Page 1] Internet-Draft Gateway Registration Architecture February 2002 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Defining Trunk Groups . . . . . . . . . . . . . . . . . . . . 6 3. Gateway Deployment Architecture . . . . . . . . . . . . . . . 7 4. Trunk Group Attributes . . . . . . . . . . . . . . . . . . . . 11 5. Reachability and Preference . . . . . . . . . . . . . . . . . 14 6. Building a Route List . . . . . . . . . . . . . . . . . . . . 17 7. An example of Gateway Registration . . . . . . . . . . . . . . 19 8. Gateway Registration & Route Selection in TRIP . . . . . . . . 20 9. Security Considerations . . . . . . . . . . . . . . . . . . . 21 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 22 References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 24 Peterson Expires August 23, 2002 [Page 2] Internet-Draft Gateway Registration Architecture February 2002 1. Introduction Gateway registration is a process by which a gateway can in real-time inform a server of its availability and the state of any resources it controls. This information is then used by a server to make optimal routing decisions in a network. The scope of this document is restricted to gateways that interwork between the Public Switched Telephone Network (PSTN) and Internet-based telephone services that use protocols such as SIP [1] - in other words, gateways that handle IP telephone calls. This document describes a particular scenario for gateway registration, namely, a case in which it could be used by a sizeable Voice over IP (VoIP) carrier. It outlines an architecture, a framework for gateway registration, and some conclusions on protocol selection that reflect the preceding considerations. In particular, this document focuses on the expression of the state and capabilities of trunk groups associated with gateways. It is the contention of this document that focusing on trunk groups provides us with new leverage to attack the whole gateway registration problem. The sort of VoIP carrier network discussed in this draft is comprised of entities responsible for routing call setup requests (like SIP proxy servers) and entities that generate and receive call setup requests (in the scope of this problem, PSTN gateways). However, there are many different types of PSTN gateways; the broad delineation is between distributed media gateway controllers (MGCs, which manage 'slave' gateways) and self-contained 'smart' gateways. The formal distinction here between smart and slave gateways is that smart gateways speak a call setup protocol (like SIP) and presumably the gateway registration protocol themselves, whereas slave gateways speak only a device control protocol (like Megaco [3]), and rely on their MGC to handle call setup and gateway registration protocols. In the field, smart gateways commonly have low capacities (on the order of a couple of DS1s) whereas the scale of slave gateways can get very large (many DS3s). High-density slave gateways tend to have support for SS7 intermachine trunks (IMTs), whereas low-density smart gateways often forgo IMT support for ISDN PRI or multifrequency (MF) trunk support; the signaling channels for all PRI and MF trunks physically terminate on the gateway themselves, but SS7 requires a consolidated point at which signaling arrives for the trunks associated with multiple gateways, and hence is conducive to the MGC/slave gateway model. Some very low-density residential gateways support POTS lines on the DS0 level, but these are considered out of the scope of this architecture. For reasons of economics, operation and management, among others, Peterson Expires August 23, 2002 [Page 3] Internet-Draft Gateway Registration Architecture February 2002 large carriers are predominantly SS7-based, so this document assumes that MGCs and large slave gateways constitute the majority of the network in this scenario. Smaller smart gateways may also be sparing deployed in the network to face specific resources (mostly PBXs). A great deal of the problem of gateway registrations concerns the 'reachability' of the resources managed by gateways; a registration expresses specifically that a given set of resources is reachable. In the past, and notably in TRIP [5]), protocols have expressed reachability information for a range of E.164 [6] numbers. Traditional PSTN switches do not support dynamic gateway registration, and therefore the PSTN has no concept of reachability nor a need for a protocol that propagates reachability information. For those unfamiliar with this term, we define whether a resource is reachable through a gateway or not as follows: if a call sent to the gateway addressed to the resource in question will be routed properly to the final destination in the PSTN, then the resource is reachable through the gateway. This document argues for a shift in the 'reachability' model that focuses on the reachability of resources through particular trunk groups located on gateways, rather than just considering the problem from the vantage of the gateways themselves. The IPTEL working group is chartered to provide a gateway registration mechanism for 'the exchange of dynamic information'. It is important to note that the reason why the exchange of dynamic information is interesting to a carrier network is that it facilitates provisioning and network management. Autodiscovery of a location server by gateways or vice versa wouldn't seem to really make a VoIP carrier's network substantially easier to manage or provision in any obvious way; although it has been discussed in the context of gateway registration, this document assumes that autodiscovery is unnecessary and that either the gateway or the location server is configured with the location of the other. Also note that the registrations performed by gateways are unlike those used in SIP, for example, which has its own registration process by which a user agent can register the identity of its user with a registrar, than in turn provisions an association in a location service that will be used to route requests for the user to the correct user agent. Neither gateways nor trunk groups have identities and contact addresses that are comparable to those used in SIP registrations. Finally, this document discusses practices that may be specific to North American telephone networks, such as describing 24-channel DS1 trunks. The authors believe, however, that these principles probably roughly apply to gateways deployed in any segment of the PSTN/GSTN. The work in this document provides additional architectures and considerations that should be understood in the framework for Peterson Expires August 23, 2002 [Page 4] Internet-Draft Gateway Registration Architecture February 2002 Internet telephony routing given in RFC2871 [4]; many terms (including 'location server') defined in that document are used here. Peterson Expires August 23, 2002 [Page 5] Internet-Draft Gateway Registration Architecture February 2002 2. Defining Trunk Groups Before we take the discussion of trunks any further, we must define both a trunk and a trunk group and explain the difference between the two. The following definitions are taken from [7]. Trunk: In a network, a communication path connecting two switching systems used in the establishment of an end-to-end connection. In selected applications, it may have both its terminations in the same switching system. Trunk Group: A set of trunks, traffic engineered as a unit, for the establishment of connections within or between switching systems in which all of the paths are interchangeable except where subgrouped. Since the introduction of ubiquitous digital trunking, which resulted in the allocation of DS0s between end offices in minimum groups of 24 (in North America), it has become common to refer to bundles of DS0s as a trunk. Strictly speaking, however, a trunk is a single DS0 between two PSTN end offices - however, for the purposes of this document, the PSTN interface of a gateway acts effectively as an end office (i.e. if the gateway interfaces with SS7, it has its own SS7 point code, and so on). A trunk group, then, is a bundle of DS0s (that need not be numerically contiguous in an SS7 Trunk Circuit Identification Code (TCIC) numbering scheme) which are grouped under a common administrative policy for routing. This definition does not include what the resources are that are available through a trunk group; nor for the purposes of gateway registration does the definition of a gateway include the E.164 number ranges that can be reached through it (following the TRIP model). This document contends that considering the resources that are available through a trunk group may offer us slightly greater leverage on the problems we are trying to solve than considering the resources that are available through a gateway - partially because there are many varieties of gateways that would require different handling in a location server, while trunk groups can be treated relatively uniformly. Peterson Expires August 23, 2002 [Page 6] Internet-Draft Gateway Registration Architecture February 2002 3. Gateway Deployment Architecture Trunks Gateway Registration IMT Carrier Architecture +----+ ----> +1 (H.248)| | Device +---- | GW1| ----> +1703,+1571... Control| | | | +----+ -TG1> +1202,+1703... | | IMT | +----+ ----> +1 (SIP) +-----+ | | | +----------->| MGC |----+-----| GW2| ----> +1540,+1804... | +--+--+ | | | | | | +----+ -TG1> +1202,+1703... | | | Call +----------+ | | IMT Setup | | | | +----+ ----> +1 (SIP) | Routing | | | | | -------->| Proxy | | +-----| GW3| ----> +1202555, | (LS) | | | | +122544... +----------+ | +----+ -TG2> +44 | | | SS7 | | +------------------------> TO PSTN | | | | | | +----+ PRI (B&D) | +-------------------------->| GW4| -TG3> +1202533 | +----+ | (SIP) | +----+ MF +-------------------------------> GW5| ----> +1703989 +----+ In the illustration above, all of the entities that speak SIP are candidates to use the gateway registration mechanism postulated in this document. The SIP proxy server (designated the 'Routing Proxy') also acts as a location server ('LS'), making routing decisions among the appropriate gateways for call setup requests it receives. By way of explanation, the diagram above shows multiple physical interfaces associated with each of the large slave gateways (GW1, GW2 and GW3), each of which we'll say for simplicity's sake consists of a Peterson Expires August 23, 2002 [Page 7] Internet-Draft Gateway Registration Architecture February 2002 DS1 worth of trunks (in reality they would command many times that). One or more E.164 number ranges are associated with each of these DS1s. '+1' indicates that all telephone numbers in the United States are reachable through this DS1 (this DS1 is characteristic of an interexchange (IXC) carrier). The second DS1 on GW1 (pointed to +1703,+1571...) contains a set of reachable area codes within the same rate center, suggesting that the DS1 is wired to a local exchange carrier (LEC) tandem. The second DS1 on GW3 (pointed to +1202555, +1202544...) is associated with a set of specific exchange codes, and is therefore probably an end office DS1 pointing to a class 5 switch. The smaller gateways (GW4 and GW5) have trunks that are associated with smaller range ranges that have most likely been assigned to enterprise customers, possibly PBXs. Finally, note that trunk groups can span multiple slave gateways under the control of an MGC, as is the case with [TG1], the third trunks on GW1 and GW2 (each pointing to +1202,+1703...). In this architecture, the fundamental question about gateway registration is 'what are the resources whose availability is advertised by gateway registration?'. Some possible answers include: Availability of a gateway itself: In the case in which an MGC performs gateway registration, it could notify the LS of the availability of any individual gateway (for example GW1 above). If a standalone gateway (like GW4) does not go offline gracefully, then of course no gateway de-registration message could be sent, but the LS would presumably have some other mechanism (such as the absence of keepalive messages) to determine that the gateway is unavailable. Since an MGC is not coupled to physical trunk resources, it can take advantage of reliability mechanisms that a standalone gateway cannot, and therefore it is well positioned to broker availability information for gateways. Either way, clearly the availability of gateway themselves can be made known to the LS. Limiting the problem space of gateway registration just to gateway availability would be appropriate if any gateway attributes needed to make routing decisions were pre-configured in the location server and were not subject to change over time. Availability of an E.164 number prefix: This is the traditional TRIP model, in which an E.164 range (e.g. '+1303') is propagated from the gateway to the LS. This model works best in the case of standalone smart gateways (like GW4). In the MGC case, it is harder to see what prefixes should be propagated by the MGC to the LS - merely propagating that '+1' is available through the MGC doesn't take into account the different policies that are potentially available on different trunks, which may have all sorts of implications about the desirability of a route. For example, on GW1, the second interface might be a more desirable Peterson Expires August 23, 2002 [Page 8] Internet-Draft Gateway Registration Architecture February 2002 route for a call than the first, so if the second interface goes down the desirability of GW1 as a route for this particular call should also be lessened - but if the routes associated with the interfaces are aggregated solely on the basis of E.164 number ranges, the loss of the second interface would not even be communicated to the LS. The question this begs is whether the MGC should aggregate routes on behalf of its gateways, and if so, how. Availability of other sorts of PSTN addresses: Also note that in order to allow for more complex PSTN features, routing by non- E.164 addresses such as location routing numbers (LRNs) and carrier identification codes (CICs, see Section 5) should also be permitted, and that the availability of particular CICs or LRNs through an MGC should be advertised. One complication that may arise from this is priority of various addresses, especially if a gateway registration mechanism that requires an innate priority for these addressing schemes is considered. Availability of the PSTN interfaces: Gateways generally have more than one physical interface capable of supporting trunks (as is the case on GW1, GW2 and GW3, each of which sports three interfaces). Once trunks have been established on a physical interface, they will have one of many dynamic states; trunks can be busy, administratively blocked, idle, and so forth. Trunks also have many different static attributes (some of which are detailed below). Clearly, the availability of particular number ranges in a gateway is predicated on the availability of these trunks, and the availability of trunks is predicated on the underlying physical interface (i.e. if the third physical interface on GW3 goes off-line, and all of its trunks are lost, then the +44 country code will no longer be available in the MGC). Availability of trunk groups: For the purposes of scalability and reliability, a more useful construct is a logical set of trunks known as a trunk group, which allows multiple trunks, potentially on different physical interfaces, to be grouped under the same set of administrative policies. A trunk group can also span multiple gateways (as [TG1] spans the third circuits of GW1 and GW2) in order to provide even greater reliability and independence of the underlying physical network. Consider, for example, that if GW2 were to go offline, the trunk group consisting of the third physical interfaces of GW1 and GW2 would still be available (with diminished capacity). Note that these properties of trunk groups also generally apply to ISDN NFAS trunks. In summary, the points above argue that the trunk group is the foundational element that determines reachability - access to PSTN address ranges is granted to gateways by the common administrative Peterson Expires August 23, 2002 [Page 9] Internet-Draft Gateway Registration Architecture February 2002 policies of trunk groups, but the availability of trunk groups themselves is not necessarily predicated on the availability of any single gateway. This document contends that bundling number prefix/address-based routed into trunk groups is the right way for an MGC to aggregate routes for delivery to an LS. Also, by treating trunk groups as routes, the LS can also handle gateway registrations from MGCs and smart gateways uniformly. Peterson Expires August 23, 2002 [Page 10] Internet-Draft Gateway Registration Architecture February 2002 4. Trunk Group Attributes By shifting the conceptual model to the availability of trunk groups, rather than gateways, we are able to ascribe attributes to trunk groups that might not have made sense for the gateways themselves, which will (as we show below) provide a more versatile framework for routing calls in the location server. Overall, we group these attributes into static and dynamic qualities. This is a representative rather than exhaustive list of possible attributes. Static attributes are qualities that do not change in real-time, but are associated with a trunk group for its lifetime. Whether or not these static qualities are propagated in the gateway registration protocol (which is scoped to consider dynamic attributes), they might be useful factors in making routing decisions. o A trunk group has directionality. It may be one-way inbound, one- way outbound, or two-way. If it is inbound, then obviously it cannot accept any outbound calls routed from a location server. A location server can also have a much better idea of the exact capacity at any given moment of a one-way outbound trunk group than of a two-way trunk group (since it may be in a position to know exactly how many calls have been sent to the one-way outbound trunks). o A single PSTN protocol (Q.931, ISUP, MF, etc) is used to establish calls on a trunk group. In some instances, VoIP messages might rely on signaling mechanisms that are specific to a particular PSTN termination protocol. A good example would be if number portability information is present in the VoIP signaling data - this information will be lost if the call terminates on a Q.931 PRI trunk (possibly resulting in an error condition). Location servers may therefore want to take this protocol information into account. Various PSTN addresses (which remain relatively static on a per-trunk group basis) can also usefully be construed as attributes of trunk groups: o E.164 number ranges, if applicable - since every E.164 number is reachable through almost every trunk group, only administrative issues (such as cost and so forth) would make certain ranges preferable to others. o Carrier identification codes. There is one and only one carrier that is responsible for the switch on the other side of a trunk group. Note however that one or more carrier identification codes (CICs) can be associated with a given carrier. And of course, other carriers are also probably in turn reachable through the Peterson Expires August 23, 2002 [Page 11] Internet-Draft Gateway Registration Architecture February 2002 remote carrier's network. This matter is explored in further detail in Section 5. o Location routing numbers. Trunks to end offices may be associated with a location routing number (LRN) used to route calls for local number portability. Each NP-compliant end office switch in the (North American) PSTN is associated with one LRN. Note that neither of these latter two forms of address are international in scope, i.e. absolutely all the carrier identification codes in the world are not typically reachable by a call setup request sent through a North American trunk. In the traditional (TRIP-like) understanding of gateway registration, it is this static set of PSTN addresses that is registered (with capacity and so forth potentially as an attribute). However, most of the dynamic information that would be exchanged by gateway registration messages are attributes of trunk groups themselves. Given the scope of the gateway registration problem this disparity is interesting. Consider for instance: o The total capacity of a trunk might seem like a static attribute, but over the long term it is actually dynamic. Existing trunk groups are frequently augmented. The total capacity of a trunk group can change over time due to capacity constraints. Large carriers are constantly in the process of augmenting existing trunk groups. The addition of circuits to an existing trunk group is preferable to creating new trunk groups when the policy of the trunks will remain the same. o Trunk groups fill up with calls. If a trunk group is one-way outbound, then in some architectures an LS could track the congestion of particular trunk groups itself without any gateway registration attributes. However, if the trunk group is two-way, it is much more difficult for an LS to keep an accurate count of idle trunks in a trunk group without reporting from gateways. One of the difficult problems with propagating dynamic capacity is the thresholds for reporting - sending a gateway registration message each time the state of a single trunk changes is probably not feasible, so perhaps some fuzzier states for the entire trunk group (e.g. 'almost full') would be needed. o Trunk groups have maintenance conditions - most notably blocking and unblocking. Sending a block for a trunk group prevents new calls from being received on the group. Blocking can be used when a hardware failure occurs that takes a trunk out of service, or as a pre-emptive measure (quiescence) to empty a trunk gradually. Peterson Expires August 23, 2002 [Page 12] Internet-Draft Gateway Registration Architecture February 2002 o Finally, trunk groups themselves are created and destroyed. Switches associated with major carriers are in an almost constant state of creating trunk groups as connections to new switches are required or connections to existing switches require augmentation with distinct policies. Peterson Expires August 23, 2002 [Page 13] Internet-Draft Gateway Registration Architecture February 2002 5. Reachability and Preference For each of the PSTN address-related attributes listed in Section 4, there is a concept that a particular trunk group is a favorable or unfavorable route for a particular call. For example, on GW1 in Figure 1, we might like to say that for calls within the 703 NPA, we would like to say that the trunk group to which the second PSTN interface belongs is a more favorable route that the first PSTN interface. This suggests that there is a concept of preference over and above reachability associated with PSTN address attributes. In this section the carrier identification code (CIC) is used as an example to demonstrate various forms of reachability, although similar arguments could be raised regarding the other forms of PSTN addressing as well. There are a number of ways that a user can directly or indirectly select a carrier for a particular call, administratively or on a per- call basis. It is certainly true that a CIC does not necessarily correspond to some physical network - that is, the concept of a 'carrier' chosen by a user is largely a matter of who issues your bill, not what physical infrastructure your call crosses. For example, there are resellers of long-distance service whose CICs are really just aliases for the CIC of a major carrier. Large carriers may own several CICs they use to target their services. There is no one-to-one mapping from CICs to physical infrastructure. However, this doesn't mean that a decision isn't made, in some places in the telephone network, about how a call is routed based on the CIC. In SS7, when a CIC has been selected for a call, it is carried within the TNS or (ANSIfied) CIC parameter of the Initial Address Message. The presence of this parameter modifies how a call is routed through the telephone network, especially at tandems. As is noted in the introduction, we say that a given CIC is reachable through a trunk group when an SS7 IAM message carrying this CIC is sent over the trunk group, this call will (eventually) be routed to the administrative domain responsible for the CIC (and presumably get delivered appropriately). One might contend, as an opposing position, that only the carrier that owns the switch on the far side of the trunk should be considered to be reachable through a trunk - but, in a pinch (due to congestion, say) most operators would be content to send calls through less preferred routes, even if doing so introduced a middle-man network, complicating routing and potentially settlement. This suggests that there is a balance between reachability and some form of preference, one that is possibly based on where a trunk group terminates. Let's say for the time being that one or more CICs may Peterson Expires August 23, 2002 [Page 14] Internet-Draft Gateway Registration Architecture February 2002 be 'directly' reachable over a particular trunk group (largely because of who happens to own the equipment on the other side), but in addition all CICs are usually 'indirectly' reachable through such trunk groups. The same is true of E.164 numbers; certain ranges may be preferred (due to settlement concerns, perhaps) for particular trunk groups, but all number ranges are usually available. This preference follows from the proximity of the PSTN resource on the other side of the trunk group to the network or resource that is identified by the PSTN address. Basing routing logic on the assumption that resources might be directly or indirectly reachable over a particular trunk group has no corollary in traditional telephone networks. However, in the PSTN there is a difference between a trunk group being directly connected to a given carrier and a trunk group being identified as a route to multiple carriers (for example, a trunk group pointing to an access tandem). 'Directly' and 'indirectly' reachable are attempts to capture these sorts of characteristics of a trunk group in the scope of 'reachability', although this does not necessarily to speak to how characteristics might be processed during a route decision in a proxy (which is discussed in Section 6). Propagating routes to proxies and making routing decisions within proxies are related but distinct problems - for now we are focused on the former, not the latter. Indeed, the very terms 'directly' and 'indirectly' reachable have been brought up only to give a sense of the sort of data that needs to be propagated in gateway registration. In fact, finer degrees of granularity than these might be necessarily to adequately capture the necessary routing logic. When the owner of the gateway turns up a trunk group, the gateway would have to be provisioned with this a certain set of information about the new trunk group so it can describe itself properly to a location server. But given these two categories, how would the owners of the GWs decide on the 'directly' and 'indirectly' reachable settings for their TGs with respect to particular CICs? Maybe this information is learned directly from the carrier whose switch terminates the other end of the trunk group - in any event it is learned administratively, not through any PSTN protocol activity. Ultimately, the gateway operator must ascertain if the carrier on the other side of trunk group (which to TG1 is 'directly' reachable) is addressed by one or more specific CICs. The gateway operator could also discover whether or not any or all CICs are 'indirectly' reachable through this carrier in the same manner. Finally, as an aside it's important to note that CICs are national in scope, and that therefore trunk groups are most likely only routes to the set of CICs within a particular nationality (this applies to Peterson Expires August 23, 2002 [Page 15] Internet-Draft Gateway Registration Architecture February 2002 location routing numbers as well). There have been suggestions in the past that identifiers for CICs in the gateway registration mechanism should be concatenated with some sort of country code to provide a scope of a CIC, which leads to an architecture in which all carriers for a given nationality could be 'available' through a trunk group. Peterson Expires August 23, 2002 [Page 16] Internet-Draft Gateway Registration Architecture February 2002 6. Building a Route List Once we have determined what information a gateway should send to a location server, we must then grow mildly curious about how a location server decides on a route, or more properly an ordered set of available routes known as a route list, for a particular call (when a proxy server needs to make a routing decision). To what extent does the forwarding logic in location servers influence the requirements for gateway registration? The information that is propagated by the gateway registration protocol is a set of potential routes, just a set of trunk groups and their attributes. These potential routes are eligible to become actual routes for a specific call when a proxy server makes a routing decision. However, this doesn't mean that gateway registration should dictate the route selection algorithm itself - for example, by somehow providing an ordered list of trunk groups to the location server that will apply to some set of calls. Multiple gateways will be sending routes for various trunk groups to the location server in gateway registration messages. Presumably, these gateways can be unaware of one another, and if any one gateway dictated how the location service selected routes, it would probably be to the detriment of other gateways as well as the overall capability of the network. In a better model, the location server receives routes from these various gateways, and for a particular call the location server should be allowed to add trunk groups located on various gateways to the route list - therefore no gateway should be dictating route lists to the location server. So, we can declare location server policy decisions outside the scope of gateway registration signaling - rather, gateway registration influences the construction of a route list. Trunk groups have state that changes dynamically, and these states in turn determine the availability of PSTN addresses. One or more trunk groups could be eligible to receive a particular call, meaning that the requisite PSTN addresses are reachable through the trunk group, the trunk group has available capacity, and so on. On the basis of this data location server that is asked to provide a route for a particular call will construct an ordered 'route list,' as it were, of alternative trunk groups that meet the routing criteria of the call. Note that the construction of a route list should not assumes that it is necessarily desirable for the PSTN path to be minimized at the expense of a more direct IP path, or even that routing calls is necessarily a least-cost problem. This is ultimately a routing policy question, and really either head-end hop-off or tail-end hop- Peterson Expires August 23, 2002 [Page 17] Internet-Draft Gateway Registration Architecture February 2002 off or any other routing scheme should be enabled by a gateway registration mechanism. The construction of a route list will be performed by the location server that has been provisioned with data by the gateway registration process. The location server then uses a route selection algorithm on this data that introduces necessarily local policy constraints and preferences to optimize amongst the potential routes. Thanks to all of the timely information the location server has learned from gateway registration, it will construct a list that will be more likely to result in the prompt termination of the call than it would have if it had no gateway registration data. It will make this decision by inspecting the signaling for call setup (including the dialed number, a CIC if available, and so forth), and comparing these criteria with the attributes it has learned from the gateway registration process, which tell the location server what possible trunk groups for termination are available, including whether the addressed resources are 'directly' or 'indirectly' available through the trunk groups. This will presumably be taken into account by the routing logic in a proxy server in order to construct a route list for a particular call. So, with a few simple principles (prefer directly available routes to indirectly available routes, etc) for a route selection algorithm, the PS can make a good route list based on the data it receives. This is the whole purpose of gateway registration. However, it is important that gateway registration not limit the capabilities of the route selection algorithm. The data that is provided by gateway registration can be communicated without restricting the sorts of choices that the location server can make. Peterson Expires August 23, 2002 [Page 18] Internet-Draft Gateway Registration Architecture February 2002 7. An example of Gateway Registration Consider a simple example. The location service in Figure 1 receives gateway registrations for three trunk groups, TG1, TG2 and TG3. For TG1, CIC 0288 is 'directly' reachable and all other CICs are 'indirectly' reachable. For TG2, only CIC 5062 is 'directly' reachable. For TG3, all CICs are 'indirectly' reachable. These are the potential routes based on the CIC attribute. Now imagine that a call comes to the PS, and the PS is required to make a routing decision - to construct the actual route list. We'll say that the call is for CIC 0288. The PS constructs, on the basis of the gateway registrations it has received, an ordered route list of: TG1, TG3. Why? TG1 is first because it is the only available trunk group for which the CIC associated with the call is 'directly' reachable. TG2 is ineligible because 0288 is not available through TG2. TG3 is 'indirectly' connected to 0288 (as it is for all CICs), so it ends up on the route list as a less preferred option than TG1. With the route list provided by the location server in mind, the proxy server forwards the call to the MGC responsible for TG1, which will internally choose between GW1 and GW3. If the call doesn't succeed at the MGC for some avoidable reason, the PS will subsequently forward the call to GW4, which is the less preferred route. Finally, note that when a call arrives at the proxy server, it has many routable attributes other than a CIC. Calls also, for example, have a dialed number. The route selection algorithm in the location server, however, decided that it should look at the CIC before the dialed number, and use the CIC to figure out how to route the call, and that it should prefer 'directly' reachable routes to 'indirectly' reachable routes, and so on. This route selection algorithm should if possible be totally independent of the gateway registration protocol - that is to say, the gateway registration protocol should just provide the data and let the location server worry about how that data will be used to route calls. Peterson Expires August 23, 2002 [Page 19] Internet-Draft Gateway Registration Architecture February 2002 8. Gateway Registration & Route Selection in TRIP The preceding sections show that there is a relationship between the attributes propagated by the gateway registration protocol and the routing decisions (for call setup signaling) made by the proxies that receive these registrations. TRIP in particular strongly couples the two - in fact, TRIP provides for three major functions: 1. The protocol itself for propagating routes from one point to the next 2. A way of making forwarding decisions for calls based on discriminators propagated in the protocol (TRIBs) 3. A way of deciding what routes you will share with peers based on routes you have received By ruling interdomain route propagation outside of the scope of the gateway registration problem, the IPTEL WG has essentially made the third item above out of scope. None of the existing gateway registration requirements really address the second problem - and thus it isn't totally clear whether or not it is in scope (although we discuss is above in Section 6. It is furthermore is not clear if these functions in TRIP are separable. Any gateway registration protocol proposal that seems to limit the sort of forwarding decisions that might be made within the proxy server should be met with caution. Note that TRIP seems to build in some limitations along these lines (like hierarchical discriminators, which are concatenated from most specific to least specific). Peterson Expires August 23, 2002 [Page 20] Internet-Draft Gateway Registration Architecture February 2002 9. Security Considerations Clearly, any proposed protocol for gateway registration would require security. While this document has not focused on concrete protocol requirements as such, this framework entails a general need in the gateway registration protocol for mutual authentication between gateways and location servers, as well as assurance of message integrity and prevention of replay attacks. Confidentiality is also probably desirable but not an immediate need. Since the focus of this protocol would be an intradomain environment, in which all of the elements speaking the protocol are owned and operated by the same administrative domain, it is likely the security requirements are comparable to those of Megaco [3]. Peterson Expires August 23, 2002 [Page 21] Internet-Draft Gateway Registration Architecture February 2002 References [1] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999. [2] Greene, N., Ramalho, M. and B. Rosen, "Media Gateway Control Protocol Architecture and Requirements", RFC 2805, April 2000. [3] Cuervo, F., Greene, N., Rayhan, A., Huitema, C., Rosen, B. and J. Segers, "Megaco Protocol Version 1.0", RFC 3015, November 2000. [4] Schulzrinne, H. and J. Rosenberg, "A Framework for Telephony Routing over IP", RFC 2805, June 2000. [5] Salama, H., Rosenberg, J. and M. Squire, "A Framework for Telephony Routing over IP", RFC 3219, January 2002. [6] International Telecommunications Union, "Recommendation E.164: The international public telecommunication numbering plan", May 1997, . [7] Telcordia, "SR2275: Bellcore Notes on the Network", December 1997, . Author's Address Jon Peterson NeuStar, Inc. 1800 Sutter St Suite 570 Concord, CA 94520 US Phone: +1 925/363-8720 EMail: jon.peterson@neustar.biz URI: http://www.neustar.biz/ Peterson Expires August 23, 2002 [Page 22] Internet-Draft Gateway Registration Architecture February 2002 Appendix A. Acknowledgments This gateway registration architecture was discussed and evaluated by the IPTEL working group, especially Mike Pierce, Matt Hammer, and Tom Taylor. Peterson Expires August 23, 2002 [Page 23] Internet-Draft Gateway Registration Architecture February 2002 Full Copyright Statement Copyright (C) The Internet Society (2002). 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Peterson Expires August 23, 2002 [Page 24]