Subject: Re: [IPTEL] carrier scenario for TRIP

From: "Hussein F. Salama" <[email-masked]>
Date: Sat, 01 Dec 2001 12:37:58 -0800

"Peterson, Jon" wrote:

>
>
> 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.

Does the LS know of the eistance of the MGs at all? Or would the MGs, (GW1, 2,
and 3) be completely shielded from the LS by the MGC?

Thanks.

Hussein

--
Hussein F. Salama
Cisco Systems
Mail Stop SJC-24/3, 170 W. Tasman Drive, San Jose, CA 95134
Voice: +1 (408) 527-7147, Fax: +1 (408) 527-7147

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

---

From: Manjunath Bangalore <[email-masked]>
Date: Thu, 06 Dec 2001 16:36:10 -0800

Hi Jon,

I am thinking of usage scenarios relavant to the gateway registration problem
similar to what you have described. I am not sure if you have had a chance
to take a look at the latest TRIP-GW draft. This draft introduces a concept
of Carriers and trunk groups which lends itself well into the model that you
bring out. It provides a model by which calls can be routed based on Carrier
preferences in conjunction with the telephony destination or optionally be even

routed at the granularity of a trunk group in an ITAD. The same holds to
managing the capacity on the gateways, as regards, its trunk resources.
This can be reported as the total number of trunks available for a carrier
or as being associated with a Carrier's trunk group.

 I would like to extend the scenario described by Jon to represent
the model of an VoIP based carrier or ITSP for  Wholesale VoIP provider
environments.

The network would be comprised of different entities - Signaling servers like
SIP Proxy Servers, Gateways that terminate calls to the PSTN, Location Servers,

etc. The PSTN gateways are provisioned with trunk groups that connect to
different interexchange carriers.  A gateway can have one or more trunk groups
connecting to an interexchange carrier. Trunk groups comprise a set of DS0s
that
have the same signaling charactersitics and are managed as one unit. Trunks
connected to a carrier's network can be grouped based on different factors. It
could be on a geographical basis, say for example, calls terminating to regions
on
the West coast, based on grades of service offered, based on pricing
(Example: Least cost trunks), etc. The gateways in a provider's network
potentially connect to different interexchange carriers, say Carrier A,
Carrier B, Carrier X, etc.  This interconnect could also be with other ITSPs.
and this, I expect will potentially increase in the future as more VoIP
providers
come into the fray.  With this background, I would like to proceed to
discussing some deployment scenarios for "Voice wholesalers".

 Voice wholesalers typically route traffic between multiple ingress carriers or

ASPs(Application Service Provider) and multiple egress carriers. A call
arriving
at the gateway from an ingress carrier will be routed to the appropriate egress

carrier. A typical deployment of this type is shown in the enclosure Slide #1

In some cases, the wholesale provider will act as a pure TDM transit network.
Customers purchase minutes from the provider and present traffic on a set of
ingress trunks, each trunk assigned to a particular customer. The provider
also purchases minutes or executes some form of agreement with a set of
carriers or partners to terminate traffic. (Often an ingress customer may
provide egress services back to the wholesale provider, acting both as
a customer and vendor) The Wholesaler for instance, could harbor agreements
with
the local phone companies in different countries. The wholesaler's task is to
route traffic between ingress and egress carriers efficiently and profitably.

In some other cases, the customers and partners will present VoIP calls
to the wholesaler in effect themselves acting as ITSPs.
This is shown in Slide #2

Many wholesalers adopt a hybrid of the above two models, maintaining a set
of trunking POPs and handing off traffic to partner ITSPs, or viceversa.
This is shown in Slide #3

In all these environments, there would be a set of carrier-based policies
provisioned into a policy server in the network that is representative
of the ITSP's agreements with different carriers/partners. When a call
enters an ITSP's network, either from a PSTN carrier or from
another ITSP, the carrier policy server is consulted to determine the egress
carrier to be used for the call. The call is then routed to the appropriate
PSTN gateway (or Signaling Server) that is connected to that egress carrier.
The call could also traverse another ITSP, and terminate calls onto certain
prefered egress carriers. This can be enabled through partnerships between
ITSPs. The information that is desirable to have here (at a Location Server)
is knowledge of the gateway(s) (or ITSPs) that has connection with the
different
egress carriers. This is where Gateway registration can add value by
advertising the Carrier information on the gateways to the Location
Server. This information is useful to the different location/signaling servers
in the provider's network or ITAD and also in other providers networks (or
ITADs)
Such carrier information can be shared between different providers subject to
agreements.  The Carrier information can be made available in the provider's
network and to other providers by advertising this information from the
first-hop Location Server both in I-TRIP and E-TRIP.

Then, as regards to managing an ITSP's network, there is the need for
efficient capacity management on the gateways. I envision that the PSTN
gateways are going to get larger and carry more trunk groups to meet the
demand for high call volume. It is neither feasible not adds value in
reporting trunk availability updates for every call or for every few calls.
What adds value is to report this availability for significant changes
in availability. This is addressed by local thresholding mechanisms on
the gateway, and have capacity based updates triggered by these thresholds.

The question is, also if trunk availability should be reported
as a gateway chacteristic or a prefix characteristic. The way I see is,
it is neither. It is best expressed as an attribute of a Carrier/Trunk group.
The capacity reported as a property of this combination offers the best
value. In an environment driven by Carrier routing, what is desirable to know
is
the trunk availability on a given Carrier's trunks or in a particular
trunk group of a Carrier. This lends itself well into a more scalable
capacity management model.

The latest TRIP-GW draft describes how to advertise Carrier/TrunkGroup
information in TRIP. You can access it from:
ftp://ftpeng.cisco.com/ftp/dhaval/draft-rs-trip-gw-03.txt

Regards,
-Manjax

"Peterson, Jon" wrote:

> 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.
>
> 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
>