Temp, I'm not absolutely certain of what FTEL's intentions are, although I have a pretty good idea.
It's quite possible to have a clear shot through _two_ backbones, unobstructed, provided they are not congested and the hop count remains low. And it's also possible to have a terrible time on a single backbone if it isn't sized properly, and entails too many hops.
---
I think that the private backbone, in the context that you are referring to, is different than, say, if the packets were being sent over the public Internet. What most ITSPs will do in order to establish a controlled environment for transmission when they take this approach, is to install a mesh of "dedicated" private lines (T1s and Fractional T3s/T3s) between their primary router nodes. The ITSP will still be using the Internet Protocol, but it will be on a private IP backbone. A thrid choice is to use one of the Interexchange carriers separate IP backbones (not the public Internet) and resell capacity at the retail level. Each of these constitutes the qualities that would make up your "A" Backbone.
This mesh of private lines (or, alternately, leased segments of IP networks) is the private backbone you are referring to, and the fact that it is being supported by WCOM or T or IIXC is inconsequential to the theme; it will work just as well, regardless of who the carrier is, if it is designed properly.
Of course, if you have a colo arrangement with a global carrier, you use 'that' carrier, and all the better for it, since it guarantees the ITSP some consistency of pricing (cost predictability) and administrative practices across the board (uniformity of look and feel).... and oh, yes... it also means that you've cut a deal that makes financial sense, it would be hoped.
Having a private mesh in place gives the ITSP the ability to control transmission parameters, and route dynamics, such as total number of hops, routing tables, latency and jitter, availability of special features such as multicasting and conferencing, and QoS/CoS attributes as well, etc., a lot more easily than in a heterogeneous and unpredictable public cloud ever could. Provided, of course that the ITSP properly sizes and tunes their routing resources, transmission media, and policy rules. Security is also a lot more manageable when using a private cloud, obviously. To sum it up, the up side of a private IP backbone is higher quality, and a more satisfied customer. The down side?
The down side of using the private mesh (your "A" Backbone exclusively) is that the ITSP is not taking advantage of economies of scale resulting from shared usage, in those not-so-heavily traveled routes, and is forced to go off-net _anyway_ at some point, in order to reach destinations that are not covered by the private cloud. This could be done several ways, either through a gateway to the public Internet (your "B" cloud) or directly to the PSTN, and suffer the consequences of a toll charge, possibly. Both approaches are being contemplated and used for different reasons.
For end-to-end domestic calls, say, within the CONUS, it would almost always have to be Internet all the way, i.e., from end-office to end-office, in order to control costs and remain competitive. On international calls, there's a little more breathing room, and some are shedding such situations directly onto the US PSTN, because the International segment is the lucrative part of the call, and the domestic landing and termination charges get lost in the noise, comparatively speaking. Besides, International IP calls (when placed of the Public Internet) can use all the help they can get.
Getting on to the "B" Backbone will also be a necessity at some point, when integrated (converged) services such as m-m apps, wide area conferencing services, and WWW hot-links, etc., are offered in addition to regular VoIP. In this case the "B" Backbone = the Public Internet. This can be achieved from the "A" Backbone (the ITSP's private net) through the use of a gateway router and firewall arrangement between the two clouds. At that point, the latency of the voice packets becomes subject to the mercy of the Public Internet.
HTH, Frank C. |
