Novell is now a part of Micro Focus

Overview of NetWare Link/ATM Technology

Articles and Tips: article

RIC LEUNG
Technical Marketing
Communications Infrastructure Division

01 Apr 1996


This AppNote provides an overview of the NetWare Link/ATM technology, part of the WAN Extensions 3.1 option available with the NetWare MultiProtocol Router 3.1 product. The AppNote covers the architecture and implementation of NetWare Link/ATM. It also highlights some configuration and vendor interoperability issues.

RELATED APPNOTES Jun 94 (Research Report) "Transitioning to ATM"

Introduction

Asynchronous Transfer Mode (ATM) networks are a key enabler for global multimedia information infrastructures and inter-networked computer systems. Organizations using the NetWare Link/ATM will appreciate the high bandwidth, flexibilility, and scalability that ATM offers.

This AppNote provides a brief overview of Asynchronous Transfer Mode and the NetWare Link/ATM technology available with the NetWare MultiProtocol Router (MPR) 3.1 product. The AppNote covers the architecture and implementation of NetWare Link/ATM. It also highlights some configuration and vendor interoperability issues.

Overview of ATM Technology

Unlike conventional LANs, such as Ethernet, Token Ring and FDDI, ATM is not a shared-access technology. A shared-access technology consists of a common wire used by all attached nodes to communicate. Adding extra nodes reduces the bandwidth available to the existing nodes, which sets an upper limit to the number of nodes that can be attached to a shared-access network. Because ATM does not suffer from this limitation, the number of nodes supported can be much larger. As traffic increases and LANs become more complex, hubs and routers will exhaust their capacity. In contrast, the cell-switching aspect of ATM means that every port added to an ATM switch is a parallel connection that increases the bandwidth of that hub.

The backbones of the ATM network are high-speed cell switching systems. These systems (called switches) are interconnected by physical transmission links. End-stations are directly connected to a switch. As in X.25 networks, end-stations create connections between end-stations.

In ATM networks, the end-stations send data as fixed-length cells. Each cell is 53 bytes long. Larger frames (up to 64 kilobytes) are sliced into cells; the cell containing the end of the frame can be padded. The sending end-station is responsible for proper pacing of cells, based on a contract Quality of Service (QoS) required. This can differ from connection to connection (and even depending on the direction of the connection). All information, whether it is data, voice, or video, uses the same cell structure and size. There is no delivery guarantee. ATM relies on transport protocols for that.

ATM is a layered architecture allowing multiple services (data, voice, and video) to be mixed over the network. Three lower level layers have been defined to implement the features of ATM:

  • The adaptation layer assures the appropriate service characteristics and divides all types of data into the 48-byte payload that will make up the ATM cell.

  • The ATM layer takes the data to be sent and adds the 5-byte header information that assures the cell is sent on the right connection.

  • The physical layer defines the electrical characteristics and network interfaces. This layer "puts the bits on the wire." ATM is not tied to any specific type of physical transport.

Benefits of ATM

Generally, ATM has several key benefits:

  1. Flexible channel bandwidth allocation. In ATM networks, bandwidth can be reassigned in real-time to different traffic based on demand.

  2. Scalable over physical size, speed, and node count. ATM networks can be scaled geographically. Because ATM networks can be increased indefinitely, they tend to eliminate the distinction between LANs and WANs.

  3. One single network. ATM will provide a single network for all traffic types: voice, data, and video. ATM is evolving into a standard technology for local, campus/backbone, and public and private wide area services. This uniformity will simplify network management by using the same technology for all levels of the network.

  4. Enables new applications. Due to its high speed and the integration of traffic types, ATM will enable the creation and expansion of new applications such as multimedia to the desktop.

  5. Compatibility. Because ATM is not based on a specific type of physical transport, it is compatible with currently deployed physical networks. ATM can be transported over twisted pair, coax, and fiber optics.

  6. Long architectural lifetime. The information systems and telecommunications industries worldwide are focusing and standardizing on ATM. ATM has been designed from the onset to be scalable and flexible. This flexibility and scalability assures that ATM will be around for a long time to come.

Incremental Migration to ATM

Efforts within the standards organizations and the ATM Forum continue to assure that existing networks will be able to gain the benefits of ATM incrementally. Users can thus upgrade portions of the network to ATM based on new application requirements and business needs.

Overview of NetWare Link/ATM

