The great WAN way

When testing any type of WAN system, carrier technicians run into two major problems: "I can't connect to...." That's the connectivity problem. And "the @#$! network is so slow!" That's the performance problem.

Whether carriers are dealing with frame relay, asynchronous transfer mode or more advanced packet-over-Sonet technology, they can easily fix these problems given the right tools and know-how. They can use two methods for testing and troubleshooting:

* The passive method, in which a technician only analyzes the traffic on a line.

* The proactive method, in which a technician replaces one end with a known objective device that can emulate the specific network facilities under test.

The complexity of WAN systems such as ATM and packet over Sonet makes testing a crucial part of these networks' life cycles. The modern network professional needs a good protocol analyzer in the toolbox-one that can monitor in real time, generate traffic and emulate network entities. A physical layer tester is just not enough.

Testing frame relay Frame relay uses variable length frames to transfer data or voice between LANs. Because frame relay is a connection-oriented technology, a carrier must set up a connection between two users before they can exchange information. The connection can be a permanent virtual circuit (PVC) or a switched virtual circuit (SVC). The circuit is identified by a data link connection identifier (DLCI) that is locally significant, as shown in Figure 1. The same pipe can transfer payloads from different users on different virtual circuits, thus making sharing resources possible.

Frame relay uses the concept of flexible bandwidth allocation. The user may forward frames to the network at variable rates, up to an agreed upon maximum, otherwise known as the committed information rate (CIR). The implications of variable bandwidth are important because the demand on the network may exceed capacity. When that happens, the network is congested and frames are lost. It is thus very important for a service provider to verify that its frame relay network is not congested too often. The absence of data link layer flow control prevents the frame relay network from directly controlling data transmission rates. The user is responsible for reducing traffic generation in response to notification from the network. The higher layers such as TCP/IP take care of these issues.

Unlike traditional X.25 or leased line networks, in frame relay the terminal equipment is smart and the network is dumb. When the network receives a frame, it verifies the validity of the data frame and the conformance with the established traffic contract. If either of these checks fails, the frame is discarded. The terminal equipment is responsible for detecting and responding to this data loss. This is why network viability is paramount. If a frame relay switch receives more traffic than it can accommodate, it will discard frames without notification to clear this congestion.

When installing and configuring a frame relay network, it is crucial to make sure both sides of every link use the same link management interface variant. The link management interface variant is usually automatically configured to match the two ends, but sometimes the service provider needs to configure it manually to match. Discovering such a connectivity problem is very easy with a protocol analyzer. The symptom of the problem takes the form of a link that doesn't show up, and the analyzer will show that each side is using a different variant or DLCI for the link management interface messages.

It is important to check the CIR on a working frame relay link. If a user exceeds the CIR, frames very likely will be discarded. From a service provider's point of view, it is important to provision a big enough network so that congestion seldom occurs. The traffic on the network should be monitored periodically to make sure that all users get enough bandwidth and frames are not discarded.

For example, a frame relay link with a CIR of 256 kb/s is set between two LANs. The link includes the Ethernet shared environment on both ends, two frame relay routers and the frame relay link. This is exemplified by the link between New York and Chicago in Figure 1. The level of frame relay services received from the carrier does not satisfy the customer. Therefore, the customer asks the service provider to increase the CIR to 512 kb/s. The response of the link does not seem to improve even though the CIR was doubled.

Both the customer and the service provider are puzzled at this. But when technicians use a protocol analyzer to look at the Ethernet and frame relay sides of a router simultaneously, they finally realize what the problem is: The Ethernet shared network is so congested that the rate of frames that are reaching the frame relay link is very low. Changing the configuration of the shared network by dividing it into two subnets fixes the problem immediately. Another solution would be to upgrade the 10 Mb/s Ethernet to a 100 Mb/s Ethernet.

Testing ATM ATM can support both local and wide area network applications. It is a connection-oriented technology and, like frame relay, it uses PVCs or SVCs. It also features flexible bandwidth.

Unlike frame relay, however, ATM uses fixed-length "cells" that are reassembled into variable length packets. The ATM cell has a fixed size of 53 bytes, five of which are used as a header and 48 that are used for payload. The header of every cell carries identifiers that specify the path and the circuit. The payload holds the data itself. ATM's fixed cell architecture makes the hardware implementation easy and fast, and it can handle far more simultaneous connections than frame relay can.

One of the biggest advantages of ATM is the integrated quality of service (QOS) that allows the network to guarantee a specific traffic agreement for different connections simultaneously on the same pipe. ATM shines in an environment where multiple streams are multiplexed into Sonet frames or where multiple types of service are provided such as voice, video and data. ATM provides the best flexibility and robustness in these cases.

Testing for connectivity in ATM includes verifying that all the cells transmitted by user A reach user B in the right order. This is measured by various parameters, including:

* Cell loss and cell loss ratio: the difference between the number of transmitted and received test cells.

