x
Page 1 / 4   >   >>
beowulf888 12/4/2012 | 9:51:00 PM
re: Multiservice Switches Stephen Saunders wrote:
"Unlike IP services, ATM services offer a return on investment (ROI)."

Could you explain why ATM is such a money-maker? Per port, ATM is more expensive to deploy and maintain (at least that's conventional wisdom).

And why have AT&T's ATM revenues grown by 42 percent this year? What's driving this growth?

best regards,
--Beo
sgan201 12/4/2012 | 9:50:52 PM
re: Multiservice Switches Hi,
ATM provide better ROI is because the revenue per port is higher...
For example, a FR DS1 port revenue per month is around $2K per month.. An IP DS1 internet acess per month is around $500 per month or less..
It is 4 times difference...
Number one application of ATM is to carry FR..

<< Per port, ATM is more expensive to deploy and maintain (at least that's conventional wisdom).>>

This statement is not exactly true either..
If you want to deploy a network with QOS, ATM network is cheaper and easier to deploy..
Only if you do not care about providing good QOS, then IP is cheaper and easier to deploy..

jamesbond 12/4/2012 | 9:50:52 PM
re: Multiservice Switches For example, a FR DS1 port revenue per month is around $2K per month.. An IP DS1 internet acess per month is around $500 per month or less..
---------------------------------------

Can you please explain why is it that FR DS1
is more expensive than IP DS1 (i am guessing
PPP)? As far as service provider goes
he has to terminate the DS1 somewhere -
a FR switch or a router.

thanks
kampar 12/4/2012 | 9:50:51 PM
re: Multiservice Switches
>>>Can you please explain why is it that FR DS1
is more expensive than IP DS1 (i am guessing
PPP)? As far as service provider goes
he has to terminate the DS1 somewhere -
a FR switch or a router.

_____________

I suggest it is the VPN/Minimum Guaranteed Bandwidth nature of a Frame Relay circuit, compared to pure Internet access over IP ... An enterprise buys frame relay PVCs to interconnect its networks in a layer 2 VPN with QoS and service level guarantees - they will pay more for this ... you simply cannot achieve the same service today over a traditionally-routed IP network.

ATM to the enterprise would be even better than frame relay, but the ROI of rolling out ATM services at lower speeds to the enterprise has been a barrier to acceptance for many years, so we use FR at the edge and ATM in the core for scalability.

The introduction of MPLS technology will make it easier to offer VPNs at the IP layer (read: much less operational management overhead in managing the enterprise VPN and removal of the dependency upon FR as the layer 2 protocol)and enterprises will be prepared to pay the bigger bucks for this feature. MPLS technology claims to essentially offers a way to bring QoS and basic network traffic engineering (both requisite for a VPN service) to many different types of data sources, including IP, with minimal overheads (bandwidth and operational).
sgan201 12/4/2012 | 9:50:51 PM
re: Multiservice Switches << ItGÇÖs also worth noting that ATM VC support is especially important in networks that are carrying digital subscriber line (DSL) traffic, because each DSL connection requires two VCs GÇô one in each direction. >>

Hi Steve,
ATM VC is full duplex. You only need one VCC to carry traffic in each direction.
On the other hand, MPLS LSP is simplex.
You will need one MPLS LSP for each direction.
jamesbond 12/4/2012 | 9:50:47 PM
re: Multiservice Switches I suggest it is the VPN/Minimum Guaranteed Bandwidth nature of a Frame Relay circuit, compared to pure Internet access over IP ... An enterprise buys frame relay PVCs to interconnect its networks in a layer 2 VPN with QoS and service level guarantees - they will pay more for this ...
------------------------------------

But VPN isn't the same thing as plain IP
connectivity (i.e. connection to Internet).
I would use FR if I had offices in several US
cities and wanted to interconnect them and have
some guaranteed bandwidth.
On the other hand I would not care what interface
service provider gives me if all I wanted was
an internet connectivity. They can give me
FR, T1 or what have you.

Regardless I don't understand why Service provider
has to charge more for a FR service. Ultimately
FR and DS1 is probably going over an ATM network
anyways. I don't see any extra cost that
Service provider has to incur.

what am i missing?
beowulf888 12/4/2012 | 9:50:43 PM
re: Multiservice Switches jamesbond said it better than I could...
"Regardless I don't understand why Service provider
has to charge more for a FR service. Ultimately
FR and DS1 is probably going over an ATM network
anyways. I don't see any extra cost that
Service provider has to incur."

Does it all boil down to SLAs? An SP can charge more for services tied to SLAs than ones not tied to SLAs? If so, then FR (which is what is most often deployed on the edge) would be the real money maker.

Steve, where are you when we need you? ;-)

--Beo
cc_junk 12/4/2012 | 9:50:42 PM
re: Multiservice Switches

I think that one of the respondents is confusing the FR service
market with FR as an access technology to the Internet.

The FR service market is private line replacement for enterperises
interconnecting sites in their corporate networks (intranets). Using
FR as an access method to an ISP is a different market. Although,
there are carriers that provide bundles - a single access circuit to
their FR switching network with a PVC as access to their Internet
service and regular PVCs for the corporate WAN. Single circuit,
multiple services.

Since the FR market is different from the Internet market the pricing
is different. An economics 101, pricing of the service does not
reflect the cost of the service, but instead reflects the market
price. FR services are profitable because the market prices have
positive margins relative to the cost of providing the service. Many
Internet services (all?) have negative margins because the market
price is below the cost to provide the service.

Also, when comparing costs of FR/ATM services with Internet services,
capital costs are a small piece of the total cost. Furthermore, if
you are comparing enterprise equipment costs for enterprise routers
and ATM switches, that does not necessarily translate into an
appropriate comparison for providers who use a different class of
equipment. Carrier class equipment does not have that great of a
price difference per port between routers and ATM switches.

As for the total cost, beyond the capital per port of the
switching/routing platform, consider the costs of the network
development, OSS development, Operations, trunking costs (to
interconnect the rotuers/switches) and customer care. The port cost
of the router/switch is a fraction (very significant, but far from the
majority). I know that the OSS's are much more sophisticated for ATM
networks compared to router networks. ATM switches have better
redundancy and reliability than routers (how many in service provider
routers are _currently_ in-service software upgradeable without
impacting customers?). Operations and customer care organizations
tend to be smaller (headcount per customer port) for ATM service
networks than router networks. Again, lack of EMS/OSS for routers
(the standard router provisioning is either human or an expect/perl
script taling to a CLI tty).

Finally, customer care for routing service is more expensive. Case in
point: an enterprise connecting two sites using a private line only
calls the carrier if the private line is down. The carrier has a
limited number of tests to be done to evaluate and fix the private
line, and none of them involve the enterprises routing. If the
enterprise has a routing problem ("can't reach IP address X) do they
call the private line provider if the private line is okay? No. It
is also true for FR/ATM services. If the enterprise is having routing
problems and the PVCs are up they don't bother the PVC provider with
their IP routing problems. But with a provider routing service, if
the enterprise has routing trouble they often call the provider.
[example call: C: "hey, I can't reach address X". P: "Okay, we see
the route and our network looks okay." C:"Well, I still don't have
reachability. Can you take a look at my premise router config?" P:
"Okay (can't refuse important enterprise customer)". Some time later
P: "Okay, found the problem - you fat fingered a network
advertisement."]

Bottomline, providing an IP routing service on par with a FR/ATM
service is more costly and is coupled with the problem that the market
prices for Internet service are lower than for FR/ATM.


The earlier post confused FR service with access to ISP.

FR as an access method to an ISP is not necessarily priced more or
less than using PPP. The providers cost for using FR versus PPP may
vary. If the provider has a large footprint FR network compared to
their IP service then backhauling the FR PVC to the access router is
probably cheaper than backhauling a private line - this is
particularly true for global carriers. But using a FR switch network
to reach the access router when router footprint is comparable to the
FR network footprint is probably more costly. When just using FR
encapsulation versus PPP over a private line directly connected to the
access router there will be no cost difference.
cc_junk 12/4/2012 | 9:50:38 PM
re: Multiservice Switches The discussion about internal switch fabric is not really
important. Many high end routers, for example, have fixed
packet length fabrics (effectively "cell" fabrics).
And fabrics always have more bandwidth with the actual slot
I/O, because there are always addtional headers/overhead to
handle routing (fabric routing) and packet handling within
switch.

The author is confusing this with whether or not the
backbone (trunking) interfaces are frame or ATM cell based
and the issues with those choices.
greybeard 12/4/2012 | 9:50:24 PM
re: Multiservice Switches > Does anyone know why Lucent has fallen off the
> planet in this area that Cascade/Ascend
> initially ruled? (CBX-500 & GX-550).
>
> Their data sheets show a lot of promises for
> the GX-550, but they've failed to deliver (for
> 2 years) on the following areas...

This is really simple, and quite obvious to anyone who was at Cascade, or who knew many people who were at Cascade.

The simple fact is that 350 smart and pretty good junior engineers, with no relevant experience and no adult supervision, can't build a product. 150 engineers, including 120 smart and pretty good junior engineers and 30 smart, practical and very good experienced engineers *with appropriate relevant experience* can build a very good product.

At the point that Ascend purchased Cascade, the engineering team at Cascade was very good. They were a little bit caught between products (the previous product sales started to slump a bit before the next product was shipped), but they were a kick ass team building a kick ass product (the 550 was well along, and other good things were in the works).

Ascend didn't run Cascade long enough to cause a clear result. However, it is pretty obvious that from the point that Lucent purchased Ascend the experienced folks at Cascade mostly left (many leaving before the purchase was finished). It is not possible for me to know what was going on in the minds of the managers from Lucent (I didn't know them), but it sure looked from outside as if they were quite happy to have the experienced engineers leave.
Page 1 / 4   >   >>
HOME
Sign In
SEARCH
CLOSE
MORE
CLOSE