Peter Lothberg writes:
I don't undertsand, if ATM did create bandwith it would be great, but it does not. If ATM was needed to make packets move it would be great, but it's not.
One issue on the above is that the ATM pipes have the history of going a step faster than the wide area IP pipes at the same time. Like we're now at STM4 for ATM and at STM1 for IP. Though this does not help too much with the current routing gear, but at least you can feed your backbone with a stack of STM1 ATM interfaces and actually move bits at aggregate rates that go STM4 if not faster (I can put multiple STM4 pipes in parallel in the backbone).
1. You need routers in and out of your cloud if your service is IP. STM-4 (packets) as router interfaces will be availiable when needed.
It seems to be usable as aa replacement for X.25 and Frame-Relay, for those who buy bandwith and routers and build private networks, but, for a public infrastructure, I don't think so.
A close look at the Internet market shows a large set of products aimed, in a way or another, for 'secure transmission of data over the Internet'. Either terminal-connections, like SSH, or VPN's. I see that as a clear demand for VPN services, at least for the area where bandwidth is inexpensive and plenty. Like in our case in Finland and Sweden. It does not take that much our of your pocket to pay the cell tax if the amount you start from is not large. (remember this when you fill in your tax forms, the "best way" to save in taxes is to earn less :-)
Cell-tax chart. POSIP ATM ether ip MAX POSIP SPE MAX cells ATM SPE size size POSIP goodput eff ATM per goodput eff (Bytes) (Bytes) pps (MB/sec) (%) pps packet (MB/sec) (%) ------ ------ ------- ---------- ---- ------- ---- ---------- ---- 64 46 353,207 16.2475 86.79 176,603 2 8.1237 43.39 128 110 160,000 17.6000 94.02 117,735 3 12.9509 69.18 256 238 76,408 18.1851 97.14 58,867 6 14.0103 74.84 512 494 37,365 18.4583 98.60 32,109 11 15.8618 84.73 1024 1006 18,479 18.5899 99.30 16,054 22 16.1503 86.27 1518 1500 12,422 18.6330 99.54 11,037 32 16.5555 88.44 (2048) 2030 9,189 18.6537 99.65 8,214 43 16.6744 89.07 (4352) 4334 4,312 18.6882 99.83 3,881 91 16.8202 89.85 (4488) 4470 4,181 18.6890 99.83 3,757 94 16.7938 89.71 Remember thaat long-haul bandwidth is a very scarse resource att the rate it will be consumed.
As the service deleiverd at the endpoint is IP, we need to interconnect the various parts of IP moving clouds, so we will have to have IP-switches (called routers) that go damn fast anyway.
Definetly we do. The problem here is that we're a generation away from routers that would go STM4. And maybe generation and half away from routers that would maintain fairness and maybe even QoS across them at the same time they go STM4 on a dozen interfaces.
Go read the latest issues of the trade-press like communications week.
So, explain what's the problem here, I just demostrated that you can run production IP traffic at 155Mbit without making a detour through an ATM switch.
Where the current POS pipe is, is a perfect place for 'ATM-less' circuit. When you say that you're going to do the next circuit locally, that makes me wonder of the benefits. If you would run the STM4 halfway across the globe, I would understand the benefits of being free of cell tax.
It will take until 1998 before there will be cablesystsems along the path that can give me a oc12c/stm-4, but we will have inside Sweden.
It has been more stable than any other international circiut we have, and the 'new' technology works great.
On which of the submarine cables it runs on, btw?
tat12/13, rioja, odin, denmark, se-dk-17. --Peter