NetWare Link/ATM is contained in WAN Extensions 3.1, which is available as an option in the NetWare MultiProtocol Router 3.1 product. When loaded on a PC-based server running MPR and containing a certified ATM adapter with the appropriate driver, NetWare Link/ATM allows high speed LAN-to-LAN inter-connection over ATM networks (see Figure 1). Therefore, it is well-suited for applications such as server backup and database replication over a corporate network backbone.

NetWare Link/ATM facilitates an incremental transition to ATM by protecting your existing LAN investments while planning and implementing a corporate network transition into full desktop ATM deployment. NetWare Link/ATM requires no changes to existing applications or wiring in the desktop environment

Figure 1: NetWare Link/ATM allows you to interconnect LANs over a high-speed ATM network backbone. you to interconnect LANs over a high-speed ATM network backbone.">

Architecture

Unlike conventional LAN protocols, ATM is not aware of the Media Access Control (MAC) and Link Layer Control (LLC) headers. Therefore, it cannot make use of the standard NetWare Open Data-Link Interface (ODI) Link Support Layer (LSL) software to perform per-packet demultiplexing. Additionally, ATM is a connection-oriented protocol. Hence, ATM requires some other mechanism to establish connections.

To meet these needs, Novell developed a special ODI for ATM called NetWare ATM-ODI(see Figure 2).

Figure 2: The NetWare Link/ATM architecture is based on a version of the Open Data-link Interface (ODI) designed for ATM. architecture is based on a version of the Open Data-link Interface (ODI) designed for ATM.">

The components of NetWare ATM-ODI include:

  • ATMTSM (ATM Topology Specific Module)

  • ATMHSM (ATM Hardware Specific Module)

  • ATMWAA (ATM Wide Area Access module)

ATMTSM. The Topology Specific Module is the central component of the ATM ODI architecture. It is the layer that resides between the ATMHSM and the ATMWAA.

ATMTSM provides two groups of Application Programming Interfaces (APIs): one is used by the ATM HSMs, and the other is used by the user applications that require direct native access to ATM services. The HSM API resides at the bottom of the TSM, while the User API resides at the top.

ATMTSM implements version 3.0 of the ATM Forum's UNI (User to Network Interface) specification. It separates the connection management oriented functions from the hardware-specific tasks. The separation of functionality is such that an ATMHSM does not need to be aware of whether Virtual Circuits(VCs) are permanent or switched, nor does it need to know whether they are incoming or outgoing.

Because the ATM adapter hardware or firmware is usually responsible for maintaining the VC contracts (such as the rate of transmission), ATMTSM enables and disables the VCs individually. Conversely, the ATMWAA (or native ATM user applications) do not need to be aware of any of the hardware-related issues. When establishing a VC, the ATMWAA only needs to be aware of the hardware that is its interface identifier. ATMTSM registers a board with the LSL for each interface that ATMHSM registers with ATMTSM. Thus, the interface identifier is a board number.

ATMHSM. This module is the ATM card driver that comes from the card vendor. To maximize the performance, adaptor vendors can develope HSM drivers that will assign priority to each VC. ATMHSM should be able to assign receive resources based on the priority. When the CPU is temporarily occupied with processing previously-received frames, ATMHSM can forward higher priority frames ahead of lower ones. If the CPU becomes backlogged to the point where ATMHSM has a high volume of received frames in queues, it should discard frames for VCs with a low priority, in favor of those with a high priority. (There are eight different priority levels. The higher priorities are typically used for real-time data.)

To optimize performance, ATMHSM is VC and ECB (NetWare buffer) aware, for both the transmit and receive interface. Both the ATMHSM and the ATMTSM maintain their own Adapter Data Space (ADS). During the registration process, the ADS addresses are exchanged. ATMTSM will pass ATMHSM's ADS address when it passes control for interrupts or polls.

ATMWAA. ATMWAA is implemented as a NetWare ODI Multiple Link Interface Driver (MLID). It interfaces with LSL/CSL(Link Support Layer/Call Support Layer) on one side, and with ATMTSM on the other. ATMWAA implements the RFC1483 specifications.

Together with ATMTSM, ATMWAA allows high level protocols/ applications to set up connections with remote ATM end-systems, transfer data, and subsequently take down connections. We'll look at an example of how this occurs later in this AppNote.

Implementation

Following are some implementation notes about the features supported by this release of NetWare Link/ATM.

Protocol Support. NetWare Link/ATM supports AppleTalk, IP, and Internetwork Packet Exchange (IPX) protocols, as well as Source Route Bridging.