* Cell sequence integrity: identifies out-of-sequence cells by comparing sequence numbers of received and transmitted test cells.

* Cell error and cell error ratio: the number of received test cells with payload bit errors vs. the number of transmitted test cells.

* Cell misinsertion and cell misinsertion rate: the number of cells on one virtual circuit with payload information belonging to another virtual circuit.

Testing ATM performance also includes verifying conformance to a QOS agreement by measuring the following parameters:

* Minimum cell transfer delay: minimum round-trip delay of test cells.

* Mean cell transfer delay: average cell transfer delay.

* Jitter: the standard deviation of the cell transfer delay.

* Cell delay variation: the difference between maximum and minimum cell transfer delay.

* Peak cell rate: maximum cell rate.

* Sustainable cell rate: nominal cell transfer rate.

* Maximum burst size: number of adjacent cells that were transmitted at the peak cell rate.

Higher protocol layer problems might occur as well. As an example, take this real-world problem of slow TCP performance over a high-speed ATM network. A service provider installs an ATM link between two switches and provides a certain QOS agreement for the connection (Figure 2). The response time of an ATM end station trying to access a server through this ATM link turns out to be extremely slow compared with expectations.

Connecting a protocol analyzer and monitoring the traffic shows that TCP is used as the transport layer. As part of this protocol, TCP implements flow control between the transmitter and receiver to ensure that a fast sending host does not overrun a slow receiver. Each message contains a window field that specifies the number of bytes that can be sent in the next message. The sending workstation can only send as many characters as are specified in the window before waiting for an acknowledgement, and when this window is small compared with the link capacity, the transfer bandwidth is determined by the software delays in the host. By increasing the TCP window parameter, longer messages can be sent before the user anticipates an acknowledgement.

Testing packet over Sonet The complexity of ATM protocols and the overhead introduced by ATM have led to the development of packet over Sonet. Packet-over-Sonet technology enables service providers to offer end-to-end frame-based service without requiring an ATM core.

With the explosion of Internet traffic, Internet protocol is quickly becoming the standard method for the transfer of data, voice and video. Even today, the amount of IP traffic outweighs any other protocol or application. Until recently, ATM was the only scalable technology capable of carrying multiple services over long distances. However, with the advent of packet over Sonet, a new high-speed frame-based service is now available, bypassing the ATM overhead. In packet over Sonet, IP traffic runs over PPP or PPP with HDLC-like framing.

The following calculation shows the benefit of packet over Sonet. When using ATM OC-3c (155 Mb/s) and considering the ATM and Sonet overhead, the resultant bandwidth available for user data is 135.6 Mb/s, compared with 149.1 Mb/s when using PPP over Sonet.

Packet over Sonet does not incorporate a QOS mechanism such as ATM but instead relies on higher layers to manage QOS-allowing a limited number of real-time video sessions to run over a routed IP network. This is a major drawback in packet over Sonet. It does not have any provision for bandwidth management. This can cause problems when mixing time-sensitive video or voice traffic with high volumes of data transfer, especially if the packets are very long.

Packet over Sonet does not provide any fault tolerance and relies on the Sonet capabilities for switching rings when a fault occurs.

Testing packet over Sonet is similar to testing a PPP connection. After the Sonet layer is set up, the service provider must negotiate a link using link control protocol (LCP). Each party in a PPP link sends a configuration request packet, which designates each party's transmission options. The other party responds with a configuration "ack" (acknowledged) when it accepts the parameters.

However, a configuration "nack" (not acknowledged) is returned in response to a configuration request when all the options requested are recognizable but one or more of the negotiable options are unacceptable or sub-optimal, or a desired configuration option was not requested by the sender. A protocol analyzer can help an engineer detect which one of these problems occurred.

Another instance is when a configuration "reject" is returned in response to a configuration request when one or more of the requested options is unrecognizable, or when a non-negotiable option is included that is unacceptable to the receiver (Figure 3).

Solving negotiation problems is tough without a protocol analyzer that can decode protocols such as LCP, password authentication protocol and challenge handshake authentication protocol. This has to be done on the packet-over-Sonet line itself, requiring a protocol analyzer that can look at OC-12 (622 Mb/s) packet-over-Sonet traffic in real time and decode all layers of the open systems interconnection model.

After the link negotiation handshake is accomplished, the protocol is negotiated using network control protocol. In most cases the service provider will use IP, which brings us to the TCP problems previously mentioned. Again, the carrier needs to use a protocol analyzer to be able to see the TCP/IP layer, which runs over the Sonet link.

Whatever the technology used when testing WAN systems, two major problems-connectivity and performance-need to be addressed. These problems occur during the whole life cycle of a network from installation to testing and maintenance, and it is important to know what tools are available for testing these systems.

The tools should provide an easy way of looking at all seven layers of the open systems interconnection model in real time, thus enabling the network engineer to solve the different problems that can occur in each layer.