Subject: RE: [IPTEL] Definition of "trunk group"

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 3 Jan 2002 01:43:07 -0600

I agree with your definition of a trunk group; we arrived at a similar one
on the mailing list earlier (i.e. roughly, a bundle of DS0's between two
PSTN network entities that are grouped under some kind of common policy).

I agree as well that 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 (the TRIP model). My contention has
been 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, and I believe
slightly less variation amongst trunk groups.

We discussed splitting TGs across multiple GWs at SLC - if I recall, I was
willing to commit to that proposition with the small caveat that you can't
split SS7 IMT TGs across PCs. However, I'm sure you'll acknowledge that it
isn't uncommon for ISDN NFAS groups to straddle physical gateways, and I
feel that our definition of TG should be broad enough to include these.

The question of whether the 'route list' model gives us still more leverage
than the 'trunk group' model is interesting; 'route list' certainly provides
an even greater level of abstraction. Without going through a lot of
semantic hair-splitting, I think that trunk groups provide just the right
layer of abstraction. The question here is "What entities should the gwreg
system provide the availability of?" I think trunk groups have state that
changes dynamically, and that these states in turn determine the
availability of network resources. A proxy server that receives
registrations for such trunk groups would construct the 'route list,' as it
were, of alternative trunk groups that meet the routing criteria of calls. I
don't think a system in which 'route lists' were published to proxy servers
through the gateway registration process would grant us much additional
leverage on network design - in fact, I suspect it would just push the
problems around a bit.

Jon Peterson
NeuStar, Inc

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, December 31, 2001 11:12 AM
> To: [email-masked]
> Subject: [IPTEL] Definition of "trunk group"
> 
> 
> I have the following comments concerning the use of the term 
> "trunk groups" 
> based on the presentation in SLC and the discussion on the list:
> 
> I believe that a lot of the disagreement is related to the 
> definition and 
> concept of what a "trunk group" is. There was mention of a 
> "trunk group" 
> being those facilities through which one could get to a 
> specific destination 
> or reach a specific set of carriers. Also, the presentation 
> showed a trunk 
> group split across multiple Gateways.
> 
> For reference, the following 2 definitions come from American 
> National 
> Standard T1.523-2001:
> 
> trunk: 1. In a communications network, a single transmission 
> channel between 
> two points that are switching centers or nodes, or both. 2. 
> [A] circuit 
> between switchboards or other switching equipment, as 
> distinguished from 
> circuits which extend between central office switching equipment and 
> information origination/termination equipment. [47 CFR 
> Pt.36-A] Note: Trunks 
> may be used to interconnect switches, such as major, minor, 
> public and 
> private switches, to form networks.
> 
> trunk group: Two or more trunks of the same type between two 
> given points.
> 
> The definition of "trunk group" in telephony does not include 
> where you can 
> get to by going through it. As noted in SLC, in many cases, 
> all destinations 
> can be reached through a specific trunk group due to the 
> routing which the 
> next switch may do. Basic requirements in the US are that all 
> carriers can be 
> reached by the end user, so, in some cases, when talking 
> about a trunk group 
> from a Gateway which serves as the user's originating end 
> office, that trunk 
> group can reach every carrier and every destination. In 
> others, if the trunk 
> group in question connects to a specific carrier (the 
> termination "point" of 
> the trunk group), then it is likely that it can only reach 
> that one carrier. 
> When talking about a trunk group terminating at an end office 
> (or a Gateway) 
> then it can probably only reach destination connected to that 
> end office.
> 
> It is not correct to depict a trunk group split between two 
> Gateways unless 
> the 2 Gateways are simply 2 physical devices which act as a 
> single switching 
> "point" controlled by a single MGC. In this case, the 2 
> physical devices are 
> really 1 single Gateway for purposes of architecture and 
> signaling with other 
> MG/MGCs.
> 
> This issue in IPTEL can be simplified if the definition for 
> "trunk group" in 
> T1.523 (which is consistent with the usage in ITU-T) is accepted.
> 
> A further definition in T1.523 is:
> 
> route list: A specific list of trunk groups. [After T1.667-1999]
> 
> This is more similar to the term "trunk group" as being used 
> in the IPTEL 
> discussions. The function of "routing" a specific destination 
> address in any 
> switching element results in the determination of a "route 
> list", which 
> points to a list of trunk groups (alternate routes).
> 
> Mike Pierce
> Artel
> _______________________________________________
> IPTEL mailing list
> [email-masked]
> http://lists.bell-labs.com/mailman/listinfo/iptel
> 
_______________________________________________
IPTEL mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/iptel