RFC 1483 Support. NetWare Link/ATM implements the two protocol multiplexing methods specified in RFC 1483: VC-based Multiplexing and LLC Encapsulation. These are explained further under the "Protocol Multiplexing Methods" heading below.

On-Demand Link Support. An on-demand connection is one that is established temporarily when there is data to transmit. If no data is received over the connection after a specified idle-timeout period has elapsed, the connection is released. If multiple protocols are used over a single connection, the idle-timeout value applies to the ATM connection as a whole, not to each protocol connection.

Inbound Call Authentication. Inbound call authentication allows the user to specify a list of remote ATM addresses from which incoming calls are accepted. However, because an ATM end-station can have more than one address, the user must ensure that all addresses for that ATM end-station are entered in the list.

Maximum Number of VCs Supported. NetWare Link/ATM does not place any limitation on the number of connections that can be established for a system. However, users should consult with ATM adapter vendors for information specific to a particular adapter.

Quality of Service Classes Supported. NetWare Link/ATM supports the following Quality of Service (QoS) classes:

  • Available Bit Rate (ABR)

  • Variable Bit Rate (VBR)

  • Unspecified Bit Rate (UBR)

During connection setup, the originating system is expected to specify the desired values for these parameters. Upon further negotiation, the receiving system either accepts or rejects the connection.


Note: The types of service classes supported by specific ATMadapters and switches vary. Check with your ATM serviceprovider for detailed information about service classes.

Protocol Multiplexing Methods

VC-based Multiplexing. VC-based Multiplexing supports one protocol over each ATM connection. No encapsulation is required when data is transmitted. ATM connection setup and takedown occur directly by way of protocol stack requests.


Note: Although NetWare Link/ATM does not place any restrictions on multiple calls using the same protocol, someprotocols do not support multiple calls.

The primary advantage of VC-based multiplexed connections over the LLC method is traffic separation because it allows connection configuration for individual protocols.

LLC Encapsulation. LLC Encapsulation allows multiple protocols to share a single ATM connection. The ATM connection request is initiated only when the first protocol requests a connection to a remote end-station. After a connection is set up, any other protocols requesting a connection to the same remote end-station will not cause additional connection setup messages to be sent. Instead, a call confirmation is generated by the local system. At the remote end-station, an incoming call signal is generated when it receives the first data packet. Then the call is established.

The ATM connection is taken down only when the last referencing protocol of an established ATM connection requests takedown of its connection. If the protocol requesting the disconnect is not the last one referencing the ATM connection, the call is disconnected only at the local system. If the user does not manually re-establish the call within 15 minutes, the remote system will disconnect the call for the protocol. Therefore, the user might see one end-station showing a call as disconnected, whereas the other end-station shows the connection as still being up until the 15-minute timeout has expired.

The primary advantage of LLC encapsulation over the VC-based multiplexing method is reduced cost of VCs. Also, bridging and the permanent virtual connection (PVC) call type are supported only when using the LLC Encapsulation method.

Limitations. In Novell's implementation, when two end-systems communicate with each other, only one of the two multiplexing methods can be used. They cannot be used simultaneously. This means that between two end-systems, it cannot have one protocol (for example, IP) using LLC encapsulation and another (for example, IPX) using VC-based multiplexing. However, it can have multiple protocols between one end-system and another using LLC Encapsulation, and between the first end-system and a third end-system using VC-based Multiplexing, as shown in Figure 3.

Figure 3: With NetWare Link/ATM, only one protocol multiplexing method can be used between two end-systems.

When LLC Encapsulation is used, only one ATM connection are can be established, and only one call per protocol is allowed over a shared virtual channel. If a second call from the same protocol is attempted, the call will be rejected. Protocol features that require multiple connections to the same end-station (such as IPX load sharing) should not be enabled.

Example

The following is an example of typical operation of NetWare Link/ATM using VC-based Multiplexing.

  1. ATMWAA is loaded re-entrantly once for every ATM board.

  2. During the initialization, ATMWAA registers itself with the LSL as an MLID, with ATMTSM as an application, and then acquires the local ATM address from ATMTSM.

  3. ATMWAA then registers with the CSL as a WAN board with the interface state set to be UP.

    At this point, the protocol stacks can start requesting connections.

  4. To set up a connection to a remote ATM end-system, a protocol stack issues a make call request to ATMWAA through CSL, passing it information including the remote system address, the encapsulation method, the carried protocol, and the Quality of Services (QoS) parameters.

  5. ATMWAA allocates a Call Record, prepares the various options for the connection request, and calls a corresponding function in ATMTSM to request the connection.

  6. Once confirmation is received from ATMTSM, the connection enters the data transfer state.

