Subject: RE: [IPTEL] carrier scenario for TRIP

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 3 Dec 2001 03:00:44 -0600

In the model I suspect to be the correct one, the LS would only know of the
existence of the trunk groups propagated by the MGC, although of the course
the availability of TGs is predicated on the avaibility of one or more
gateways.  The LS would however have direct knowledge of the availability of
the MGC itself; presumably if the MGC somehow became unavailable, so would
all of the resources that it controls. In this respect the LS can adopt the
same behavior towards an MGC, that controls many trunk groups, that we would
expect it to use for a single small smart gateway that might control only
one trunk group.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Hussein F. Salama [mailto:[email-masked]]
> Sent: Saturday, December 01, 2001 12:38 PM
> To: Peterson, Jon; [email-masked]
> Subject: Re: [IPTEL] carrier scenario for TRIP
> 
> 
> 
> 
> "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: Michael Hammer <[email-masked]>
Date: Tue, 04 Dec 2001 15:45:31 -0500

Jon,

A trunk is a single circuit (DS0) between two switching nodes that is 
shared on a call-by-call basis, as opposed to a local loop that serves only 
one user (telephone number address, excepting party lines).  A trunk group 
is a bundle of DS0's and the first level of aggregation.  (Please don't 
propagate the confusion that a trunk is more than one circuit.)  After that 
you can address Routes and Route Sets/Lists as higher echelons of 
aggregation.  Those lists may be ordered and unordered.

I suspect that H.248 and MGCP are used for communications between the MGC 
and MGW involving the availability and status of the MGW.  The MGC should 
be able to provide a complete picture of the MGW that it controls.  Any 
suggestion that additional signaling of this nature is needed should be 
deferred to the Megaco WG rather than addressed here.  To distinguish smart 
and dumb gateways, you might want to stipulate that the signaling endpoint 
for the gwreg protocol should be capable of terminating session/call 
signaling (i.e., SIP).

Otherwise, this is a great writeup.  Furthermore, I agree with the need to 
have additional attributes like LRN's and Carrier ID's that add context to 
the indication that a number is "reachable."  While this won't completely 
address the "cost" issue, it can give great clues about where to direct 
signaling to get sessions setup to the "best" gateways.

Mike

At 02:06 PM 11/30/2001 -0600, 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.
>
>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
>
>

---

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 4 Dec 2001 22:04:07 -0600

Agreed that it's important that we define trunk group precisely if we intend
to use it in any meaningful way. I'd suggest we refer to the definitions
from SR2275:

Trunk: In a network, a communication path connecting two switching systems
used in the establishment of an end-to-end connection. It 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.

I believe since the introduction of ubiquitous digital trunking, since
trunks never run over non-digital facilities, it has become common to refer
to 

Jon Peterson
NeuStar, Inc.

> From: Michael Hammer [mailto:[email-masked]]
> Sent: Tuesday, December 04, 2001 12:46 PM
> To: Peterson, Jon
> Cc: [email-masked]'

---

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 4 Dec 2001 22:24:37 -0600

Whoops - sent an incomplete version of this. Please disregard my preceding
mail.

-----

Agreed that it's important that we define 'trunk group' precisely if we
intend to use it in any meaningful way. I'd suggest we refer to the
definitions from SR2275:

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.

I believe that since the introduction of ubiquitous digital trunking, which
resulted in the allocation of DS0s between end offices in minimum groups of
24, it has become common to refer to bundles of DS0s as a trunk. You're
right that we shouldn't further any confusion about this matter - but
provided that we all understand that a TG is a bundle of DS0s between end
offices, I think we'll be all right.

I was certainly thinking that a protocol like H.248 would be used between an
MGC and any gateways it controls. I definitely agree that no new protocol
should be required between the MGC and its gateways in support of gateway
registration - and that if there is any new package or what have you that's
required for the device control protocol that it shouldn't be pursued in the
IPTEL WG. I also firmly agree that any endpoint that speaks the call setup
protocol (i.e. SIP) should speak the gateway registration protocol - I hope
this comes through as my contention in the write-up.

Jon Peterson
NeuStar, Inc.

---