---

From: [email-masked]
Date: Fri, 4 Jan 2002 12:00:03 EST

In a message dated 1/3/02 2:43:27 AM Eastern Standard Time, 
[email-masked] writes:

> (snip)
Jon,

Although you said above that you agree with my definition of "Trunk Group" 
(copied from T1.523), your reply to Mike Hammer the same day still indicates 
that you have a very much different concept of what a "trunk group" is and 
how it is used in routing calls to specific carriers (based on the CIC). Mike 
Hammer's e-mail correctly described the routing. Interpretation of the CIC 
(or any other digits dialed) results in a pointer to a trunk group. 
Obviously, multiple CICs can point to the same trunk group, and, with 
alternate routing, each CIC can point to multiple trunks groups (in an 
ordered list defined as a "route list"). I guess this is what you mean by 
saying that this relationship is not "hierarchical". I would say it's not 
one-to-one or one-to-many, but rather many-to-many. In telephony routing 
"hierarchical" has had a different meaning.

It confuses the issue to describe trunk groups in terms of what CICs (or 
E.164 number ranges) they can reach, which is what your comments still do. 
Further, your statement that "One or more CICs may be 'preferred' for a 
particular trunk [group] by some switch ..." does not correctly represent the 
dialed digit interpretation/alternate routing that takes place.

I'm further confused by the references to "logical trunk groups" and what 
significance this has. It is possible for an implemenation to further 
subdivide actual (physical) trunk groups into some "logical" sub-grouping, 
for example, to help it prevent glare on two-way trunks, but I don't think 
this is an important concept to include in these discussions. Does "logical 
trunk group" have some additional meaning or significance?

Regarding your comment on "whether the 'route list' model gives us still more 
leverage than the 'trunk group' model" --- the "trunk group" concept is 
fundamental to all descriptions of routing, since it represents the actual 
physical facilities (sometimes DS0s as you noted) between real network 
elements. The "route list" concept, on the other hand, represents the 
internal workings of a switch and does not impact the signaling between 
switches, so is less important. However, it is a useful concept and 
definition since it helps to have a common concept of how telephone calls are 
routed (what I call "alternate routing").

Mike Pierce
Artel

---

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 4 Jan 2002 17:59:35 -0600

My email had suggested that we coin a new term, as it were, and define
whether a CIC is 'reachable' through a trunk group based on certain specific
criteria - I recognize that the 'reachability' of CICs is not an existing
concept in the PSTN, and I apologize if this concept confuses you.
Traditional PSTN switches do not support dynamic gateway registration, and
yes, therefore the PSTN has no need for a protocol that propagates
reachability information at all. Despite your reservations, we all really do
agree, I think, on how CICs are routed in a traditional telephone switch. An
IP telephony network of gateways is not, however, a traditional telephone
switch, and I believe this concept of 'reachability' is useful in this new
domain - it been used, for example, throughout the TRIP literature since its
inception (i.e. E.164 numbers are 'reachable' through a particular gateway).

In a similar spirit, my suggestion that CICs might be 'available' or
'preferred' with regard to a particular trunk group has no corrollary in
traditional telephone networks. However, I suspect you understand the
difference between a trunk being directly connected to a given carrier, and
a trunk group (like one pointing to an access tandem) being identified as a
route to multiple carriers. 'Available' and 'preferred' are attempts to
capture these sorts of characteristics of a trunk group in the scope of
'reachability', not to speak to how characteristics might be processed
during a route decision in a proxy. Propagating routes to proxies and making
routing decisions within proxies are related but distinct problems - this WG
is currently focused on the former, not the latter. 

I personally have no commitment to a concept of 'logical trunk groups' -
this was raised by Mr. Hammer, and my response to him indicated that I
wasn't sure how it would be applicable to this problem.

