Hi Gary,
Okay, I guess it's my turn.
Cisco has been doing cut through
switching in their routers for a while now.
Sounds like you're refering to Tag Switching. The word I heard about Tag Switching is it offers relative QoS, not absolute QoS. I believes it is still a connection-less protocol. More on this below.
Well, I think you may be wrong about IP's ability to prioritize and guarantee QoS.
There's been a lot of work in this area. But even if your not, I'm interested in why
you believe ATM can "guarantee" specific end to end latency. I agree that ATM
can guarantee jitter due to cells...but surely you're not saying ATM can guarantee
delay under network outages or congestion scenarios.... Yes, you can "tune" buffer
depths, and "throw away" packets, but retransmission will excerbate the problem.
This is where best effort is superior.
ATM is a connection-oriented protocol. Yes, it CAN guarantee delay in congestion scenarios. There is a connection admission control (CAC) procedure every time a new virtual connection is initiated, and if the connection is granted, then specific performance parameters must be honored for the life of that connection. If a new connection comes along and attempts to demand more resources than the switch has available, then that new connection is refused. If congestion were to occur in a network, only the lower-priority traffic (UBR) would be affected. Priority voice and VPN traffic (CBR, VBR-RT) will be untouched for a standards-compliant switch.
Furthermore, ATM has dedicated signaling channels, which further isolates an ATM network's performance and management from congestion. With RSVP, signaling is done with UDP or ICMP packets (I forget which), which in the event of congestion are vulnerable to being delayed or discarded.
Furthermore ATM
is not able to offer multiple prioritization for multiple types of IP traffic.
I believe you can map each type of IP traffic to an AAL layer in ATM. Yes, you have five AAL's to choose from.
The bottom line is ATM provides absolute QoS, while IP can only provide relative QoS (at a very expensive overhead cost). For large networks, the cost for IP-based QoS mechanisms is too high. Any way you cut it, ATM-based QoS is far more efficient and effective than RSVP.
DEN is nothing like RSVP - it's a server based mechanism where, upon sign on to
a network the server communicates with the network devices, assigns priorities,
access, and security - all based on the application the user is running. That is, a user
may have high priority for a video conference and a lower priority for email. When
he sets up his video conference the server commincates with the network, sets up
the best path, and assures priority/latency. This off-loads the routers from having to
do this work. If there is a network outage the routers still have the capability to
re-route the traffic...
I took the liberty to go to Cisco's web page and look up DEN. Yes, you are right it's a server-based application and one of its many features is managing QoS. DEN does not promise to be the silver bullet to solve QoS issues. DEN manages QoS, but does not deliver it. You first need a mechanism to deliver QoS--which will it be? RSVP? IP Precedence? CBQ? All of the above? Unfortunately, all of these have the weaknesses I've been talking about.
Interesting considering they haven't yet implemented a full RSVP based network
yet. ISP's aren't making money and can not afford to deploy perhaps.
This isn't what ISP's have told me. They specifically said RSVP would cause their networks to collapse. RSVP is currently available in the Cisco IOS, and can be turned on for a small licensing fee perhaps. But no one wants it.
ATM does NOTHING to protect
against packet loss. In fact it relies wholly on the IP device to manage this process
which is one of the ways ATM and FR reduce overhead..
The ATM VC will honor the contract under which it was set up. If a high priority is assigned to the VC (CBR or VBR-RT), then that contract will be honored and there will be no packet loss by the ATM router/switch, congestion or otherwise. With Packet-over-Sonet, a packet can be dropped or delayed by any of the intermediary routers along the network path, should that router become congested. RSVP can help at a heavy cost to non-priority traffic, but once again only relative priority can be assigned to a flow.
Gary, thanks again for your comments. I don't know if Ascend will knock of Cisco, but they're one of the few threats I see at this point. The other is NT, who are working real hard on some of the same technologies that Ascend is working on. Contrary to what you said, I'm not sure LU is as strong in ATM. I know they have been OEM-ing GDC's switch, which leads me to believe they have holes in their ATM lineup. But the Yuri acquisition was meant to take care of that.
Cisco is definitely king of networking now, but it's healthy to have a paranoia of your competitors. If I was Chambers, I'd be REAL worried about Ascend now. They are winning and stealing lots of contracts that he should have won. One day he may wake up and fine his 7500's & 12000's obsolete, replaced by a new generation of ATM router/switches.
bucky89**comes back with a stinging forehand to the front court** |
