|
|
This chapter describes the Asynchronous Transfer Mode (ATM) technology on which the LightStream 2020 multiservice ATM switch (LS2020 switch) is based. ATM is a communications standard based on cell relay techniques. The next sections discuss cell relay and ATM technology. They also contrast ATM techniques with time-division multiplexing (TDM) and other packet-handling technologies.
Cell relay is a flexible and responsive method for multiplexing all forms of digital traffic (data, voice, image, and video). Cell relay can handle rapid changes in the quantity and pattern of the traffic in the network. All traffic is placed in fixed-length packets of information (cells) and switched at high speeds. Cell relay is generally acknowledged as the best multiplexing technology for modern communication applications because it combines the strengths of TDM and conventional packet switching. Using cell relay packet-handling techniques, a mixture of bursty and delay-sensitive traffic can be processed simultaneously, while at the same time providing the services required by each traffic type.
Also, because cell relay processing is based on the use of small packets, the process technology is adaptable and cost-effective for a wide range of interface speeds.
ATM technology first appeared in the Broadband Integrated Services Digital Network (BISDN). However, ATM is now recognized as a useful technology in and of itself and is based on the specifications and standards being developed by ITU-T (International Telecommunications Union Telecommunication Standardization Sector), ANSI (American National Standards Institute), and the ATM Forum.
Each ATM cell contains a header and the data to be transferred. Cells are switched in the network based on routing information contained in the cell headers. ATM transports all types of traffic (data, voice, image, and video) using the same cell format.
ATM contrasts with TDM in the way it allocates communications channels. In TDM, communications channels are divided into fixed periods of time called frames. The frames are divided into a fixed number of time slots of equal duration (see Figure 21-1). Each user is assigned certain time slots within each frame. As Figure 21-1 indicates, a user can be given more than one time slot in a frame.
The time slots allocated for each user occur at precisely the same time in every frame. Because the time slots are synchronous, TDM is sometimes referred to as synchronous transfer mode (STM).
In other packet-handling technologies, such as High-Level Data Link Control (HDLC), any user can gain access to the communications channel, but a user who has a long message to send can prevent other users from gaining access to the channel until the entire message has been passed. However, with ATM, every message is divided into small, fixed-length cells. Thus, no single user can monopolize access to the communications channel while other users have messages to send (see Figure 21-2).
ATM standards define protocols that operate at Layer 2 (the data link layer) of the International Organization for Standardization (ISO) seven-layer Open Systems Interconnection (OSI) reference model. Figure 21-3 shows the layered architecture of the OSI model.
The data link layer may divide higher-level data into smaller units (cells, in this case), whose sizes are compatible with overall network requirements. Layer 2 data units contain a cell header, an information field, and some method of checking for transmission errors.
Before frames can be transported across an ATM network, they must be divided into ATM cells. The processes that divide the frames into cells occur at Layer 2. Layer 2 is divided into two parts: the ATM adaptation layer (AAL) and the ATM layer. After frames are divided into ATM cells, the cells can be transferred to Layer 1 (see Figure 21-4).
ATM uses label switching, a technique in which a simple label is placed in the header of each cell. The label provides information used in transporting the cell across the next hop in the network. Networks that do not use label switching usually require each packet (or cell) to contain the explicit address of the final destination. ATM uses label switching because it is simpler, thereby making faster switching possible.
Here is how label switching works:
1. A switching unit reads an incoming cell from a particular port. The incoming cell has a routing label.
2. The switching unit uses the combination of the input port on which the cell was received and the information in the label to determine where the cell should go next. It does this by referring to a routing table that correlates the incoming port and label with an outgoing port and label.
3. The switch replaces the incoming label with a new outgoing label and sends the cell through the outgoing port, which is connected to another switching device. (The new outgoing label is taken from the routing table.)
4. This process is repeated until the cell reaches its final destination in the ATM network.
For example, suppose your network includes a switching unit called Boston. A number of data paths go through the Boston switch. When those data paths are created, a routing table is set up within the Boston switch. The table in the Boston switch has one entry for each data path that goes through the switch. The entries in the table map the incoming port and label to an outgoing port and label for each data path, as shown in Table 21-1 .
| Port In | Label In | Port Out | Label Out |
1 | L | 6 | Z |
1 | M | 7 | X |
2 | N | 7 | Y |
When the Boston switch receives an incoming cell on port 1 with label M, it consults the routing table and finds that label M should be replaced with label X and that the cell should be passed out of the Boston switch on port 7. The cell is then transported to the switch in the network that is connected to port 7 of the Boston switch, as shown in Figure 21-5.
In all cases, transporting cells through the use of label switching requires a connection. Information about the connections is provided in the routing tables (sometimes called lookup tables) of switching and multiplexing units. ATM uses virtual channel connections and virtual paths to accomplish routing functions.
A virtual channel connection (VCC) is a series of virtual channel links (VCLs) between two ATM points. A VCL is a means of bidirectional transport of ATM cells between a point where a virtual channel identifier (VCI) value is assigned and the point where the same value is either reassigned or terminated. The VCI identifies the VCL to which a cell belongs and determines where the cell should go next. Figure 21-6 shows the relationship between VCLs and VCCs in an ATM network.
VCCs are sometimes transported within virtual paths (VPs). A VP is identified by its virtual path identifier (VPI). VPs provide a convenient way of bundling traffic directed to the same destination or traffic requiring the same Quality of Service (QoS) in the network (see Figure 21-7).
Every ATM cell is 53 bytes long. The first 5 bytes contain header information, and the remaining 48 bytes contain the payload (see Figure 21-8).
The 5-byte header (see Figure 21-9) contains several different fields (see Table 21-2). The 48 bytes following the header (the payload) contain user data.
| Header Field Name | Location in Header | Description |
GFC1 | First 4 bits of | Controls the flow of traffic across the user network interface and thus into the ATM network. |
VPI2 | Second 4 bits of Byte 1 and the first 4 bits of | Identifies a particular VPC3. A VPC is a group of virtual connections carried between two points and may involve several ATM links. VPIs provide a way to bundle traffic heading to the same destination. |
VCI4 | Second 4 bits of Byte 2, Byte 3, and the first 4 bits of Byte 4 | Identifies a particular VCC5. A VCC is a connection between two active, communicating ATM entities. The VCI consists of a concatenation of several ATM links. |
PT6 | The fifth, sixth, and seventh bits of Byte 4 | Indicates the type of information in the payload field. ATM cells carry different types of information that may require different handling by the network or terminating equipment. |
CLP7 | The eighth bit of | Indicates the cell loss priority set by the user. This bit indicates the eligibility of the cell for discard by the network under congested conditions. If the bit is set to 1, the cell may be discarded by the network if congestion occurs. |
HEC8 | Byte 5 | Contains an error-correcting code calculated across the previous four bytes of the header. The HEC detects multiple-bit header errors and can be used to correct single-bit errors. The HEC provides protection against incorrect delivery of messages caused by address errors. The HEC does not provide any protection for the payload field itself. |
The AAL accepts frames from higher OSI layers and adapts them to the 48-byte segments that are placed into the Payload field of ATM cells. The ATM layer accepts the 48-byte segments, adds the 5-byte header, and produces ATM cells to be transferred to the physical layer, as illustrated in Figure 21-10.
When ATM cells are transferred through a network, each cell is processed in isolation from all other cells. All processing decisions are made based on the cell header; no processing of the data in the payload field occurs.
Figure 21-11 shows some examples of AAL processing.
Hosts A and C are connected to the network through ATM interfaces, so they do all their AAL processing internally. The network does not do any processing for hosts A and C. Hosts B and D are connected to native Ethernet interfaces on Nodes 1 and 2. Therefore, Node 2 does all the AAL processing for Host D. Node 3 does no AAL processing.
Depending on the type of traffic entering the ATM network, the AAL uses one of four different AAL types to divide the traffic into small segments. These types are classified according to the timing -relationship between the source and destination, the constant or variable bit rate, and the mode (connection-oriented or connectionless). The AAL types defined in the ATM standard are listed in Table 21-3 .
| AAL Type | Examples of Traffic Type |
1 | |
2 | Variable bit rate video and audio |
3/4 | Connection-oriented or connectionless data transfer (AAL 3/4 has cell-by-cell error checking and multiplexing) |
5 | Connectionless data transfer (AAL 5 has lower overhead than AAL 3/4) |
The AAL is divided into two sublayers: the convergence sublayer (CS) and the segmentation and reassembly sublayer (SAR; see Figure 21-12).
The convergence sublayer (CS) accepts higher-layer traffic for transmission across the network. Depending on the AAL type, header and/or trailer fields are added to the packet. The packet is then segmented by the SAR sublayer to form 48-byte payloads (also known collectively as SAR-PDUs).
Upon receipt of cell payloads, the AAL removes any AAL-specific information from each payload and reassembles the entire packet before passing it to a higher layer (see Figure 21-13).
The ATM layer accepts the 48-byte SAR-PDUs from the SAR process, adds a 5-byte header to each, and produces ATM cells for transfer to the physical layer (see Figure 21-14).
Each PMD is specific to a particular physical medium and includes definitions of proper cabling as well as bit timing. The TC sublayer generates and receives transmission frames and performs all overhead functions associated with the transmission frame. The TC sublayer performs a convergence function by receiving a bit stream from the PMD and extracting cells.
Although PMD operation depends on the physical medium, the following TC functions remain common to all physical layers:
This section presents troubleshooting information for connectivity and performance problems in ATM switching environments. The chapter begins with general information about checking ports, performing loopback tests, and using the ping command on a LightStream 2020 ATM switch.
The remaining sections describe specific ATM switching symptoms, the problems that are likely to cause each symptom, and the solutions to those problems.
The following steps outline the procedure for performing basic port checks. It is important to perform basic port checks to verify that a LightStream 2020 port is enabled and functioning correctly:
Step 1 Use the show port port-number all command to display information about a port.
Step 2 Check the Admin Status field to make sure that the port is up.
Step 3 Check for excessive line errors, packet drops, or a lack of receive data. If there is no receive data or if the error rate on the receive data is excessive, check the hardware, cabling, and other physical layer components.
For more information on troubleshooting hardware, refer to "Troubleshooting Hardware and Booting Problems."
Step 4 If the port is directly connected to a host, ensure that one side of the connection is configured as data communications equipment (DCE) and the other side is configured as data circuit-terminating equipment (DTE).
If two ports are connected through a channel service unit (CSU), ensure that the ports on both sides of the connection are configured as DTE.
Step 5 If you are working with a low-speed line card (LSC) port, check the bit rate. Refer to the section "Checking Bit Rates" later in this chapter.
Step 6 If you are working with a medium-speed line card (MSC) port, check for mismatches in port configuration attributes such as cell payload scrambling, line type, and cable length.
Step 1 Use the show port port-number all command to display information about a port.
characteristics {dce-bitrate Kbits | dte-bitrate bits}
Set the DCE or DTE bit rate for the specified port, depending on the dce-dte-type value described below. The value of Kbits for the DCE bit rate may be 56, 64, 128, 192, 256, 384, 448, 512, 768, 896, 1344, 1536, 1792, 2688, 3584, 4000, or 5376. The value of bits for the DTE bit rate is unrestricted in the range of decimal integers 9,000---6,000,000.
Step 3 Compare the Measured Bit Rate with the Admin DCE Rcv Bit Rate field. If the value shown in the Measured Bit Rate field is significantly different from that shown in the Admin DCE Rcv Bit Rate field, a problem exists.
Step 4 If the port is DCE, it provides the clocking function. Make sure that the cabling is correct and that the configured bit rate is valid. If an attempt is made to activate the port when an invalid bit rate is configured, problems will occur. The value of Kbits for the DCE bit rate may be 56, 64, 128, 192, 256, 384, 448, 512, 768, 896, 1344, 1536, 1792, 2688, 3584, 4000, or 5376.
Step 5 If the port is DTE, it uses the clock supplied by the attached device (such as a CSU/DSU or a router). If the correct clock is not being detected, make sure that the correct cable type is used to connect the port to the attached device and that the attached device is providing a clock function.
Loopback tests can help you pinpoint faults by looping a signal at various points in the network. The LightStream 2020 ATM switch provides the following two types of loopback tests:
This procedure outlines the steps for looping data through a trunk, the physical and logical connections between two LightStream 2020 trunk ports. If you know that data is not passing on a trunk between two trunk ports, follow these steps to set up a remote loop on one of the trunk ports:
Step 1 Enter the set port port-number loop remote command. The port is set to testing mode and the loopback test begins automatically.
Step 2 If the remote loop succeeds, the trunk port comes up at the remote end. If the local port displays an operational status of down during the loopback test, there is probably a problem with the local port. Proceed to Step 3.
If the remote loop fails and the trunk does not come up, then a problem exists somewhere between the local access card and the remote system.
Step 3 To run an internal loop on the port, enter the set port port-number loop internal command. The port is set to testing mode and the loopback test begins automatically.
Step 4 If the internal loop succeeds and the local trunk comes up, the problem is the local access card.
Step 5 To stop the loopback test, enter the set port port-number unloop command.
This procedure outlines the steps for looping data through an edge port. The line from the port connects a LightStream 2020 ATM switch to a third-party external device. If you suspect that data is not passing between the LightStream 2020 edge port and the host, or that the line is unreliable, use this looping procedure to isolate the problem:
Step 1 If the port is a Frame Relay User-Network Interface (UNI) port, enter the set port port-number framerelay netinterfacetype nni command to set the netinterfacetype attribute to Network-to-Network Interface (NNI).
Internal loopback tests do not work on Frame Relay ports with the Local Management Interface (LMI) type set to UNI.
Step 2 Run a remote loop on the LightStream 2020 edge port by entering the set port port-number loop remote command. The port is set to testing mode and the loopback test begins automatically.
Step 3 If the internal loop fails and the line does not come up, the problem is in the line or access card.
Step 4 To stop the loopback test, enter the set port port-number unloop command.
Step 5 If you changed a Frame Relay UNI port to NNI for the loopback test, reset the port to the UNI network interface type by entering the set port port-number framerelay netinterfacetype uni command.
The following steps describe how to perform a ping test from a LightStream 2020 ATM switch:
Step 1 Log in as root on the LightStream 2020 switch from which you want to send ICMP echo packets.
Step 2 Enter the ping [packet-size] hostname command (where packet-size is the size of the packets to send and hostname is the name or IP address of the host). The packet size argument is optional. The default packet size is 64 bytes.
Step 3 To stop the ping and display a summary of the results, press ^C.
Symptom: An ATM trunk does not come up properly and connections cannot be made.
Table 21-4 outlines the problems that might cause this symptom and describes solutions to those problems.
| Possible Problem | Solution |
|---|---|
Card not configured as a trunk card | Step 1 Check the port at each end of the trunk with the show port port-number statistics command. Make sure that both ports are periodically sending cells. Step 2 Check the Octets Sent field to verify that it is incrementing. Step 3 If one port never sends trunk-up-down messages, make sure the card is correctly configured as a trunk card. Step 4 Make sure that a trunk is configured on port 0. The trunk can be configured as inactive if desired. Step 5 If both sides of the trunk show that they are sending cells, find out which side is not receiving cells. Perform a basic port check as described in the section "Basic Port Checks" earlier in this chapter. |
Make sure that the line type parameter (dsx3Linetype) is correctly configured. Check with your carrier for the correct line type for your connection. Use the show port physical command to display the line type as well as the following information:
| |
Framing type mismatch | Step 1 Check to see whether both ends of the trunk are configured to use the same framing type (PLCP, HEC, or G.804). Enter the show port command. If there is a mismatch, the display for both ports will indicate "DS3 other failure." Step 2 Change the framing type on one of the ports, as appropriate, using the set port c.p characteristics framing type {plcp | t3-hec | q-804} command. |
Cell payload scrambling mismatch |
Step 1 Check to see whether one end of a trunk has cell payload scrambling enabled and the other end has cell payload scrambling disabled. Use the show port c.p physical command to verify the status of the payload scrambling. Step 2 Reconfigure the trunk ports using the set port c.p characteristics cell-scrambling {enable | disable} command so that cell payload scrambling is either enabled or disabled on both ends of the trunk. |
Telephone company network problem | Isolate the problem by running the loopback tests described in the section "Performing Loopback Tests" earlier in this chapter. If you determine that the problem is occurring in the telephone company network, contact your carrier to solve the problem. |
Hardware or cabling problem | Step 1 Check all cabling and connections to make sure there are no worn cables or loose connections. Step 2 Make sure that cable lengths are within specification and that the cable length port attribute is properly configured. Use the set port c.p characteristics cable len length command to change the cable length attribute. Step 3 Check all hardware for problems. For more information on troubleshooting hardware, refer to "Troubleshooting Hardware and Booting Problems." |
Table 21-5 outlines the problems that might cause this symptom and describes solutions to those problems.
| Possible Problem | Solution |
|---|---|
Step 1 Use the show port port-number all command to see whether the Normal Packets Received counter is incrementing. A packet should be received every 10 seconds from the Frame Relay host. Step 2 If the counter is not incrementing, check the Discarded Received Packets statistic. If the Discarded Received Packets entry is incrementing, the packets are coming in but on a different DLCI2. This occurs when there is an LMI type mismatch. Step 3 Make sure that both the Frame Relay port and the Frame Relay host are configured to use the same LMI protocol (FRIF, ANSI T1 617D, or Q933A). Use the show port c.p framerelay command to check the LightStream 2020 port. For information on checking and configuring the LMI type on the Frame Relay host, refer to the vendor documentation. Step 4 Change the LMI type on the port using the set port c.p framerelay lmiconfig {none | frif | ansi_t1_617d | q933a} command and see whether the port becomes active. If the LMI does not come up, make sure that packets are being received on the LMI DLCI. The FRIF LMI uses DLCI 1023. The ANSI and Q933A LMIs use DLCI 0. | |
Port protocol incorrect | Step 1 Use the show port c.p framerelay command to make sure that the LightStream 2020 port is correctly configured as a UNI3 port or an NNI4 port. In general, ports should be configured to use the UNI protocol. The NNI protocol is designed for network device-to-network device connection and is rarely used. Step 2 If the port protocol is incorrect, use the set port port-number framerelay netinterfacetype {nni | uni} command to reconfigure it. |
DLCI is not activated | Step 1 Use the show port c.p listdlci command to see whether the Frame Relay DLCI is deactivated. The output will show an uppercase I in front of the DLCI entry if it has been manually deactivated. Step 2 If the DLCI is deactivated, use the set port port-number dlci dlci-number activate command to activate the DLCI. |
| 1LMI = Local Management Interface 2DLCI = Data Link Connection Identifier 3UNI = User-Network Interface 4NNI = Network-to-Network Interface |
Symptom: A Frame Relay, frame forwarding, UNI, or constant bit rate (CBR) virtual circuit fails to be created.
Table 21-6 outlines the problems that might cause this symptom and describes solutions to those problems.
| Possible Problem | Solution |
|---|---|
Virtual circuit not configured on both endpoints | Step 1 Use the show port command to verify that the virtual circuit is configured on both endpoints. The virtual circuit must be configured on both endpoints for the circuit to be created. Step 2 If one endpoint does not have the virtual circuit configured, reconfigure the endpoint. For each virtual circuit you must specify the node, card, and port at each end and the required bandwidth. For detailed information on configuring virtual circuits, refer to the LightStream 2020 Configuration Guide. |
Port in inactive mode | Step 1 Check to see whether the virtual circuit is configured on an inactive port. Use the show port command to check the status of the port. Step 2 If the port is in inactive or testing mode, bring the port up using the set port port-number active command. |
cardMaxVCs attribute set too low | If the cardMaxVCs attribute is set too low on a line card, there might be insufficient resources available for creating a virtual circuit. Increase the value of this attribute and reboot the line card. The following switchwide attribute may be configured only in expert mode in the configuration tool:
|
If the virtual circuit has illegal attributes set, the circuit will not be created. Review the bandwidth values in particular. Use the following commands to review the settings:
Refer to the LightStream 2020 Configuration Guide for more information. | |
Not enough bandwidth | Step 1 If there is not enough bandwidth available to support the virtual circuit, the circuit cannot be created. Check the cells available attribute to determine how much bandwidth is available (that is, how much has not been allocated to other virtual circuits). Use the show port c.p all command to display all port attributes (name, status, statistics, physical, frameforward, framerelay, DLCI, VCI, PVC, VPI). This is the default, with show port c.p followed by no arguments. Step 2 Check the cells required attribute to see how many cells of bandwidth are needed to carry the virtual circuit over a trunk. Use the show port c.p vci VCI# command to display, for the specified ATM UNI port, the following attributes of the PVC with the specified VCI:
|
Trunk down | Make sure that any trunks in the path between the endpoints are active. For more information, see the section "ATM Switching: Trunk Does Not Come Up" earlier in this chapter. |
| 1PVC = permanent virtual circuit 2VCI = virtual channel identifier 3CLC = cell line card |
Symptom: Partial data is delivered over a Frame Relay, frame forwarding, UNI, or CBR virtual -circuit.
Table 21-7 outlines the problems that might cause this symptom and describes solutions to those problems.
| Possible Problem | Solution |
|---|---|
Network congestion | Check whether the network is congested. Check your traffic management configuration and make adjustments as appropriate. Use the show chassis congestion command to display the maximum and minimum intervals between permit limit updates and the minimum interval between CA updates. For detailed information, refer to the LightStream 2020 System Overview. |
Target depth and maximum depth parameters misconfigured (CBR1 only) | Use the set port c.p cbrpvc PVC# {targetdepth | maxdepth} bytes command to control the reassembly buffer at the point where input cells are converted back into a CBR stream. An adaptive control loop maintains data in the buffer close to the level specified by targetdepth bytes. Data in excess of maxdepth bytes is discarded. The default values of the targetdepth and maxdepth attributes are usually best left unchanged. If the target depth is set too high or if the maximum depth is set too far above the target, end-to-end delay for the entire circuit increases. With voice traffic, such delay can cause annoying echo. If the target depth is set too low or if the maximum depth is set too close to the target depth, random CDV2 may cause the circuit to overflow or underflow sporadically, causing data errors and reframe events for equipment downstream. For certain applications, such as video and phone, where some discarding of overflow data is an acceptable cost of maintaining a constant bit rate, it may be preferable to set these two parameters closer together. |
| 1CBR = constant bit rate 2CDV = cell delay variation |
Posted: Tue May 16 15:15:26 PDT 2000
Copyright 1989 - 2000©Cisco Systems Inc.