Some of my frustrations with ATM are mainly due to it's deployment way before it should have seen a live user packet. I believe wholeheartedly that what ATM has to offer will soon offset it's deployment headaches due to lack of standards and acceptance among the primary WAN vendors.
IMO ATM is still at a point where it would be considered cost prohibitive for a large business to deploy a private enterprise ATM network utilizing a core ATM switching fabric for the transport. And then bear the additional costs of installing your PBX equipment (or other phone switch), and the required data components of core/branch routers. I can't wait till that day comes though (job security<VBG>).
ATM is always connection oriented.
Under your definition of connection-oriented that is the case. A VC is connection oriented. BTW for other readers Gary's definition is standard ATM nomenclature. My comparisons are at the user session level, in which connection definition (reliability...another definition...not to be taken literally) is established by the reliablilty of the session incorporating flow control, ACK, NAK, in order to maintain the integrety of said connection between hosts. Again, under these guidlines UDP/IP (or IP) is connectionless, where TCP/IP is connection oriented.
That is before information is transferred from the terminal into the network, a logical/virtual connection set-up phase must first allow the network to do the reservation of the necessary resources, if they are available. If no sufficient resources are available the connection is refused to the requesting terminal (as may happen with UBR traffic).
The question of sufficient resources:
You have just described one of ATM's current weaknesses that hopefully will be resolved sooner than later. The current standards described by P-NNI1.0's GCAC (General Connection Admission Control) is still very much vendor specific. Many of the QoS tests that where intended for PNNI1.0 have been put off until the release of I-PNNI1.0 and PNNI2.0. What PNNI does is find the best resourses (SONNET/ISDN, or other transport media) for the setup of the required QoS connection as demanded for each VC. The notion of GCAC allows PNNI to create an ATM VC by starting at the requestor's ATM switch (the switch where the source of the VC is) and bounce from switch to switch (not randomly, but selecting the best ones utilizing the tierd routed hiarchy offered with ATM), testing switch CPU and bandwidth/latency/cell-loss-ratio (Some of the attributes of QoS) creating a path for the VC along the way. Should one of the switches not have the resources to accomidate the new VC, "crankback" is initiated and another path is chosen off the previous switch until a suitable path is found to complete the VC.
This "connection-oriented" mode of operation allows the network to guarantee in all cases a minimal cell loss ratio and thus maximal quality.
Actually it establishes a level of service known as MCLR (Maximum Cell Loss Ratio), an atribute of QoS. This is not a garrentee that cell loss will not occur. As long as the actual cell loss is maintained within the limits established in MCLR will the connection be maintained. Losses do occur. The frequecy is dependent on the QoS and outside variables such as transport quality and hardware integrety.
Every "call set-up" checks whether statistically enough resources are available. Ths assures that it can be guaranteed resources will be available and queue overflow will only occur with a very low probability. The probability of overflow can be dimensioned by gueuing theory. Tyipcal values are between 10 -8 and 10 -12 as far as the probability of losing a packet.
I agree. I can't speak to the statistics of having cell loss occur, but I can say given the statistics given above that during a a 60 minute period a network node could see a lost packet a dozen or so times in any given hour on a 10Mbps access port. That is where the importance of reliable applications come into play that truely do garrentee any IP window is resent that would have a corrupted packet (due to cell loss). FTP is a TCP (connection oriented) application that would work. TFTP is an application that would ignore (it is connectionless UDP) the error and include the distorted data in the transfered file.
Note that IP is connectionless.... That is there is no estabilshment of a connection. If resources are not available...well..tough. You lose the packet.
IP by itself is, but when the application is TCP (FTP is a TCP/IP application), the connection orriented session can navigate line errors, etc. and garrentee information transfer under most conditions. If conditions become to severe, the session terminates, and must be re-initiated.
Regards, Paul |
