Table of Contents:

Definition and Overview

1. ATM Layer Testing

2. Stages of Testing ATM Products

3. Signaling over ATM

4. Automated Testing

5. Testing Deployment of ATM Services

6. LANE over ATM

7. Summary

Self-Test

Glossary

PDF of this tutorial

The Issues

Testing LAN interconnections over ATM continues to provide many difficulties. These problems are the result of a number of contributing factors including:

• multiple product specifications—the ATM Forum, Internet Engineering Task Force (IETF), and a number of networking companies (including Cisco, IBM, 3Com, and Ipsilon) have each proposed different models for LANE, multiprotocol over ATM (MPOA), classical Internet protocol (IP), and additional variations based on the concepts of intelligent switching.
• protocol decoding—ATM is primarily a transport level protocol. To provide a communications link between two (2) existing LAN systems, all of the native protocols must be encapsulated before transmission over the ATM portion of the network. When monitoring an ATM network, it is often necessary to detect protocol encapsulations prior to performing protocol decoding.

Encapsulation standards are the rules observed by networking equipment to insert and extract the protocol information for any payload portion of any packet. Each encapsulation method describes the location within the packet (at what offset) of the unique identifier to specify the higher layer protocol (i.e., IP or Internet packet exchange [IPX]).

The use of protocol encapsulation process requires prior agreement between any end-systems involved in communication. Most protocol encapsulation methods do not directly identify the encapsulation method or the identity of the encapsulated protocol.

• multiple encapsulations—The use of multiple encapsulations is one of the most common causes of networking problems on LANs. The use of multiple encapsulations is relatively common in both LAN and WAN networks. Router vendors have developed products supporting both standards-based and proprietary WAN encapsulations. The proprietary versions are often driven by the need for efficient use of bandwidth while standards-based solutions trade off efficiency for multivendor compatibility.
• calls for standardization—To promote compatibility for LAN over ATM the IETF's request for comment (RFC) 1490 (supersedes RFC 1294) recommends encapsulation be used for LAN data over a frame relay transport.

Figure 12. Typical LANE Network Architecture

The need for a common encapsulation for LAN traffic over ATM was recognized very early. IETF's RFC 1483 requested methods of encapsulating network interconnect traffic within an ATM adaptation Layer 5 (AAL5) protocol data unit (PDU). RFC 1483, published to define the recommended encapsulation, included six possible methods and resulted in introducing additional incompatibilities between devices that are 1483 compliant.

The six methods fall under two categories described as listed:

• logical link control (LLC) encapsulation—allows multiplexing of multiple protocols over a single VCC using 802.2 LLC/SNAP as the identifying prefix
• VC–based multiplexing—implicitly defines a one-to-one protocol to VCC mapping

Will One Encapsulation Dominate?

Although it appears that standards are converging on LLC encapsulation, LANE v1.0 remains the most common implementation of LAN interconnect over ATM. Other popular methods include:

• LANE v1.0 uses the VC multiplexing bridged Ethernet/802.3 (for Ethernet LANs) or bridged 802.4/5/fiber distributed data interface (FDDI) (for token-ring and FDDI LANs; see Figure 13).
• LANE v2.0 has specified the use of LLC encapsulation.
• RFC 1577 (classical IP over ATM) also uses the LLC encapsulation as does the MPOA specification.

Figure 13. Testing LAN of ATM

The ATM Forum has, to date, produced three separate specifications:

• LANE v1.0
• LANE v2.0
• MPOA

The IETF has published RFC1577, dealing specifically with transmission control protocol (TCP)/IP traffic. Most switch vendors today provide support for both LANE v1.0 and classical IP.

Many companies have recognized limitations in these standards (increased complexity and falling performance) and have responded by proposing their own proprietary solutions.

IETF—Next Hop Resolution Protocol

IETF's next hop resolution protocol (NHRP) was developed during an ATM Forum joint LANE/MPOA working group session. The LANE working group included support for the NHRP as a routing protocol in the LANE v2.0 specification. This feature enables users to employ short circuit direct VCC interemulated LAN (ELAN) connectivity similar to MPOA.

IBM—Multiprotocol Switched Services (MSS)

IBM adopted a modified version of LANE v1.0 with its announcement of MSS. This extends the LANE V1.0 specification by adding broadcast containment and allows LANE–based systems to route traffic based on the IETF's NHRP.

Ipsilon Networks—IP Switching

Ipsilon Networks was founded to promote a new standard called IP switching. This solution offers a proprietary hardware and software alternative to the use of UNI 3.1/4.0 signaling protocols. IP switching has demonstrated higher throughput levels at reduced cost and level of complexity. This technology, submitted to the IETF as RFC 1953/1954, is gaining market acceptance by the communications industry (i.e., FORE, GDC, Digital, and Ericcson).

Tag Switching

Cisco has also proposed a protocol switching method known as tag switching. This tag distribution protocol (TDP) has been submitted to the IETF as an RFC for adoption as a standard. TDP works by having edge devices numerically tag frames or cells based on routing table information. Once tagged, traffic is forwarded through the network solely on the basis of the tag rather than the more time-consuming route table look-up.

RFC 1577 Classical IP over ATM

IETF's RFC 1577 recommends an architecture for operating classical IP networks over an ATM transport. This RFC defines the operation and components (i.e., ATMARP server) and references the LLC method of encapsulation from RFC 1483 as the frame format to be used.