Subject: [IPTEL] carrier scenario for TRIP

From: "Peterson, Jon" <[email-masked]>
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

_______________________________________________
IPTEL mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/iptel