My gosh Bucky...where do you get the time....
QoS...you're saying that no matter what happens in the network that CBR and VBR-rt circuits will provide absolute QoS. You need to go back and read your ATM manuals ...focus on the congestion areas.. Then let's talk again. At this point we're at a stale mate. ATM switches take time to re-route in the event of failure (either switch or trunk). QoS is compromised in these situations.
ATM VC's are static. If QoS needs to change then a new VC must be built. If the network fails a new VC must be built. There are no two ways around this one. BTW: congestion is a result of a line failure...or I should say it can be.
ATM does not need to rebuild connections in the event of congestion, but IP does.
IP is connectionless....no need to rebuild any connection.... ATM needs to rebuild connections for altered QoS purposes or if a VC is rerouted...as happens all the time in congested networks...even when there is no failure..
A topology change is not the same thing as congestion.
Well, in all due respect...if a trunk is congested and a second one is not a VC will be rerouted to take advantage of the bandwidth on the alternate path. This reroute requires a VC to be moved...torn down and rebuilt. Therefore to the VC congestion might as well be a topology change..
IP uses dynamic routing protocols like OSPF, RIP, etc... Their chief advantage is they are a somewhat scalable way of managing large numbers of very large routing tables, and can dynamically adjust themselves to changes in network usage and topology. On the other hand, this is a disadvantage for QoS. A router path may traverse five routers one second, and then 20 routers the next in the event of congestion. Latency cannot be guaranteed in an environment where the routes are dynamically changing.
See IP switching publications and discussion... then lets catch up. I don't want to waste anymore time on this. Your knowledge is very good although it think it may be dated a year or so. TAG, Netflow, IP Switching, etc.. have solved this problem. Couple DEN with this and the "routing" overhead is almost completely eliminated while also maintaining the integrity and flexibility of the routed environment.
ATM uses PNNI which is a static source routing protocol. The initiating switch, if the CAC is successful, knows how many nodes, CTD between nodes, etc... and can determine absolutely what the latency time will be for priority AAL's (CBR, VBR-RT). The path for the VC does not change unless the topology changes. ATM's advantage is that congestion and other changes in network usage will not affect performance of VC's carrying priority traffic.
Well, although I might disagree on a couple of point here I agree with you fundamentally. But these are reasons why ATM is an excellent transport technology. It's rigidness however make it less adaptable to the network edge. Couple the speed, efficiency, and resiliency of an ATM backbone with the flexbility, and dynamicism of an IP edge and you have the makings of an excellent network. The IP edge must be capable of prioritization and packet idenitification for either local routing purposes or for communication with the ATM backbone.
RSVP could work if it were somehow scalable.
You keep saying this, but have not provided your basis for this other than ISP's say it isn't. Well, ISP's aren't that bright... no one really know what RSVP can and can not do yet.
Yes, it has CAC, but it only provides relative, not absolute QoS because you never know which nodes it will claim for a particular path.
Check DEN.
If the network is congested at the particular instant CAC is initiated, then you could end up with a very non-optimal path for the RSVP. But its chief disadvantage is scalability and the additional processing burden it places on routers.
Check DEN. DEN handles this..no extra processing required.
Everyone, especially all the ISP's, are complaining that routers are too slow. How much slower will they get when burdened with RSVP?
It's not the routers, it's the servers... they blame the routers ...true...but it's the servers that are slow... Take a look at the PPS on the GSR and the new 8500.
Mulicast. IP supports bidirectional many to many transmissions. ATM supports unidirectional point to multipoint. This means that there will be a lot of additional ATM VC's required to emuliate the IP mulicast model.
I admit this is one weakness of ATM, but there are workarounds.
Thanks for admiting. Workarounds are sub-optimal and require VC's up the yahoo...
Heterogeneity. Receivers in the ISA model can requirest and receive different levels of QoS. ATM VC's are a single QoS. ISA receivers can also renegotiate QoS levels during a connection. ATM currently requires that a new VC with a different QoS be established.
What more do you need? Five levels of QoS have been carefully spec'ed out by the standards forum, and they appear to be adequate to cover all possible types of traffic. On the other hand, saddling routers with all these different kinds of QoS leaves them with a single QoS too--very slow QoS.
you missed the point... If you have an originating point that requires 5 levels of QoS (assuming I buy in that 5 is enough), then you require 5 VC's...since only one QoS attribute can be supported on a given VC. Anyway, watch what the standards bodies do to thier carefully crafted 5 levels of QoS. Watch for either sub-levels or additional AAL's. IP using DEN can define a discrete QoS attribute for any kind of application...
Result...ATM is very rigid and therefore not as well adaptable to network edges where flexbility is required. It however is an excellent transport architecture.
I agree here. Routers will not become obsolete by any means. But unless Cisco can think of something quick, routers may become extinct in the core of large networks.
Hmmmmm, I'm not certain that Cisco has designs on placing routers in the "core" proper of service provider networks. That's why they bought StrataCom. They understand the need for ATM. However, they are indeed behind ASND on their development and launch.
OG |