Incidentally, 'hierarchical', in the sense that I believe Mr. Hammer used
it, refers to how route discriminators are processed by the proxy server to
make a routing decision, based on the TRIP concept that discriminators
should be concatenated from most specific to least specific. Not all of the
nomenclature used in this discussion is predicated on PSTN antecedents.

Jon Peterson
NeuStar, Inc.

> Sent: Friday, January 04, 2002 9:00 AM
> To: [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: [IPTEL] Definition of "trunk group"
> 
> 
> >  than the 'trunk group' model is interesting; 'route list' 
> certainly 
> provides
> >  were, of alternative trunk groups that meet the routing 
> criteria of calls. 
> I

---

From: [email-masked]
Date: Sun, 6 Jan 2002 19:35:07 EST

>  is currently focused on the former, not the latter. 
Yes, I realize that the issue is "propagation" of routes rather than how that 
data is actually used to route calls. But I believe that a solid 
understanding and agreement of how telephony routing occurs is required 
before too much detail on "propagation" is done. I think Mike Hammer's 
comments are addressing this issue. There is a fundamental difficulty, since 
the network architecture requires that many trunk groups handle all traffic, 
regardless of the CIC or destination address specified, but the route 
propagation is based on a different concept.

Regardless of the functions of "route propagation", it seems to me that the 
function of "routing" still means that interpretation of the CIC (and other 
dialed information) results in the selection of an ordered list of trunk 
groups (physical facilities) by which a call can be routed (called a "route 
list" in T1.523). I especially have a concern with your statement that "CICs 
might be 'available' or 'preferred' with regard to a particular trunk group 
has no corrollary in traditional telephone networks". I don't think this 
statement represents the required routing logic (independent of how this 
information is propogated). I believe the required routing logic does have a 
direct corrollary in the traditional telephone network. The concepts of 
"available" and "preferred" are included by the ordered list of trunk groups. 
(The first trunk group is preferred, the second is preferred next, etc. All 
in the list are available.) The difficulty with indicating "preferred" and 
"available" in the route progagation procedure is that it can not indicate an 
actual order to be used in the actual route selection.

It seems that there must first be a common agreement on what routing 
procedures are required. Only then can route propogation procedures be 
defined.

Mike Pierce
Artel

---

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 8 Jan 2002 08:03:56 -0600

I think I understand our disconnect after reading this mail; towards the end
I offer a fairly lengthy example which hopefully illustrates where I'm
coming from.

Jon Peterson
NeuStar, Inc.

> Sent: Sunday, January 06, 2002 4:35 PM
[snip]
> There is a fundamental 
> difficulty, since 

I don't think route propagation is based on a 'different concept' - I think
we need to reconcile gateway registration to the realities of network
architecture. That's been the overriding thread of my many mails on gateway
registration and trunk groups.

> list" in T1.523).

Totally. I'm with you there. The construction of that route list will be
performed within the proxy server that is provisioned by the gateway
registration process. Thanks to all of the timely information it has learned
from gw reg, the proxy server will construct a list that will be more likely
to result in the prompt termination of the call than it would if it had no
gw reg 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 gw reg
process, which tell the PS what possible terminations are available.

> I especially have a concern with your 
> statement that "CICs 
> information is propogated). 

The concepts of 'available' and 'preferred' in and of themselves, of course,
do not represent the required routing logic. They are just data that are
taken into account by the routing logic in a proxy server in order to
construct a route list for a particular call.

Incidentally, I'm not married to the terms 'preferred' and 'available'. I
brought them up to give a sense of the role they might play in the
construction of route lists. Probably better terms would be 'directly' and
'indirectly' available, where a CIC is 'directly' available through a trunk
group iff the administrative domain of the switch on the other side of the
trunk group is the administrative domain responsible for that CIC.

> I believe the required routing 
> logic does have a 
> in the list are available.) 

This is good - I think this is where our disconnect is. The problem I'm
trying to solve is 'how does a proxy server construct an ordered route list
for a particular call based on the information it receives from gateway
registrations?". When you talk about how CICs are routed, you seem to assume
that this route list has been provisioned by some other means, or that the
information propagated by gw reg literally is the route list.