For LLC Encapsulation, the procedure is very similar except that a connection setup request is issued only when the first protocol requests a connection to a remote end-system. Likewise, a connection take-down request is issued only when the last protocol over that connection requests to take down its connection.

Configuration Considerations

Before you begin configuring NetWare Link/ATM, you should:

  1. Familiarize yourself with exactly what your ATM service carrier has done to provide the connection medium. You should have values for the following service classes:

    • ABR (Available Bit Rate)

    • VBR(Variable Bit Rate)

    • UBR (UnspecifiedBit Rate)

  2. Be aware of the physical limitations of the adapter being used for your ATM interface.

    Verify that both physical and logical boards are configured for NetWare Link/ATM.

    Check if the Link/ATM User Data Size is set to the same value on both systems. Both the User Data Size and the system Maximum Packet Receive Buffer Size should be set as large as the application requires.

Troubleshooting Tools

This section briefly introduces two utilities that can be used to troubleshoot NetWare Link/ATM.

ATMCON. This is an NLM diagnostic console utility for NetWare Link/ATM. It provides access to NetWare Link/ATM configuration information and statistical data relating to the operation of NetWare Link/ATM (see Figure 4).

Figure 4: The ATMCON utility.

MONITOR. This NLM utility that comes with the NetWare operating system allows you to determine which NetWare Link/ATM adapters are installed and exchanging traffic with the network. The LAN/WAN driver information provided by MONITOR allows you to view generic and custom statistics for ATM and ATMWAA drivers (see Figure 5). These statistics enable you to determine whether the drivers are sending and receiving data and whether error statistics (such as No ECB, Receive Packet Too Large, and others) have been logged.

Figure 5: ATM driver statistics in the MONITOR utility.


Verified ATM Hardwareand Drivers for NetWare Link/ATM

The Novell Labs group plans to have an ATM driver certification program available by May 1996.In the meantime, Novell has verified the following components forfunctionality and stability.

ATM Switches

  • BayNetworks ATM switch

  • FORE ATM switch

  • UBNetworks ATM switch

To ensure that the NetWare Link/ATM software works properly,ATM switches must meet the following requirements:

  • BayNetworks switches must be running Connection Manager 1.2 or later.

  • FORE Systems switches must be running FORE Systems software 3.3.0 or later.

  • Other switches must support ATM Forum UNI 3.0 signaling, including ILMI address registration

ATM Adapters

  • Efficientadapter *

  • FORE ATM adapter **

  • MadgeATM adapter **

  • Zeitnet ATM adapter *

* Efficient and Zeitnet drivers are verifiedon the NetWare 4.1 platform

** FORE Systems and Madge drivers are verified on the NetWare 4.1 and 3.12 platforms

Contact the ATM adapter vendors for the latest ATM-ODI compliant drivers. All ATM adapter vendors must supply an ATM-ODI HSM (Hardware Specific Module)driver conforming to Novell specification 107-00083-001 (August 1995).

Updates for NetWare Servers Running NetWare Link/ATM

The following supplemental files allow the ATM driver to operate:

NetWare 4.1 environment LOADER.EXEand LSWAP.EXESHRRAMFX.NLM and PM410.NLM

NetWare 3.12 environment SHRRAMFX.NLM andPM312.NLM

Refer to the NetWare MPR 3.1 Release Notes for installation detailsof the supplemental files.

Interoperability Issues

For the MPR 3.1 release, Novell has performed interoperability testing with the Cisco 7010 router version 11.0 (2.5). This testing verified that the following protocols operate between the NetWare Link/ATM module and the Cisco router in PVCs (Permanant Virtual Connections):

  • AppleTalk

  • IP

  • IPX

As of this writing, Cisco is working on SVC (Switched Virtual Connection) interoperability. Check with the vendor for latest information.

Figure 6: A Cisco 7010 Router can interoperate with NetWare Link/ATM servers across an ATM network.

Summary

ATM is strategically important for Novell and its customers. NetWare Link/ATM represents only the first offering of Novell's ATM strategy. Novell is committed to continue further research and development of ATM technology to include LAN Emulation and Native ATM Services for the NetWare environment.

* Originally published in Novell AppNotes

Disclaimer

The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.

© Copyright Micro Focus or one of its affiliates