From: "Peterson, Jon" To: "'iptel@lists.bell-labs.com'" Date: Fri, 30 Nov 2001 14:06:04 -0600 I'd like to describe a particular scenario for gateway registration, namely, a case in which it could be used by a large US-based VoIP carrier. The sort of carrier network I'm envisioning is composed 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 media gateway controllers (that manage 'dumb' gateways) and self-contained 'smart' gateways. The formal distinction here between smart and dumb gateways is that smart gateways speak the call setup protocol (like SIP) and presumably the gateway registration protocol themselves, whereas dumb gateways speak only a device control protocol (like Megaco), 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 dumb gateways can get very large (many DS3s). High-density dumb gateways tend to have support for SS7 intermachine trunks (IMTs), whereas low-density smart gateways often forgo IMT support for ISDN PRI or MF support; the signaling channels for each PRI and MF trunks physically terminate on the gateway, but SS7 requires a consolidated point at which signaling arrives for the trunks associated with multiple gateways, and hence is conducive to the MGC/dumb gateway model. Some very low-density residential gateways support POTS lines on the DS0 level, but I'm not considering them in this architecture. For reasons of economics, operation and management, among others, large carriers are predominantly SS7-based, so I'm going to assume that MGCs and large dumb 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). Trunks Gateway Registration IMT Carrier Architecture +----+ ----> +1 (H.248)| | Device +---- | GW1| ----> +1703,+1571... Control| | | | +----+ ----> +1202,+1703... [TG1] | | IMT | +----+ ----> +1 (SIP) +-----+ | | | +----------->| MGC |----+-----| GW2| ----> +1540,+1804... | +--+--+ | | | | | | +----+ ----> +1202,+1703... [TG1] | | | Call +----------+ | | IMT Setup | | | | +----+ ----> +1 (SIP) | Routing | | | | | -------->| Proxy | | +-----| GW3| ----> +1202555, +122544... | (LS) | | | | +----------+ | +----+ ----> +44 | | | SS7 | | +------------------------> TO PSTN | | | | | | +----+ PRI (B&D) | +-------------------------->| GW4| ----> +1202533 | +----+ | (SIP) | +----+ MF +-------------------------------> GW5| ----> +1703989 +----+ In the above picture, I envision that the gateway registration protocol would be spoken between all of the entities that speak SIP. By way of explanation, the diagram above shows multiple bundles of DS0 circuits (we'll refer to them as trunks) associated with each of the large dumb gateways (GW1, GW2 and GW3). One or more E.164 number ranges is associated with each of these trunks. '+1' indicates that all of the United States is reachable through this trunk (probably, this is a trunk to an interexchange carrier). The second trunk on GW1 (pointed to +1703,+1571...) contains a set of reachable area codes within a rate center, suggesting that the trunk is associated with a LEC tandem. The second trunk on GW3 (pointed to +1202555, +1202544...) is associated with a set of specific exchange codes, and is therefore probably an end office trunk pointing to a class 5 switch. The smaller gateways (GW4 and GW5) have trunks that are associated with customers, possibly PBXs. Finally, note that logical 'trunk groups' can span multiple gateways, as is the case with [TG1], the third trunks on GW1 and GW2 (each pointing to +1202,+1703...). Jonathan noted that the charter permits gateway registration for 'the exchange of dynamic information' rather than reliability or scalability. I think 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. I don't think that autodiscovery of the LS by MGCs or vice versa would really make this system substantially easier to manage or provision in any obvious way. To my mind, the fundamental question about gateway registration in this architecture is 'what are the resources whose availability is advertised by gateway registration?'. I think it needs to be some combination of the following: - 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 (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. - Availability of a number prefix/address. 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, I think, 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. In other words, the big open issue here is whether the MGC should aggregate routes on behalf of its gateways or not, and if so, how. Also note that in order to allow for more complex PSTN features, routing by location routing numbers and carrier identification codes should also be permitted, and that the availability of particular CICs or LRNs through an MGC should be advertised. - Availability of a trunk/PSTN interface on a gateway. Gateways generally have more than one physical interface capable of supporting a trunk. If a trunk has been established on a physical interface, it will have one of many dynamic states (more precisely, the states on a trunk are an aggregate of the states of its constituent circuts if no trunk-level events are taking place); 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 dependent on the availability of trunks (i.e. if the third trunk on GW3 goes off-line, then the +44 country code will no longer be available in the MGC). For the purposes of scalability, a more useful construct is a logical set of circuits known as a trunk group which allows multiple trunks (potentially on different physical interfaces) to be grouped under the same set of attributes and policies. A trunk group can also span multiple gateways (as [TG1] spans the third circuits of GW1 and GW2) in order to provide greater reliability. Consider, for example, that if GW2 were to go offline, the trunk group consisting of the third trunks 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. I suspect 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. Many static attributes that proxy servers might use for routing decisions have dependencies on trunk groups. Some that come to mind: - A trunk group has directionality. It may be one-way inbound, one-way outbound, or two-way. - The protocol used to establish calls on the trunk. 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 PRI trunk (possibly resulting in an error condition). Even addresses can usefully be construed as attributes of trunk group: - There is one and only one carrier that is responsible for the switch on the other side of the trunk. One or more carrier identification codes can be associated with a carrier. Of course, other carriers are also probably reachable through the remote carrier's network. - 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 (USA) PSTN is associated with one LRN. Note that neither of these forms of address are international in scope, and therefore the set of all the carrier identification codes in the world is not reachable by an ISUP signal sent through an American trunk. Interestingly, I think most of the dynamic information that would be exchanged by gateway registration messages are attributes of trunk groups. For instance: - 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 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 exist trunks. The addition of circuits to an existing trunk group is preferable to creating new trunk groups when the attributes of the trunk remain the same. - 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 circuits 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 circuit changes is probably not feasible, so perhaps some fuzzier states for the entire trunk group (e.g. 'almost full') would be needed. - Trunk groups 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. - 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. That's probably a good start as far as describing the architecture goes. Jon Peterson NeuStar, Inc