Here's how I think it should work: The information that is propagated by the
gateway registration protocol is a set of potential routes, just a set of
TGs and some of the attributes of these trunk groups. These because actual
routes for a specific call later, when a proxy server makes a routing
decision.

Consider a simplified example. A proxy server (PS) receives gateway
registrations for three trunk groups, TG1, TG2 and TG3. For TG1, CIC 0288 is
"preferred" and all other CICs are "available". For TG2, only CIC 5062 is
"preferred". For TG3, all CICs are "available". These are the potential
routes.

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 that is "preferred"
for the CIC associated with the call. TG2 is ineligible because 0288 is not
available through TG2. TG3 is "available" for 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 for the call in mind, the PS routes forwards the call to
the GW responsible for TG1. If the call doesn't succeed there for some
avoidable reason, the PS will subsequently forward the call to the GW
responsible for TG3.

As a bit of back-story, how do the owners of the GWs decide on the
"preferred" and "available" settings for their TGs with respect to
particular CICs? Well, when the owner of the gateway on which TG1 is located
turned up TG1, he provisioned the GW with a set of information about TG1.
Maybe he learned this information directly from the carrier whose switch
terminates the other end of TG1 - maybe he looked some of it up in the LERG
- in any event he learns this information administratively. One such piece
of information is that the carrier on the other side of TG1 (to which TG1 is
"directly" connected) is addressed by CIC 0288. He also knows that this
carrier is an IXC, and that all CICs are therefore "indirectly" available
through this carrier.

Finally, note that when a call arrives at the PS, it has many routable
attributes other than a CIC. Calls also, for example, have a dialed number.
The route selection algorithm in the PS, 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" available routes to
"indirectly" available routes, and so on. This route selection algorithm, in
my opinion, should if possible be independent of the gateway registration
protocol - that is to say, the gw reg protocol should just provide the data
and let the PS worry about how that data will be used to route calls.

> The difficulty with indicating 
> "preferred" and 

Agreed, it can't. All it does, as my example above should show, is give the
PS some data that is used by the route selection algorithm. This is critical
because I don't think gateway registration should control the route
selection algorithm itself - for example, by somehow providing an ordered
list of TGs to the PS that will apply to some set of calls. Multiple
gateways will be sending routes for various trunk groups to the PS in a gw
reg message. Presumably, these gateways do not know about one another. The
PS receives routes from these various gateways, and for a particular call
the PS should be allowed to add TGs located on various GWs to the route list
- therefore no GW should be dictating route lists to the PS. 

But 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, in my
opinion, the whole purpose of gateway registration.

---

From: "Tom-PT Taylor"<[email-masked]>
Date: Tue, 8 Jan 2002 09:53:48 -0500

I think you're on the right track, Jon.  There are basically two
possibilities: that registration provides the data from which route lists
can be constructed, as you suggest, or that proxies contain pre-defined
route lists and registration data is used to verify the validity of
individual entries within these lists.  I agree with your argument that,
because route lists will typically span multiple gateways, the registration
data do not consist of route lists in themselves.

If we accept your view, the aim of the exercise is to acquire registration
data which support the construction of "good" route lists according to some
criterion.  What your examples illustrate for that criterion is a very rough
topological distance measure: "direct" vs. "indirect" (assuming these are
exactly what you meant by "preferred" vs. "alternate").  The "points" in
this topology are individual service providers' networks.  The questions
raised if we follow this line are whether other measures of "goodness" have
to be supported by the registration data and if so, which ones.

Speaking of topology, at some point we may have to worry about loop
prevention.  One assumes that loops won't happen provided that a call passed
to the switched domain stays there, but we can't count on that.  This is
probably a call signalling issue -- I'll try to see that it is addressed in
the SIP-ISUP work being done in Study Group 11.

