
| |
Introduction This chapter tackles Asynchronous Transfer Mode (ATM). ATM is presented last, after the other network technologies, after bridging, routing and switching, after network design, because of its complexity. You will need the concepts from all of these topic areas in order to really make sense of ATM. ATM is what you get when the Telcos design a network technology by committee. It is a sprawling, dense technology. You will be forgiven if, halfway through this chapter, you think that you have been condemned to acronym hell. ATM is also intensely powerful. | |||||||||||||
| |
[ I ] ATM ATM has its origins in the desires of European and American telephone companies to develop a technology to carry voice, video, and data traffic over their networks. As such, ATM uses many of the concepts native to data networking, but frequently uses a different set of terms to refer to them. For instance, frames are not frames in ATM parlance. In ATM, a data frame is called a cell . We'll examine the ATM cell in detail later in this section. Normally at this point I would show where ATM fits into the OSI Reference Model. However, ATM presents a difficult match to the model. So, I think that it is more appropraite to discuss the mechanics of ATM first, and then present my thoughts on where ATM fits into the OSI model. ATM is a circuit-switched technology. The network technologies we have studied up to this point are packet switched : packets are handled by bridges and routers as individual units, with forwarding decisions made on a per-packet basis. Ethernet, Token-Ring and FDDI do not use the concept of creating a circuit from sender to receiver, and do not keep track of packets as being part of one particular conversation or another. ATM does both. Call Setup When a station on an ATM network wishes to transmit information to another ATM-attached station, the sending station signals the ATM switch it is attached to to setup a call from it to the intended recipient. The switch sets up a virtual channel connection (VCC) through itself (and any intermediate ATM switches) to the destination system. The VCC is made up of two or more VCs -- virtual channels -- setup from station to switch and switch to switch. The collection of VCs leading through the network from source to destination make up the VCC. VCCs are one way: they permit communication from sender to recipient. If the recipient wishes to respond, it must signal its ATM switch to set up a VCC from it back to the sender. At this point, when two VCCs are setup going in opposite directions, two-way communication can flow. The diagram below shows two stations with one VCC setup over an ATM network..
When the two stations above are done communicating they will signal their respective ATM switches to shut down the VCCs. In this fashion, ATM functions like the telephone system. It has call setup (the initial signaling from station to switch to setup a VCC) a conversation, and then call tear-down (the final signaling from station to switch to dissolve a VCC). VPCs and VCCs Setting up a VCC takes processor time and memory resources from the ATM stations and switches. Retaining information about the path which each VCC takes through the network from origin to destination would mean that ATM switches in a large, busy network would be holding a lot of redundant information. ATM uses the concept of the Virtual Path Connection (VPC) to streamline the process of managing the network path information for multiple VCCs. | |||||||||||||
|
Calling ATM 'circuit switched' is actually something of a misnomer. ATM is really a packet switching technology (a la Ethernet and Token Ring), but the real heavy lifting involved in routing ATM packets is done during VPC / VCC setup. Each ATM packet is still looked at individually by each ATM switch that handles it, but the processing load is very small because the switch is only matching each packet up with an existing VPC / VCC. |
When a station signals to set up a call (establishing a VCC) the ATM switch it is attached to first sets up a VPC from itself to the next ATM switch along the path to the destination end of the VCC. The switches along the route of the call hold information about the VPCs they have setup to each other. The VCC is set up next -- instead of having to retain path information about the VCC, the switches associate the VCC with the VPCs going from switch to switch. At this point, this seems like needless complication. However, a real benefit comes when another station attached to the ATM switch signals to setup a VCC to a destination where a VPC has already been created. If the VPC is already there, the work of setting up a path through the ATM network has already been done. The new VCC is simply identified as belonging to the existing VPC. Thus, multiple VCCs can be bundled together within a VPC, saving memory and processor resources within the ATM switches. The diagram below shows a network of ATM switches and the VPCs needed to carry a VCC from the originating station to the destination.
ATM Cells ATM's data frame is fifty-three bytes long. It is a fixed-size frame; the header is five bytes long, and the payload is forty-eight bytes. If the data being carried in the payload area isn't 48 bytes long, it will be padded to bring the frame up to 53 bytes. The ATM standards call this frame a cell, perhaps to emphasize the differences between ATM frames and Ethernet or Token Ring frames. Both Ethernet and Token Ring frames are variable length. Both frames are much larger -- Ethernet with a 1500 byte maximum, and Token Ring with a 4500 byte maximum size. ATM's cell has its small, fixed size due to its origins in the telcos; it has its particular size due to an intractable disagreement. The telephone companies wanted a very small cell size because small packets are better suited to carrying voice traffic. Voice traffic doesn't need a lot of bandwidth, but it does need consistent bandwidth. By mandating a small cell size you create an environment where a tiny voice packet won't get stuck waiting in a switch's transmit queue behind a huge data packet. That sort of waiting can cause gaps and pauses in the voice stream which would be very distracting to two people trying to hold a conversation. | |||||||||||||
|
When it comes to speed and efficiency, it can be said that the small cell size giveth, and all the headers taketh away. The full weight of this irreverance will become apparent when we get through AAL and LANE. |
Using a fixed-size cell removes a couple kinds of uncertainty from ATM device design. With an ATM cell being 53 bytes, no more, no less, then there is less guess work involved in determining how big buffers should be in an ATM switch. You can also build switching functions into hardware (to gain speed over implementing them in software) more easily when you know exactly how big each cell will be. A fixed cell size also aids in recovering synchronization when it has been lost. The switch knows that within every 53 bytes it receives there must be a cell header. This makes the task of picking out the cell header easier, and thus quickens the process of finding the boundaries between incoming cells. Which all translates into faster recovery from an error than would be possible with variable-length cells. The precise length of the payload area of the ATM cell -- 48 bytes -- is due to a disagreement between European and American telcos over the proper length. Both agreed on a 5 byte header, but the Americans wanted a 64 byte payload, and the Europeans wanted a 32 byte payload. The reason has to due with the expense of echo-cancellation hardware for long-distance telephone calls. American long-distance lines are long enough that this hardware is required all the time. So, the American telcos wanted to use a 64 byte payload to gain more efficiency (64 out of every 69 bytes being data). The Europeans have short enough long-distance lines that they don't need echo-cancellation hardware. The extra delays introduced by a 64 byte cell payload would add enough delay to the European phone networks to make them pay for adding echo-cancellation hardware. Thus, the Euros wanted a 32 byte cell. Neither side would budge, so the ATM Forum crafted a compromise which satisfied no one: they took the average of the two and set the cell payload at 48 bytes. "Nana-nana boo-boo". The table below shows the layout of two different ATM cell headers. The first cell header is used by ATM end stations to communicate with ATM switches, the second is used by ATM switches to talk to other ATM switches. User-Network Interface (UNI) Cell Header
Network-Network Interface (NNI) Cell Header
GFC - Generic Flow Control: [4 bits] This field is present in the UNI cell header to permit the ATM switch to send network congestion-related signals to the end station, permitting in-band control over the flow of cells coming into the ATM network from the end station. VPI - Virtual Path Identifier: [8/12 bits] The VPI field identifies which VPC the cell should travel down. NNI headers have 50% more room in the VPI field on the assumption that switches will have more active conversations to deal with than end stations. VCI - Virtual Channel Identifier: [16 bits] Like the VPI, the VCI indicates which VCC the is associated with. These two (VPI/VCI) permit an ATM switch to make a simple lookup upon receiving an ATM cell to determin what to do with the cell. EG: during call setup the switch builds a forwarding table entry which tells it that cells arriving on a certain interface with a VPI 3, VCI 210 should be forwarded out another interface with VPI 0, VCI 12 PT - Payload Type: [3 bits] The PT field is used to indicate whether the cell contains user data or network maintenace information, and whether or not the cell has experienced network congestion on its path from origin to destination. CLP - Cell Loss Priority: [1 bit] Like Frame Relay, ATM has a mechanism for indicating a preference for which cells to drop if the network should become congested. A cell with a CLP of 0 is treated as a higher priority cell. A cell with a CLP of 1 will be treated as a lower priority cell. Low priority cells will be dropped first by a switch if it experiences congestion. The CLP can be set either by the originating station (to indicate an intentional burst of traffic), or by the ATM switch the end station is connected to (to indicate a burst which that switch could handle, but which other switches might need to drop). HEC - Header Error Control: [8 bits] The HEC is an eight-bit CRC used to detect transmission errors in the ATM cell header. The HEC can be used by the receiving station to correct single bit errors in the header. If a single bit error cannot be corrected, or if the error is a multi-bit error, the cell is discarded. AAL - ATM Abstraction Layer | |||||||||||||
| |
[ II ] Routing IISP Interim I?? Switch Protocol PNNI Private Network-Network Interface | |||||||||||||
| |
[ III ] LANE | |||||||||||||
| |
[ IV ] CONCLUSION Isn't ATM just nifty? | |||||||||||||
| |
[ V ] SELF CHECK
| |||||||||||||
| |
2000 Shipman | Created 2-5-00 | Updated 2-5-00 |