From: Michael Hammer <[email-masked]>
Date: Wed, 05 Dec 2001 11:42:45 -0500

Jon,

I'm a little uneasy about the wording in that definition for Trunk.  We 
need to maintain the idea that the "communication PATH" is an individual 
circuit.  The reason is that the DS0's need to be managed 
individually.  The use of "path" can be confusing.  Looking at ATM, the VCI 
is a trunk, the VPI (path) is a trunk group, even though the VCI capacity 
may exceed that of a DS0.  On the other hand, a circuit in the packet world 
may map to a "bundle of DS0s" i.e. trunk group in the TDM world.

So, can we stick to trunks (=DS0) and trunk groups (=bundles of DS0) for 
the TDM (not packet) domain, and use circuits and paths (or other 
aggregation terms) in the packet domain, and not mix the two?  The unifying 
concept is that the lowest unit serves one user at a time, while the 
aggregate may be supporting streams from different users.

Mike

---

From: [email-masked]
Date: Sat, 8 Dec 2001 14:29:31 EST

Im not for sure if Theese questions of mine have made it to the list, or not, 
and if they have, and If they've been answerd (If so, could someone please 
resend the responces to me?), Ive had a few email issues lately...   :/

Theese were in reguards to the TRIP-GW draft that Manjunath had on the cisco 
FTP server

Are we no longer routing on ITAD #'s, and now routing on FG-B/D CIC's??
What if someone outpulses digits to a gateway with a FG-D CIC in it, will
the gateway route the call on that CIC, or will there be some type of a
parameter in either the Voice G/W, or the RouteServ to implicitly deny
FG-B/FG-D Dial arrounds??

Also in reguards to trunking, how will TG's be tracked on the RouteServ for
traffic sculpting, and billing purposes??

---

From: "Roy, Radhika R, ALCTA" <[email-masked]>
Date: Sat, 8 Dec 2001 18:39:04 -0500

Comments are inline [RRR]. You have made a very important point. I have expanded this point seeing the big danger in the future.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Saturday, December 08, 2001 2:30 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [IPTEL] carrier scenario for TRIP

Im not for sure if Theese questions of mine have made it to the list, or not, and if they have, and If they've been answerd (If so, could someone please resend the responces to me?), Ive had a few email issues lately...   :/ 

Theese were in reguards to the TRIP-GW draft that Manjunath had on the cisco FTP server 

Are we no longer routing on ITAD #'s, and now routing on FG-B/D CIC's?? 
[Roy, Radhika R, ALARC] I believe that we need to have ITAD #'s as well to be consistent with the (inter-ITAD) TRIP. We just cannot arbitrarily propose that we will NOT use it. Otherwise it will create a big hole because the whole situation is concerned about a given ITAD. 
 
[Roy, Radhika R, ALARC] There are other important issues what I have provided in my earlier email with this proposed protocol. If people want to use a short-cut in the name of so-called "Gateway Registration," we have to pay a heavy price because of INCOMPLETENESS for the sake of so-called "SIMPLICITY." 
 
[Roy, Radhika R, ALARC] We need to look into it very carefully for the whole protocol that will be used in an ITAD. In an ITAD, there will not only be many GWs, there will be many types of GWs as well (e.g., SIP-ISUP, SIP-H.323, SIP-BICC, etc.). In addition, there will be many SIP Proxies/Location Servers.
 
[Roy, Radhika R, ALARC] People must NOT be forced to use the so-called I-TRIP between the SIP Proxies/Location Servers as it as been casually been mentioned in the (inter-ITAD) TRIP protocol. TRIP had no "mandate" or "charter" to develop the protocol for the "intra-ITAD" or "intra-Domain." I-TRIP has been mentioned as a place holder in that spec just, by the way, to show how a subset of TRIP can be used within an ITAD. We have accepted this example on "good faith," but NOT as the "standardized" protocol that will be used in an ITAD. The use of I-TRIP in an ITAD is very inefficient as we have analyzed in our contribution (http://www.ietf.org/internet-drafts/draft-roy-iptel-itrp-00.txt) and, if the protocol for communications among the location servers in an ITAD is not standardized, people will be forced to use the so-called "inefficient" I-TRIP protocol. This may be trap.