Just pursuing the second alternative I mentioned in my opening paragraph for
a moment: there is the possibility of a statically administered set of route
lists within proxies.  The role of gateway registration would then be to
give a dynamic view of gateway and trunk group status, to make routing more
effective within the preprovisioned framework.  Given what I see as the
slowly-varying nature of the switched network topology as I used the term
above, preprovisioned routes could be "better" than those created
dynamically, promote more stable network operation, yet gateway registration
would provide an essential element of adaptiveness.  I describe this
alternative for logical completeness, but I expect it is a less-preferred
method of operation.

We can probably design gateway registration to support either method of
operation.  However, the detailed information requirements and possibly the
required reporting frequency may be different between them.

-----Original Message-----
From: Peterson, Jon [mailto:[email-masked]]
Sent: Tuesday, January 08, 2002 9:04 AM
To: [email-masked]'; [email-masked]; [email-masked]
Subject: RE: [IPTEL] Definition of "trunk group"

Jon Peterson
NeuStar, Inc.

[snip]

---

From: Michael Hammer <[email-masked]>
Date: Tue, 08 Jan 2002 11:43:44 -0500

Tom, Jon,

I concur with your line of thought, although I think the terms "direct" and 
"indirect" are more descriptive and useful.  Will these characteristics be 
propagated as attributes when advertising that a TG can reach a specific 
carrier?

Mike

---

From: [email-masked]
Date: Sun, 13 Jan 2002 18:23:44 EST

In a message dated 1/8/02 9:35:07 AM Eastern Standard Time, 
[email-masked] writes:

>  > I believe the required routing logic does have a 

I understand that the idea is to construct the route list from the 
information derived during the GW registration process. The problem is 
describing the process, considering that the GW registration process only 
provides a small part of what is needed to construct a route list. Sometimes 
it is no more than a hint.
>  TGs and some of the attributes of these trunk groups. These become actual

This simple case is obvious to the PS, since it got one "preferred" and one 
"available" choice for CIC=0288. (Actually, this isn't even obvious, since 
the determination of "preferred" and "available" was made by the GW, but the 
PS may have a legitimate reason to reverse the selection order based on other 
information it has, like the GW that said "available" is next door and the 
one that claimed "preferred" is on the other side of the world.)

The difficult case is when the PS receives multiple "preferred" choices. In a 
particular network situation, each GW may be owned by a different company who 
makes their money by getting traffic to go through their GW. They would 
specifiy everything that they could possibly handle as "preferred" and never 
as just "available".

Mike Pierce
Artel

---

From: "Roy, Radhika R, ALASO" <[email-masked]>
Date: Mon, 14 Jan 2002 13:14:58 -0500

Comments inline [RRR]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Sunday, January 13, 2002 6:24 PM
To: [email-masked]; [email-masked];
[email-masked]

....

[RRR] In intra-domain, it is assumed that all GWs will be administered by a single IP Telephony service provider. In this situation, the logic of "preferred" and "available" is expected to be maintained in accordance to the policy of the given service provider.

Mike Pierce
Artel

---

From: Michael Hammer <[email-masked]>
Date: Mon, 14 Jan 2002 15:59:32 -0500

That is why it may be better to separate the policy decision (which is 
preferred) from the basic facts.  The use of terms "direct" and "indirect" 
meaning that a switch of that carrier is one hop from the gateway doing the 
advertising is factual and unambiguous.

Mike

At 01:14 PM 1/14/2002 -0500, Roy, Radhika R, ALASO wrote:
>[RRR] In intra-domain, it is assumed that all GWs will be administered by 
>a single IP Telephony service provider. In this situation, the logic of 
>"preferred" and "available" is expected to be maintained in accordance to 
>the policy of the given service provider.
>
>Mike Pierce
>Artel

---

From: "Roy, Radhika R, ALASO" <[email-masked]>
Date: Mon, 14 Jan 2002 16:24:04 -0500

Hi, Mike:

You are right and I agree with you (because it is better NOT to standardize "subjective" terms related to policy per se).

Thanks for your clarifications.

Best regards,

Radhika R. Roy
[email-masked]

-----Original Message-----
From: Michael Hammer [mailto:[email-masked]]
Sent: Monday, January 14, 2002 4:00 PM
To: Roy, Radhika R, ALASO
Cc: [email-masked]; [email-masked];
[email-masked]
Subject: RE: [IPTEL] Definition of "trunk group"

Mike