windows atm services - itwelzel.bizgwise.itwelzel.biz/microsoft/windows 2000 server... · web...

Operating System

Windows ATM Services

White Paper

Abstract

This white paper describes the Asynchronous Transfer Mode (ATM) services that Microsoft and other vendors provide in the Microsoft® Windows® 95 and Microsoft Windows NT® 4.0 operating systems. It also describes the new native ATM services provided in Windows 98 and Windows 2000. The paper provides a general overview of ATM technologies and describes how to deploy ATM in a variety of networking situations.

© 1998 Microsoft Corporation. All rights reserved.The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.This White Paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.The BackOffice logo, Microsoft, Windows, and Windows NT are registered trademarks of Microsoft Corporation.Other product or company names mentioned herein may be the trademarks of their respective owners.Microsoft Corporation • One Microsoft Way • Redmond, WA 98052-6399 • USA0699

INTRODUCTION.................................................................................1Where Is ATM Used Today? 1How This Paper Is Organized 1

ATM TECHNICAL OVERVIEW..............................................................2What Is ATM? 2Differences between a Traditional LAN and an ATM LAN 2

Connectionless vs. Connection-Oriented 2Network Speed 5Service Guarantees 6The ATM Adaptation Layer (AAL) 8Summary of Benefits 9

HOW ATM WORKS – ATM CLIENT SOFTWARE REQUIREMENTS.......10Hardware Interface 10Signaling 11Protocol Layer 12

LAN Emulation 12LANE in Detail 13

IP over ATM 15ATMARP Server 16MARS 16

PPP Over ATM 18

ATM SUPPORT IN WINDOWS 95 AND WINDOWS NT 4.0.................20

WINDOWS ATM SERVICES – WINDOWS 98 AND WINDOWS 2000..............................................................................22API Support in NDIS 5.0, Winsock 2.0, and TAPI 22

ATM Call Manager 24LANE 25IP/ATM 25PPP/ATM 26DirectShow 27

Weather Report Application 27IP Phone Access 28

Potential Future Additions to Windows ATM Services 28

ATM DEPLOYMENT..........................................................................30Configuring LAN Emulation 30

Configuring the LANE Client 31LANE Client Fault Tolerance 34

IP/ATM 34The ATMADM Utility 39Using PVCs 39

CONTENTS

Registry Parameters – Windows 98 40Deployment Scenarios 43

ATM Core with Ethernet Edge 43ATM to the Desktop 44Residential/SOHO Access with ATM 45

Key Considerations 45

CONCLUSION..................................................................................46For More Information 46

Asynchronous Transfer Mode (ATM) describes a number of related, standards-based technologies that provide high-speed communication over a variety of media. Before you can decide whether to use ATM in your network deployment, you should understand how it integrates with current networking environments and how it will function with new networking environments that will be available. This paper’s main emphasis is on the integration of ATM with the Microsoft® Windows® operating system. It covers the ATM services included in Windows 95 and the Windows NT® 4.0 operating system, as well as the native ATM support included in Windows 98 and Windows 2000.

Where Is ATM Used Today?ATM is a wide array of services and concepts, and its usefulness can only be measured when you understand how all the various pieces fit together, in both their current and future states. Right now, ATM technologies exist in a scattered form. Some networks have been completely transformed into native ATM networks—with software, end-station hardware, and network fabric all made up of ATM devices and drivers. In other networks, ATM only shows up as a backbone or trunk provider. And in some instances, ATM is deployed in small pockets intermixed with standard local area network (LAN) components and other networking technologies.

ATM is still going through a difficult acceptance stage. In some cases, ATM’s usefulness is being judged by how well it emulates legacy networks; that is, how it compares with traditional LANs. In other cases, ATM provides so many clear advantages in terms of speed, manageability, and accuracy that it seems to be the only viable solution and its acceptance is guaranteed.

ATM is expensive; it hasn’t yet fully realized the advantages of commodity availability and pricing. However, in the near future, more integrated ATM services at the operating system level, more universal drivers that bring down the cost and complexity of using ATM, and more consistent and reliable ATM services in all networking areas will make ATM more attractive.

How This Paper Is OrganizedTo clarify ATM and to clearly define the terms and concepts that are key to any understanding of ATM, this paper begins with a brief overview of ATM and related technologies. It then describes how ATM is supported and integrated into today’s networks. The final section includes details on Microsoft Windows ATM support, how the support is achieved, and how you should work with the new, native ATM services provided in Windows 98 and Windows 2000.

Although some of the information in this paper may not be new to you, it is recommended that you read the brief overview section as it provides a background for much of the material in later sections.

Microsoft Windows White Paper

1

INTRODUCTION

This section provides a brief technical overview of ATM. It also introduces some important concepts that you’ll need to be aware of before proceeding.

What Is ATM?The phrase “Asynchronous Transfer Mode” doesn’t say much about what ATM does or what advantages it offers. In fact, ATM alone doesn’t refer to a specific device or system. It is a group of related technologies. In this paper, ATM refers to software, hardware, and connection media together. This collection of ATM technologies cannot be described in a single sentence, but some important aspects include:

Scalable performance—ATM can data across a network quickly and accurately, regardless of the size of the network. ATM works well on very low to very high-speed media.

Flexible quality of service (QoS)—ATM allows the accuracy and speed of data transfer to be specified by the client.

In addition, ATM is a deterministic networking system—it provides absolute, predictable, guaranteed quality of service. From end to end, every component in ATM provides a high level of control and reliability.

A top-level picture of ATM would show two basic components: an end station, (a computer connected to the ATM network) and an ATM switch (the device responsible for connecting end stations and making sure data is transferred successfully).

Figure 1. ATM Network Components

Differences between a Traditional LAN and an ATM LANTo further clarify ATM, it is beneficial to examine how a traditional LAN operates and contrast the two networking systems.

Connectionless vs. Connection-OrientedTraditional local area networks, such as Ethernet and Token Ring, use a connectionless, unreliable approach when sending information across the network.

Microsoft Windows White Paper 2

ATM TECHNICAL OVERVIEW

Each client is connected to the network by an adapter card, which has a driver, and above that driver is a protocol driver, such as TCP/IP. The protocol driver bundles information into frames of varying size, and gives each bundle an appropriate header. Then, when the wire is available, the data packets are shipped off to be individually routed through the maze of hardware and software. Each packet in a series of packets could conceivably take a different route to reach the same destination. Traditional LAN technologies do not guarantee that data will arrive on time or in the proper order. Ethernet and Token Ring can detect errors, but they provide no service guarantees and are not responsible for recovery from missing or corrupted data packets.

Figure 2. Two Packets Taking Different Routes Through a Traditional LAN

Because they are joined by a common medium, each station on the traditional LAN sees the packets of data put on the wire by each of the others, regardless of whether the packet is passed sequentially from one station to the next (as in a ring topology) or broadcast to all stations simultaneously (as with Ethernet). Each station has an adapter card, which processes the packet and examines the destination address. If the address applies to that machine, the adapter does a hardware interrupt and accepts the packet.


3

Figure 3. Traditional LAN -- Connectionless Data Transmittal of a Packet

Because a traditional LAN is connectionless, it cannot provide guarantees or similar features. For example, it cannot determine the status of the target machine. It cannot ensure that bandwidth will be available throughout the transmission. Unanticipated bottlenecks are common, which can hinder a traditional LAN’s ability to support time-sensitive applications such as video-on-demand or voice traffic. Traditional LANs can use upper-level protocol drivers are to do such things as verify packet arrival (retransmitting, if necessary), partition big messages into smaller ones, use time stamps for synchronization, and so forth. However, these services add time to the transmission, and none of them provide end-to-end quality of service guarantees.

ATM, on the other hand, is connection-oriented. An ATM end point establishes a path (a virtual circuit, or VC) to the destination end point prior to sending any data out on the network. It then sends a series of same-size packets (called cells) along this path towards the destination. Note that while establishing the connection, the ATM end point also negotiates a quality of service (QoS) contract for the transmission. This contract spells out the bandwidth, maximum delay, acceptable variance, and so forth that the VC will provide, and this contract extends from one end point to the other. ATM provides guaranteed quality of service through a LAN, a WAN, and a public internetwork.

Unlike LAN traffic, ATM traffic does not need to be redirected at each router or switch. Its path is identified at the outset, and the switching hardware merely needs to examine a simple header to identify the proper output port. Note, however, that ATM is an unreliable transmission protocol. It does not expend bandwidth sending or waiting for data acknowledgement. As with LANs, missing or corrupted information must be detected and corrected by upper-level protocols.


Figure 4. ATM Virtual Circuit and Packet Transmission

Network SpeedWhile traditional networks are increasing in speed—for example, there is now 100 MB and Gigabit Ethernet—the underlying architecture has speed limitations. Ethernet works on a carrier sense multiple access/collision detection (CSMA/CD) mechanism. It uses a half-duplex method to exchange data (one node transmits while the other node waits for the data), and, to prevent collisions, it allows only a single node to use the shared media (in a half-duplex fashion) at any one time. The layer that does the collision detecting and carrier sensing can only manage segments up to a certain length and up to a certain transmission speed; these limitations are associated with the length and propagation speed of the wire and the speed that data is placed on the wire. For example, if your network is upgraded from 10 MB Ethernet to 100 MB Ethernet (that is, you multiplied the transmission speed by 10), you would need to divide the maximum length of a segment by 10. If you further increase your network speed from 100 MB to 1000 MB, you would need to reduce your segment length to 25 meters. Note that these numbers are based on copper wire. Your maximum segment lengths can be longer if you have a medium that propagates more rapidly. (For this reason, very fast Ethernet [Gigabit Ethernet] requires fiber cable.)

ATM, on the other hand, has no inherent speed limit, and its efficiency is not affected by the distance that the data has to travel. Unlike a routed Ethernet environment where decisions are made at every bridge and gateway, ATM establishes the pathway for a particular series of packets at the outset and makes minimal decisions thereafter. To travel across the ATM network, data is segmented into same-size cells, and encapsulated with a header that contains routing, congestion, and error checking information. ATM allows a location to establish a full duplex connection (that is, traffic can travel in both directions) with multiple locations at the same time.


5

Cells are transmitted in the proper order, and the network uses a simple Virtual Path Identifier/Virtual Channel Identifier (VPI/VCI) header to efficiently route them through the switching hardware. A switch reads the header to determine the correct output port, and then sends the packet on through—without requiring any complicated analysis, lookup tables, or hardware interrupts. All of the addressing information the ATM switch needs is contained in the header and is always found in the same place. This makes the translation task simple to implement in hardware, reducing latency. Moreover, with ATM, there is no data translation required if a packet must travel from a LAN through a WAN to reach a destination LAN. ATM virtual paths and virtual channels and the ATM cell structure are explained more fully in the section, “How ATM Works – ATM Client Software Requirements,” later in this document.

Figure 5. ATM Fixed-Length Cells (Bi-directional Traffic)

Because ATM uses small (53-byte) fixed-length cells that require minimal logic to process, the network spends no time determining where a particular cell begins and ends. The small cell size ensures that there are no bottlenecks at the switch, as there would be if a small packet had to wait for a large packet to be processed before proceeding. Because the cell size is so predictable, buffer usage and analysis algorithms can be simplified and optimized.

To summarize, traditional LAN technologies such as Ethernet have inherent speed limitations—either the underlying infrastructure (the cable) or the segment length must be changed to support fast traffic. However, unlike Ethernet and Token Ring, ATM has no such imposed limitations. If you can invent a faster physical layer—if you can design a quicker method of transmitting data reliably from one place to another over one wire or many wires—ATM can work over that physical layer and at those new speeds. In addition, ATM allows information with different requirements and from different nodes to be transmitted nearly simultaneously without fear of collision. ATM places fixed length cells on the media when the data is produced according to the parameters of the previously negotiated connection. ATM can simultaneously handle the needs of isochronous (time-dependent) traffic, such as


voice and video, and non-isochronous traffic, such as LAN data.

Service GuaranteesAs part of the previously negotiated connection, ATM end points establish a service contract that guarantees a specific quality of service. Note that quality of service (QoS) guarantees are not offered by traditional LAN solutions.

With a traditional LAN, any notion of service guarantee is based on priority, where one transmission receives delivery preference over others. Because the condition of the network and data recipient aren’t known prior to transmission (traditional LANs are connectionless), traffic is subject to delay at routers and so forth. These unforeseen delays can make bandwidth availability and delivery times difficult to predict. While the traffic with the higher priority will generally reach its destination prior to traffic with a lower priority, the higher priority traffic may still arrive too late.

ATM offers very granular, explicit service guarantees that are not based on a relative structure (such as priority). With ATM, a data supplier can request a specific bandwidth, maximum delay, delay tolerance, and so forth. Each ATM switch then determines whether or not it can meet the request after taking prior allocations into consideration. If it can accommodate the transmission, it will guarantee the service level and allocate the necessary resources. With ATM, the service contract is enforced and the bandwidth is allocated at the hardware level—all of the switches between the sender and receiver know and agree to the service level before the contract is granted. The source station hardware, also having agreed to the contract, is responsible for shaping the traffic before it enters the network.

ATM offers the following service categories:

Constant Bit Rate (CBR), which specifies a fixed bit rate. Data is sent in a steady stream with low cell loss. Note that this is expensive because the granted bandwidth must be set aside, regardless of whether or not it is actually used. Only the most time-sensitive applications require CBR.

Variable Bit Rate (VBR), which specifies a throughput capacity over time, but data is not sent at a constant rate. This also specifies low cell loss.

Unspecified Bit Rate (UBR), which does not guarantee bandwidth or throughput. Cells can be dropped.

Available Bit Rate (ABR), which ensures a guaranteed minimum capacity but allows data to be sent at higher capacities when the network is free. ABR adjusts the rate of transmission based on feedback. This specifies low cell loss. ABR provides better throughput than VBR, but is less expensive than CBR. It is important to note that ABR has only recently been fully defined and not all hardware and software support this service category.

Guaranteed QoS allows ATM to support time-sensitive (isochronous) applications, such as video and voice, as well as more conventional network traffic. While 100-megabit Ethernet and other high speed networks can provide comparable bandwidth, only ATM can provide the QoS guarantees required for real-time telephony, VCR-quality video streaming, CD-quality sound, smooth


7

videoconferencing, and other no-delay voice and video applications.

QoS is so vital to the industry that a number of initiatives are underway to provide QoS support for TCP/IP–based networks. One such initiative is the Resource Reservation Protocol (RSVP), a specification proposed by the Internet Engineering Task Force (IETF) that allows software developers to "reserve" bandwidth on the Internet to deliver real-time video and audio data streams. Solutions such as these are useful, but they require that all nodes on the network participate—which can be difficult to guarantee on heterogeneous networks. And, because these solutions shape the traffic in software, latency and variations in delay may be introduced. This is not the case with ATM.

Perhaps most importantly, the acceptance of ATM as a common standard for both LANs and WANs enables enterprise deployment of QoS applications and integrated services. The deployment of ATM/Asymmetric Data Subscriber Line (ADSL) to the home enables residential access to these services. (ADSL uses existing copper twisted pair telephone lines to transmit broadband data to the home, without requiring recabling or a new telephone infrastructure.)

The ATM Adaptation Layer (AAL)The ATM Adaptation Layer (AAL) is responsible for the creation and reception of 48-byte payloads through the lower layers of ATM on behalf of different types of applications. ATM Adaptation is necessary to link the cell-based technology at the ATM Layer to the bit-stream technology of digital devices (such as telephones and video cameras) and the packet-stream technology of modern data networks (such as Frame Relay, X.25 or LAN protocols such as TCP/IP).

There are several different AALs each providing a different class of service:

AAL1—AAL1 provides circuit emulation over an ATM network. This requires constant bit rate, time-dependent service. To provide this, AAL1 adds timestamps, error checking and sequencing to the data payload. Additional functionality is provided in AAL1 to load the 48-byte cell payload with multiple smaller-than-48-byte samples, as might be required with voice streams. Due to its high overhead, AAL1 is used only when these features are required.

AAL2—AAL2 is a mechanism to allow the transfer of high-speed, variable bit rate information in an isochronous, connection-oriented manner. Unlike AAL1, AAL2 is designed to use bandwidth only when data is sent. AAL2 is not fully defined by the standards committee and is not used.

AAL3/4—AAL3/4 is a combination of two separate AAL specifications. AAL3 was intended for the framing of connection-oriented protocols, while AAL4 was intended for the framing of connectionless protocols. While pursuing these two standards, the ATM standards bodies learned that there was no difference in the framing between the two types of protocols; therefore, they combined the two separate framing methods to create AAL3/4. This AAL adds information to the payload regarding segment size, sequencing, and ordering control. This AAL is rarely used because of the high overhead required; AAL5 provides the same services with minimal overhead.


AAL5—AAL5 provides a way for non-isochronous, variable bit rate, connectionless applications to send and receive data. AAL5 was developed as a way to provide a more efficient transfer of network traffic than AAL3/4. AAL5 merely adds a trailer to the payload to indicate size and provide error detection. AAL5 is the AAL of choice when sending connection-oriented or connectionless LAN protocol traffic over an ATM network.


9

Summary of BenefitsIn summary, ATM provides the following benefits as compared to a traditional LAN solution:

Speed—ATM imposes no architectural speed limitations. It uses a pre-negotiated virtual connection, fixed-length cells, message segmentation and re-assembly in hardware, and switching at the hardware level to support fast routing of data.

Guaranteed QoS and support for isochronous traffic—Traffic management at the hardware level ensures that the level of service exists end to end (even over a WAN). Each VC is unaffected by traffic on other VCs. Small packet size and a simple header structure ensure that switching is done quickly and that bottlenecks are eliminated at the switch.

Support for new applications—ATM supports integration of voice, video, and data services on a single network. ATM/ADSL enables residential access to these services.

The next section describes the components that connect an end station to an ATM network.

This short section describes the software components that a single computer (or end station) must use to connect to an ATM network. It also introduces the basic communication processes between an end station and an ATM switch.

To connect to an ATM network, an end station must have the following basic components:

A hardware interface (ATM adapter) Software to interface with the adapter Signaling (connection setup) software Protocol support

Hardware InterfaceThe hardware interface or adapter puts data on the wire and communicates directly with an ATM switch. It has specific functions for handling ATM packet transmission. The main feature that an ATM adapter provides (and that most other adapters do not), is a high level of traffic shaping. An ATM adapter uses the service category and contract negotiated between the end station and the switch to control how fast it sends packets to the ATM switch. The adapter itself doesn’t understand how to negotiate a contract, but once a contract and service category have been established by higher-level processes, the adapter is optimized to enable it to send packets efficiently, based on the level of service specified in the contract.

The ATM adapter uses a wire-based protocol to communicate directly with the ATM switch. Higher-level software does not need to be concerned with this communication. The wire protocol is separate from the ATM specifications.


HOW ATM WORKS –ATM CLIENT SOFTWARE REQUIREMENTS

Examples of wire protocols include Synchronous Optical Network (SONET) and Asymmetric Digital Subscriber Line (ADSL).

Figure 6. ATM Hardware Interface

Basically, the adapter knows only two things: how to communicate with an ATM switch and how to send lots of packets. Because of this, the adapter is able to transmit packets on established permanent virtual circuits (PVCs) only. (A PVC is a manually configured virtual connection that establishes a path from one ATM device to another.) In other words, if you tell an ATM adapter that a certain virtual circuit exists, it can then use it. At the factory, all ATM adapters are configured to understand virtual path zero, virtual circuit 5 to be a default communication line to any ATM switch. As you’ll see in the following section on signaling, this is the virtual circuit used by adapters and switches to negotiate a switched virtual circuit (SVC). A SVC is a network connection created on demand to meet the needs of a specific transmission.

SignalingSignaling components exist at the end station and at the ATM switch. The signaling layer of ATM software is responsible for creating, managing, and terminating virtual circuits (VCs). The ATM standard wire protocol implemented by the signaling software is called User Network Interface (UNI). There is also a standard for the way one ATM switch signals another ATM switch. It is called Network Network Interface (NNI).

Figure 7. ATM Signaling


11

When an ATM-aware process needs to connect to another process somewhere else on the network, it requests the signaling software to establish a VC. To do this, the signaling software uses the signaling VC and the adapter to send a VC creation request to the ATM switch. Each ATM switch forwards the request on to another switch until the request reaches its destination. A switch determines which switch to send the request to next, based on the destination address for the connection and the switch’s internal network database (routing tables). Each switch also determines whether or not the service category and quality of service needs can be met. At any point in this process, a switch can refuse the request. If all of the switches in the path are able to support the circuit as requested, the requesting end station receives a packet that contains the VC number. From that point on, the ATM-aware process can communicate with the destination process directly by sending packets to the VC number identified. For the most part, the originating process doesn’t need to be concerned with whether or not the packets are getting through. (Note that this depends on the service category. In less reliable service categories, the overlying protocol layer may need to monitor packet loss and delay.)

The ATM adapter shapes data traffic for each VC to fit the contract made between the ATM switch and the signaling software. If for any reason too much data is sent, the ATM switch will ignore the data and it will be lost. This is true across the network; if bandwidth or speed exceeds the limits established by the contract, any device—including the ATM adapter—can simply drop the data. And if this happens, the end stations concerned may not be notified of the packet loss.

Point to MultipointSince ATM is a connection-oriented medium, there are no inherent capabilities for broadcasting or multicasting packets as there are in a standard LAN environment. To provide this capability, the sending node could make a connection to all of the destinations and send a copy of the data on each connection. However, this would be highly inefficient. A more efficient way to do this would be through point-to-multipoint connections. This type of connection connects a single source end point (known as the root node) to multiple destination end points (known as leaves). The ATM switches copy cells to the multiple destinations where the connection splits into two or more branches.

Point-to-multipoint connections are unidirectional; the root can transmit to the leaves, but the leaves cannot transmit to the root or to each other on the same connection. Leaf-to-node and leaf-to-leaf transmission requires a separate, likely point-to-point, connection. One reason for this limitation is the simplicity of AAL5 and the inability to interleave cells from multiple payloads on a single connection.

Protocol LayerThe protocol layer of the ATM software is a high layer of abstraction and is concerned more with communicating with higher-level processes and applications than with ATM. The bottom of the protocol layer handles packet transmission and reception, connection requests, and other ATM services. The top of the protocol layer communicates with applications and other networking protocols such as


TCP/IP.

Figure 8. The ATM Protocol Layer

The only applications that communicate with the ATM protocol layer are those that have been written to take direct advantage of ATM features. Currently there are few applications that fall into this category; however, in the near future, many applications and services will communicate directly with the ATM protocol layer. Because of this, the protocol layer is concerned primarily with two things: LAN emulation (LANE) and IP/ATM. These are discussed next.

LAN EmulationLAN emulation (LANE) is a group of software components designed to make ATM work with both legacy networks and applications. With LAN emulation, you can run your traditional LAN-aware applications and protocols on an ATM network without modification. This section explains how LANE works. Later sections describe implementation details of Microsoft’s LANE services.

LAN emulation makes the ATM protocol layers appear to be an Ethernet LAN to overlying protocols and applications. It hides ATM from these applications and protocols and understands standard Ethernet and Token Ring LAN commands. It is a halfway point between fully exploiting ATM and not using ATM at all. It increases the speed and accuracy of data transmission for current applications and protocols (such as TCP/IP); unfortunately, it can reduce the potential of ATM by not exposing native features such as QoS. However, it does allow your current system and software to run on ATM, and it facilitates communication with nodes attached to legacy networks.

LANE in DetailLANE consists of two primary components: the LANE client (LEC) and the LANE services. The LANE client allows LAN protocols and LAN-aware applications to function as if they were communicating with a traditional LAN. The LANE client communicates LAN commands at its top edge and native ATM commands at its bottom (to the ATM protocol layers). The LANE services are a group of native ATM applications that hide the connection-oriented nature of ATM from the connectionless legacy protocols. These services maintain the databases necessary to map the LAN addresses to ATM addresses that the LANE client can use to create connections.

The LANE services components could reside anywhere on an ATM network, but most ATM switches ship with LANE services components installed. Therefore, for


13

practical purposes, LANE services are on an ATM switch (or a group of switches).

The three primary LANE services are the LAN emulation configuration server (LECS), the LAN emulation server (LES), and the broadcast and unknown server (BUS). The LECS handles distribution of configuration information to clients. The LES manages one or more Emulated LANs (ELANs); and is responsible for joining members to the ELAN, maintaining a list of all the members of the ELAN, and handling address resolution requests for the LECs. The BUS handles broadcast and multicast services.

Figure 9. LANE Client, LECS, LES, and BUS

The next few paragraphs explain how a LANE client joins and navigates an ATM network running LANE services.

When the LANE client starts, the first thing it must do is to find the LECS. This is because the LECS will give the client the address of the LES managing the ELAN it will join. The client needs the LES address so that it can communicate with other members of the ELAN. Unfortunately, at initialization there isn’t yet an established connection to any ATM switch, let alone to the switch or other entity that contains the LECS. If the ATM network only has a single ATM switch, and the switch contains all the LANE services, then it’s easy to find the LECS. The network may have multiple switches, however, and the local switch that the LANE client has immediate access to may or may not have LANE services running on it. Fortunately, LANE includes some established mechanisms for a LANE client to discovery the LECS.

LECS DiscoveryThe LANE client can use any of the following techniques when attempting to connect to the LECS:

It can try a well known (defined in the protocol) ATM address.

It can use a well-known VC.

It can query using the Integrated Layer Management Interface (ILMI).

Both the well-known ATM address and the well-known VC are standardized. Most switches and clients are preconfigured with this information, and, in most cases, the LANE client will be able to find the LECS by using one of these two methods. However, these values could have been changed at the end station or at the switch, which would make the either type of discovery unsuccessful.


If this happens, the LANE client can use ILMI, which is a protocol standard (similar to SNMP) that was designed for ATM administrative and configuration purposes. ILMI provides a query function that the LANE client can use to find the LECS address, and then set up a VC to it.

Once the client has discovered the LECS and connected to it, the client asks the LECS to provide configuration information to allow it to connect to a particular ELAN. It does this by sending one or more pieces of information about the desired ELAN; this information may include the LAN type (Ethernet or Token Ring), the maximum packet size, and the name of the LAN.

The LECS takes the information from the LANE client and looks in its table of ELANs, trying to find a match. When it locates the correct ELAN, it returns that address to the LANE client.

LES Address MatchingThe LANE client can now join the ELAN. To do this, it sends an emulated LAN address and its true ATM address to the LES. The LES registers this information. Now the LANE client can send and receive data over the ATM network as if it were using a normal LAN.

When the LANE client receives a request from a protocol (such as TCP/IP) to send information to another point in the ELAN, it sends the destination LAN address to the LES. The LES looks for a match in its database, and then returns the true ATM address to the LANE client. The client then sets up a normal VC between it and the destination, and subsequent data traffic is sent directly on this VC without any further intervention with the LES or the other LANE services. While this address resolution request is being processed, interim traffic is sent to the BUS and fanned out from there to all stations in the ELAN.

If the LES doesn’t find a match, the data is sent to the Broadcast and Unknown Server (BUS).

BUS Distribution The BUS does two different things: it handles distribution of data to unknown clients and it emulates LAN broadcast services. If the LES can’t find a particular ELAN client, the data is sent to the BUS for distribution, and the BUS forwards it to all the clients of the ELAN.

The BUS also handles broadcasts. It does this by registering its address with the LES just like any other client. It registers under the address of F (x16), which is the normal LAN address for a broadcast message. When a LANE client protocol wants to broadcast a message to the entire LAN, it addresses the message to F (x16) and passes it on. The LEC sends this address to the LES for resolution, and the LES returns the ATM address of the BUS. The LEC can then send the message to the BUS. The BUS maintains a list of all clients on the ATM network and sends the message to all clients. Note that the BUS service is usually co-located (in the same piece of equipment) with the LES.


15

IP over ATMIn general, IP/ATM functions in a manner similar to LANE. A central IP server (called an ATMARP server) maintains a database of IP and ATM addresses, and provides configuration and broadcast services. As with LANE, IP/ATM is a group of components that don’t necessarily reside in one place, and, in this case, the services are not usually on an ATM switch. (In some cases, switch vendors provide some IP/ATM support, but not always. For the purposes of this discussion, it is assumed the IP/ATM server services reside on a Windows 2000 server.)

IP/ATM is a very small layer between the ATM protocol and the TCP/IP protocol. As with LANE, the client emulates standard IP to the TCP/IP protocol at its top edge and uses native ATM commands to the ATM protocol layers underneath. IP/ATM is faster than LANE for a variety of reasons. One key reason is that almost no additional header information is added to packets as they are handed down the stack. The IP/ATM client, once it has established a connection, can generally transfer data without modification.

As with LANE, IP/ATM is handled by two main components: the IP/ATM server and the IP/ATM client. The IP/ATM server is composed of an ATMARP Server and Multicast Address Resolution Service (MARS). The ATMARP Server provides services that emulate standard IP functions, while MARS provides broadcast and multicast services. Both services maintain IP address databases just as LANE services do.

The IP/ATM server can reside on more than one computer, but the ATMARP and MARS databases cannot be distributed. You can have one IP/ATM server handle ATMARP traffic, and one handle MARS. Note that if you divided the ATMARP Server between servers, it would effectively create two different IP networks. IP/ATM clients in the same logical IP subnet (LIS) should be configured to use the same ATMARP server. Traditional routing methods are used to route between logical IP subnets, even if they are on the same physical network.

Windows 2000 will ship with fully integrated ATMARP and MARS servers. These services are described in more detail, next.

ATMARP ServerThe IP/ATM client and ATMARP server go through a process similar to the LANE client and the LECS when the client joins the network and discovers other network members. As with LANE, once an address is found, native ATM takes over and TCP/IP packets are sent across a VC from end station to end station. There is, however, a major difference in how the IP/ATM client discovers the ATMARP server.

ATMARP Server DiscoveryBecause the ATMARP server will most likely reside on a server, not an ATM switch, it is not possible to use ILMI or a well-known VC to discover its address. There is no IP/ATM mechanism for server discovery. In effect, to start using IP/ATM, an administrator must find the ATM address of the appropriate ATMARP server and


manually configure each IP/ATM client with this address. In a single ATM switch network, this isn’t much of a problem. For more information on deployment issues, see the section, “ATM Deployment,” later in this document.

Once the ATMARP server has been discovered, the IP/ATM client can use this server to resolve IP to ATM address mappings and communicate with other computers. The ATMARP Server supports unicast traffic only. If a packet is sent to a broadcast address or multicast list, the IP/ATM client will go to the MARS.

MARSAs with the BUS in LANE, MARS handles distribution of broadcast and multicast messages to all the members of the network or to all members of a multicast group. Because of the potential for bottlenecks, MARS provides two modes of operation. If an ATMARP client receives a request to send a packet to a multicast or broadcast IP address, it sends a request to the MARS to resolve this address to a list of clients that are members of that group. In one mode of operation, the MARS return the list of ATM addresses to which the group address resolves. The client then creates a point-to-multipoint (PMP) ATM connection to all of these addresses, and forwards the packet on that connection.

The other mode of operation involves the use of a Multicast Server (MCS). The MCS registers interest in one or more multicast groups with MARS. The MCS receives information as to membership in that group, as well as updates when clients join or leave that group. When the client makes the request for resolution to the MARS, MARS simply returns the single address of the MCS. The packet is then sent to the MCS, which creates the PMP connection and distributes the packet.

The disadvantage of the first method, in which each client sending packets to the group creates its own PMP connection to all other members of the group, is the large number of VCs required. The disadvantage of the second method, which uses the MCS, is that the MCS is a central point of failure and potential bottleneck because it distributes all multicast packets for all of the groups it serves.

See the figures on the next page for an example of the VCs created in each of these modes.


17

Sender 1

MARS

Control Connections Client-MARS

Multicast Data VC (PMP ) - Sender 1 to A ll Receivers

Cluster Control VC (PMP) MARS to A ll Clients

Multicast Data VC (PMP ) - Sender 2 to A ll Receivers

Sender 2

Receiver 3

Receiver 2

Receiver 1

Figure 10. IP Multicast over ATM connections in the absence of MCS


Sender 1

MARS

Control Connections Client-MARS

Multicast Data VC - Sender 1 to MCS

Cluster Control VC (PM P) MARS to A ll Clients

Multicast Data VC - Sender 2 to MCS

Sender 2

Receiver 3

Receiver 2

Receiver 1

MCS

Multicast Data VC (PMP) - MCS to all Receivers

Figure 11. IP Multicast over ATM connections using an MCS

PPP Over ATMWith the advent of Digital Subscriber Line (xDSL) technologies, high-speed network access from the home and small office environment is becoming more of a reality. Several standards are being developed in these areas, including Asymmetric DSL (ADSL) and Universal ADSL (UADSL or DSL Lite). These technologies operate over the local loop (the last run of copper wire between the telephone network and the home). In most areas, this local loop then connects to an ATM core network.

ATM over the xDSL service would preserve the high-speed characteristics and QoS guarantees available in the core, without changing protocols. This would create the potential for an end-to-end ATM network to the residence or small office. This network model provides several advantages, including:

Protocol transparency Support for multiple classes of QoS with guarantees Bandwidth scalability An evolution path to newer DSL technologies

Adding Point-to-Point Protocol (PPP) over this end-to-end architecture adds functionality and usefulness. PPP provides the following additional advantages:

Authentication Layer 3 address assignment


19

Multiple concurrent sessions to different destinations Layer 3 protocol transparency Encryption and compression

In addition, with the adoption of PPP/ATM, little change would be required at the ISP level (ISPs generally use PPP today). If each VC that carries a PPP session carries only one session, each destination will have its own authenticated PPP session, providing per-VC authentication. This provides an extra measure of security. Using Null Encapsulation over AAL5 (because the protocol multiplexing is provided in PPP) can further reduce overhead.

Microsoft provided ATM support in both Windows 95 and Windows NT 4.0, and adoption of ATM hardware has increased steadily. However, until applications and hardware are enhanced to take direct advantage of ATM services, the potential for gains in transmission accuracy and speed will not be fully realized.

Microsoft’s Network Driver Interface Specification (NDIS) as it shipped with Windows 95 and Windows NT 4.0 allowed independent hardware vendors to add any kind of functionality required without having to worry about the operating system, other applications, or other network protocols. All of these components used native NDIS commands to communicate over the network, and it didn’t matter what occurred under the hood. This provided significant advantages for both software and hardware developers. To enable ATM for traditional LAN components, hardware vendors only needed to write small miniport drivers—just enough code to get NDIS communicating with their hardware. Software vendors needed to learn only one set of instructions to get their applications working on the network (NDIS again). This also made it easy for ATM hardware vendors to begin shipping adapters and software early. However, because NDIS was designed to handle connectionless networking environments, it imposed some limitations on ATM integration. And, because applications were still expecting normal LAN functionality, they too had limitations in how they made use of the new ATM networks.


ATM SUPPORT IN WINDOWS 95 AND WINDOWS NT 4.0

Figure 12. Windows 95 and Windows NT 4.0 Monolithic ATM Driver

To make their ATM adapters work with Windows 95 and Windows NT 4.0, hardware vendors wrote monolithic ATM adapter drivers. These drivers not only handled direct hardware communication, but also UNI signaling, LANE support, and in some cases IP/ATM. Unfortunately, this created some problems. Not all of the drivers were written to be compatible with all of the versions of LANE services software on the ATM switches. Most vendors only tested their adapter drivers with their own ATM switches. Moreover, writing and testing a monolithic driver was a very complex undertaking. UNI signaling is a very complicated piece of software, and in many cases, hardware vendors licensed the UNI signaling software from other companies. So, while networks could use ATM, there were reliability issues and the cost of these ATM adapters was initially very high. These issues underscore the negative criticism ATM has received thus far. Other issues include difficulty in configuring ELANs; in some cases, end users were required to specify information such as the maximum packet size, LES address, BUS address, and other information in order to join an ELAN.

However, these issues have to a large degree been resolved with Windows ATM Services, as you’ll see in the next section.

This section focuses on ATM support in Windows 98 and Windows 2000. A high level of integrated ATM support will be included in both operating systems. This section also describes some of the major advantages afforded by this integration.

There are three main areas where Windows 98 and Windows 2000 provide high levels of support for ATM:

APIs and integrated network services for direct access to ATM Support for existing network protocols


21

WINDOWS ATM SERVICES – WINDOWS 98 AND WINDOWS 2000

Broad ATM adapter support

Applications can now directly access ATM services through a new set of ATM APIs made available through several established operating system components, including NDIS, Windows Sockets, and TAPI/Direct Show. Through these interfaces, access to ATM services is now supported in kernel and user mode.

Windows 98 and Windows 2000 also contain a much higher level of integrated support for existing network protocols over ATM. For these new releases, Microsoft has written and tested a universal LANE client, IP/ATM components, PPP/ATM components, a Windows Sockets Service Provider, and UNI signaling modules for end stations. Currently, Microsoft has a test lab with more than 10 different ATM switch vendors, all testing LANE, IP/ATM, UNI, and general interoperability.

Because of this integration and extensive testing, hardware vendors can focus on their hardware and can largely ignore LANE, IP/ATM, PPP/ATM, Windows Sockets support, and UNI. Hardware vendors must write only the small NDIS miniport driver to interface with their hardware because the components formerly required in the monolithic driver are now folded into the operating system. This simplified driver development should reduce the cost of ATM adapters, and, as the cost to the hardware vendor goes down, so will the cost of an ATM adapter to the customer. In addition, this simplification of driver development should facilitate improvements in reliability, and should increase the number of ATM adapters that are supported.

API Support in NDIS 5.0, Winsock 2.0, and TAPIAll of these enhancements are made possible due to extensions to the operating system. The chief extension is a connection-oriented service added to NDIS in version 5.0. NDIS 5.0 (also known as connection-oriented NDIS, or CoNDIS) includes a new API set that will enable applications and protocols to create virtual circuits and specify the quality of service, all through NDIS. CoNDIS supports multiple call managers to enable different media-specific signaling needs, including an ATM-specific call manager. In addition, CoNDIS supports point-to-multipoint connections for efficient multicast services.


Figure 13. CoNDIS Extensions

Two components operate on top of NDIS, integrating ATM services with the rest of the operating system and exposing ATM services through well-known APIs. Windows Sockets 2.0 now has direct ATM support through the Windows Sockets ATM Service Provider. Windows Sockets support through the Windows Sockets ATM Service Provider provides direct access to ATM services from user mode applications. With the addition of IP/ATM support, Windows Sockets applications that use TCP/IP as a transport protocol can be run over ATM networks and inter-operate with standard LAN based IP clients.

TAPI—the Microsoft connection and routing API—has been expanded to handle incoming calls from a telephone line and connect various services including ATM services to that line. TAPI doesn’t handle data, but it can create a circuit and connect that circuit to another device. TAPI redirects calls to a data handler such as the raw channel access filter (RCA), or DirectShow components.

Figure 14. Windows ATM Services


23

Although the new native support for ATM services through Winsock version 2.0 will be attractive to application vendors, TAPI will be of greater interest to integrators who want more than just high bandwidth and good throughput. TAPI, through the NDIS TAPI Service Provider; or TAPI Proxy, now allows you to make NDIS 5.0 calls and redirect them to a stream handler such as the RCA filter. This component maps (or proxies) TAPI call management functions to NDIS 5.0 call management functions, allowing a connection from another medium to be redirected directly to or from ATM.

The next section describes the ATM call manager and how it handles VCs. Subsequent sections cover other Windows ATM Services components. For specific configuration details on any of these services see the section, “ATM Deployment,” later in this white paper.

ATM Call ManagerThe ATM signaling component, also known as the UNI call manager, handles VC creation and management. This section describes how the ATM call manager does its job, specifically with regard to handling of PVCs and SVCs.

How the Call Manager Differentiates PVCs and SVCsPVCs are identical to SVCs except that they are manually configured, device by device, by an administrator. SVCs are dynamically configured at the time they are established. Each device—from end station through one or more switches to another end station—determines its role in supporting a virtual circuit, what device to forward the request to, and whether or not it can guarantee the requested quality of service at that time.

SVCs and PVCs are both stored in the internal tables of the ATM call manager, the ATM adapter, and the ATM switch, and are identical. The difference is in how they are handled at initialization. At initialization, the ATM call manager checks the Registry for any PVCs. If it finds a PVC, it stores its VC number, along with other VC information such as quality of service, the process ID (or more generically, the service access point, or SAP), and the source and destination addresses. It uses a single bit to designate that it is a PVC and not an SVC.

During initialization, the ATM adapter knows nothing of PVCs. Until someone (usually an administrator) configures an application to use a PVC, applications aren’t aware of PVCs either. When an application wants to use a PVC, it uses the provided interfaces to cause an ATM MakeCall command to be issued. The destination address, the quality of service, and the virtual circuit number (among other information) may be provided with the request. Up to this point, the PVC is not handled any differently than a request for a SVC. The call manager receives the MakeCall request and checks the information it received against the entries in its internal table of VCs. If it finds a match and the match turns out to be a PVC (designated by the PVC field in its table), it handles the rest of the process a little differently than it would a request for an SVC.

A normal SVC request causes two NDIS 5.0 commands to be initiated, CreateVC


and ActivateVC. CreateVC is a request to the ATM adapter to determine whether it has the resources to handle another VC. This is done first so that the SVC can be sure the end station itself can handle another VC. There is no reason for a VC request to be sent over the wire until it is determined that the ATM adapter has the resources to support this VC. When the ATM adapter receives the CreateVC command, it stores the VC information, along with a VC number, in its internal tables, and returns a message to the call manager that it can proceed.

The call manager then uses signaling protocol to negotiate the VC setup through each switch in the network to the destination process. Assuming the call parameters are acceptable to all of the network components involved VC signaling completes successfully. The call manager uses an ActivateVC call to notify the adapter that the VC is ready for use. The ATM adapter is notified of the contract that it must adhere to when shaping traffic.

With a PVC, however, the process is handled a little differently. When the call manager receives a MakeCall specifying a PVC, it assumes that the PVC has already been established end-to-end. Therefore, it quickly sends CreateVC and ActivateVC calls in rapid succession to the ATM adapter. The ATM adapter doesn’t need to know that it is working with a PVC. It obtains the quality of service and other information from the CreateVC and ActivateVC commands, and from these commands, determines how it should shape the traffic. From then on, the PVC is used just like a SVC.

LANEIn Windows 2000 and Windows 98, LAN Emulation client services are included in the operating system. When Plug and Play detects an ATM adapter and installs the appropriate driver, this client is also installed by default. This permits full LANE connectivity without the need for configuration, provided that:

The switch has LANE services available and turned on. The LANE services configuration has a default ELAN enabled.

For centralized administration and ease of configuration, this LANE client implementation allows configuration of the ELAN name only. All other ELAN configuration information—such as the MTU, ELAN type, and LES—are obtained from the LECS. If a default ELAN is enabled in the LECS, no configuration is required

For more information on configuring the LANE client, see the deployment section of this white paper.

IP/ATMIP/ATM will be released with Windows 2000. This will enable TCP/IP over ATM to be supported more efficiently than through LANE. IP/ATM is faster than LANE for a variety of reasons, but one key reason is that there is almost no additional header information added to packets as they are handed down. The IP/ATM client, once it


25

has established a connection, can generally transfer data without touching it. IP/ATM is a very small layer between the ATM protocol and the TCP/IP protocol.

IP/ATM exposes some of the features of ATM so that TCP/IP can directly make use of them. With this support provided, applications written to use TCP/IP, through Windows Sockets or otherwise, can also make use of ATM. Applications written to use Generic QoS (GQOS) under Windows Sockets will benefit from this QoS being mapped in IP/ATM to ATM specific QoS parameters.

Microsoft will provide an ATMARP (IP/ATM) client that also supports multicast address resolution via MARS. In addition, Windows 2000 contains a ATM ARP/MARS service that enables Windows NT to act as an ATMARP server and MARS server with integrated Multicast Server (MCS). The MARS configuration allows configuration of the ranges of addresses for which the service will act as an MCS. For deployment and configuration information, see the section, “ATM Deployment,” later in this white paper.

PPP/ATMPoint-to-Point Protocol (PPP) is supported over ATM (for example, ATM over ADSL and ATM over cable). This means that users can dial in and make RAS connections over the telephone, thus taking advantage of telephone companies’ already broad support for ATM services. These enhancements provide high bandwidth even over a telephone line with an ATM adapter and this new level of integrated ATM support. PPP/ATM supports dialup connections over ATM. However, a complete description of this process requires a discussion of TAPI and its function as a universal connection manager and redirector.

In earlier versions of Windows, the NDISWAN component was available to support operation of standard protocol stacks over WAN media and acted as the PPP engine. The NDISWAN component has been extended and the TAPI Proxy component added to provide this same support over NDIS 5.0 connection-oriented media, such as ATM.

At initialization, the NDISWAN component, acting as a client to the TAPI proxy, registers itself as the stream handler for PPP data. When the user starts dialup networking to connect to a network, the dialup networking module communicates with TAPI to make the phone call. When the request is made on an ATM device, TAPI does two things:

1. Through the TAPI proxy and NDIS 5.0, it uses a call manager to make the telephone call through the ATM adapter.

2. When the call goes through, it redirects the connection from the adapter, through NDIS 5.0, to NDISWAN.

NDISWAN then handles further network (PPP) negotiation, and ultimately, through the LAN and TCP/IP stacks, it connects the user’s computer to the remote network. The important thing to note here is that TAPI can make the call and then feed the


resulting connection to another process, in this case NDISWAN.

Because of this connectibility, several new types of applications can be conceived, including those that make use of the RCA filter and Microsoft DirectShow technology.

DirectShowMicrosoft developed the DirectShow technology to better integrate multimedia services and to enable multimedia developers to more easily customize the system to their needs. DirectShow allows hardware and software vendors to create individual multimedia modules called filters. Multiple filters can be connected by the use of pins and a filter graph. (Note that the language used here is the same that is used to describe the Component Object Model [COM], a high-level specification for designing fully independent and object-oriented software.) The key point here is that TAPI connects different components, and DirectShow uses the same approach to enable filters and devices to connect to each other.

Figure 15. Windows COM-based DirectStreaming

DirectShow has an RCA filter—a simple module that exposes the raw data, whether it is voice, video, or other, to any device that wants to handle it. With NDIS 5.0, the RCA filter can be connected to TAPI. And, NDIS 5.0 can export ATM VCs as DirectShow pins.

Weather Report ApplicationAn example of using DirectShow and RCA support in Windows ATM services is a weather report application that delivers up-to-date weather report information over the telephone. Customers can simply dial a number and hear a recorded message.

Here’s how this might work:

1. At initialization, the RCA filter registers as the stream handler for voice data.

2. A user calls a number to get the current weather report.


27

3. TAPI receives the call. TAPI redirects the incoming call to the RCA filter, by virtue of it being a voice call.

4. NDIS 5.0 maps the DirectShow pin to the VC number.

5. DirectShow plumbs the filter graph, and the stream starts.

Figure 16. Weather Report Application Using DirectShow RCA Filter

IP Phone AccessSimilarly, a user could make a telephone call that would be routed across a traditional LAN. This could enable such things as IP-based telephones. Again, TAPI handles the incoming call and uses NDIS 5.0 to connect it to a pin. Then, DirectShow reformats the data using a real-time protocol (RTP) filter that goes through UDP/IP to ultimately reach an Ethernet card. The resulting connection allows a telephone user to talk to a computer user. This blurs the boundaries between telephone and computer networks considerably.

Potential Future Additions to Windows ATM ServicesEnhancements to Windows ATM Services are being considered for addition to later releases of Windows operating systems. These include the following.

UNI 4.0 Call Manager Support—The UNI 4.0 signaling specification from the ATM forum specifies enhancements to UNI 3.1, including QoS negotiation during call setup, support for ABR service class, and leaf-initiated join of a point-to-multipoint VC.

LAN Emulation version 2 (LANEv2) —LANEv2 extends LANE capabilities. LANEv2 adds support for such things as more efficient handling of multicast frames, support for QoS on LANE Data VCs, and support for multiplexing


multiple data flows (and possibly multiple protocols) over a single VC using LLC SNAP encapsulation. (LANEv1 only supported non-multiplexed VCs and a VC was required for each flow.) In addition, Multi-Protocol over ATM (MPOA) requires some of the features provided in LANEv2; therefore, this support will be required if MPOA support is added.

Multi-Protocol Over ATM (MPOA) —LANE provides a mechanism for intra-subnet communication over ATM. Inter-subnet communication must still use routing for communication. The addition of MPOA client (MPC) components to the end stations and MPOA server (MPS) support to the routers on the network allows unicast data paths to cut through the ATM switch network, eliminating the possible overhead of multiple router hops. MPOA detects data flows through an emulated network and uses the IETF Next Hop Resolution Protocol (NHRP) to determine the final ATM-attached destination. This information can then be used to set up a direct SVC through the ATM to the destination.

The following section provides information on ATM deployment in a variety of situations. Depending on your configuration, you may or may not need to read all of these sections.

Configuring LAN EmulationBy default, LAN Emulation is configured on the ATM adapter. All protocols that can run over an Ethernet or Token Ring network can run over ATM LAN Emulation. Windows ATM LANE is relatively easy to configure, and can adequately accommodate the communication requirements of most networks.

If you have a single switch and a Windows 98 or Windows NT client, setting up LANE connectivity is fairly easy. Microsoft is encouraging all switch vendors to supply their switches with a default configuration that will allow a Windows client to immediately begin using LANE services practically out of the box. If the ATM switch is not configured this way by default, you’ll need to make sure all of these services are running and configured in this manner (configuration mechanisms and options depend upon the switch vendor).

The default configuration is as follows:

1. By default, enable LANE, including an LECS, LES, and BUS.

2. In the LECS, support discovery through the well-known address, the well-known VCI and VPI, and ILMI.

3. Create an ELAN associated with a LES. Base the ELAN name, LAN type, and maximum packet size on the legacy clients it will be communicating with (for example, Marketing, Ethernet, 1516). The switch may require you to separately create a BUS for the LES. The Microsoft LEC supports either co-located or separate BUS addressing.

When an ATM adapter is installed on a Windows 98 or Windows 2000 computer, the Plug and Play module automatically detects it and begins initializing for LANE


29

ATM DEPLOYMENT

client services. At the end of this initialization, the LANE client is running and the rest of the system believes it now has a traditional Ethernet card available. The Windows LANE client is preconfigured to function with the switch default configuration above. If the defaults are in place, the computer will be able to participate in the default ELAN.

At this point, you can begin using the user interface on the ATM switch to configure whatever LAN topologies you require (if you require more than the default ELAN).

Note: Windows 98 allows only one ELAN to be connected, but with Windows 2000, multiple ELANs can be connected. Therefore, a multi-ELAN domain can be created that allows a Windows 2000 computer to provide services to multiple ELANs, all without any ELAN members seeing outside of their ELANs.

If you have multiple ATM switches, some extra configuration may be required. If one or more switches in the network separate the LANE client and LECS, LECS discovery can become difficult. Without additional configuration, ILMI can only identify the LECS if it is on the same switch to which the LANE client is directly connected. If the LECS is on another switch, the ILMI database on all other switches must include an entry for the LECS. This guarantees that at least through ILMI, the clients will be able to find the LECS.

If you want clients to be able to find the LECS using the well-known ATM address, you’ll need to establish routes for this address. (LANE Services in most switches allow for pointers to another switch’s LECS address when the LECS is specified not to be local.)

The well-known VCI and VPI only work with the switch to which the client is directly connected. These can be configured via PVC to lead to the LECS.

When there are multiple switches, you should not have more than one running the LECS. Most switch implementations will not allow this; moreover, this type of implementation renders your routes to the well-known address useless. If you choose to have more than one switch running the LECS, each switch must point to the same LES for the same ELANs. In other words, if you have an ELAN named “Blue” and you have two switches running the LECS, both should point to the LES that holds the Blue ELAN. Otherwise you’d be creating two separate ELANs named Blue. As the LES can reside anywhere on the network, so can the BUS. Again, the only important consideration is that the address of the BUS be correct.

Configuring the LANE ClientIf you have multiple ELANs and need to configure the client to participate in other than the default ELAN, you will need to configure the LANE client. This white paper includes procedures for doing this for Windows 2000; however, Windows 98 procedures are very similar.

If you are using one of the ATM adapters that was supported in Windows NT 4.0, your previous monolithic driver will not be used when you upgrade to Windows 2000. Instead, Plug and Play will detect your card and load the updated


NDIS 5.0 ATM miniport driver for your adapter to use, along with the Microsoft ATM UNI call manager (for signaling over ATM), the Microsoft ATM LAN Emulation service, and other Windows ATM service components.

As described earlier in this paper, in Windows NT 4.0, a few ATM adapters were supported by means of a monolithic NDIS driver. This driver included all support necessary for LAN emulation over ATM using Windows NT (including integrated modules for LANE client service, ATM UNI signaling, as well as the ATM hardware interface). In Windows 2000, the ATM UNI signaling component and LANE client services are included in the operating system. The adapter vendor need only write a small NDIS 5 mini-port driver that provides the necessary hardware interface functionality needed to support their specific ATM hardware implementation. Because of this change, some LAN emulation information that was previously configured in the Windows NT 4.0 monolithic ATM LANE drivers will be lost after you upgrade to Windows 2000. This lost configuration information may include:

The Emulated LAN (ELAN) name The LAN media type (Ethernet or Token Ring) to be emulated on the ELAN ATM addresses for the LAN Emulation Server (LES) and Broadcast and

Unknown Server (BUS) associated with the ELAN Maximum allowable packet size for the ELAN

In Windows 2000, the ATM LANE client module allows only the ELAN name to be exposed and configurable. All of the other parameters of the ELAN, as listed above, are obtained from the LECS on the ATM switch. At system initialization, the ATM LANE client module uses the well-known address to register with the LECS. The LANE client identifies the ELAN it wishes to join by passing the configured ELAN name. The LECS returns all configured parameters of the specified ELAN to the LANE client.

The Windows 2000 ATM LANE client can be configured as a member of one or multiple emulated LANs. Consequently, before you upgrade from Windows NT 4.0 to Windows 2000, complete the following steps.

1. Note any of the parameters (from the list above) that may have been configured for the Windows NT 4.0 monolithic ATM LANE driver.

2. From your ATM switch, use the LES user interface to configure ELANs and all associated parameters (ELAN name, media type, LES/BUS ATM addresses, and maximum packet size).

3. Install Windows 2000, and configure the ELAN name.

To configure the ELAN membership for a client:

1. On the desktop, click My Computer.

2. Click Network Connections.

3. Click the ATM Connection that corresponds to the ATM network adapter installed on this computer. The Device Name column containing the device


31

name of the ATM adapter installed on this machine can help you to identify the correct connection. If you do not see these columns, you may need to select the Details view from the View menu.

4. Right-click this connection, and select Properties. The following dialog box will be displayed.

5. In the list of network components used in this connection, click ATM LAN Emulation Client, and then click Properties. The following dialog will be displayed.


6. If needed, further configure the list of emulated LANs available for use with this ATM connection by adding the ELAN name. The <unspecified ELAN name> listing instructs the client to use the default ELAN.

LANE Client Fault ToleranceIf the LECS or LES fails for some reason, the Windows LANE client completely restarts its initialization at the point of LECS discovery. Therefore, if for some reason the LANE servers fails and then restarts, the LANE client automatically reregisters itself properly without any interaction from users. Ultimately the fault tolerance responsibility lies primarily with the LECS and LES. The LANE client only detects a fault and restart.

Some switches may allow a backup LECS or LES to be ready and waiting to come online if the current server goes down. If this happens, the backup LECS can register at the same well-known address as the failed LECS, and all clients will find it.

IP/ATMAs with LANE, in a single ATM switch situation, clients should immediately be able to make use of the ATM network via IP. In this situation, however, Windows NT Server 5.0 will provide the ATM ARP/MARS service. This service does not install by


33

default; therefore, an administrator must install it.

To install this service, proceed as follows.

1. On the desktop, click My Computer


3. Click the Local Area Connection that corresponds to the ATM network adapter installed on this computer. The Device Name column containing the device name of the ATM adapter installed on this machine can help you to identify the correct connection. If you do not see these columns, you may need to select the Details view from the View menu.

4. Right-click this connection, and choose Properties.

5. Click Add.

6. In Select Component Type, click Protocol from the list of network component types, and then click Add.

7. In Select Network Protocol, click ATM ARP/MARS Service in the list of network protocols, and then click OK.

8. The ATM ARP/MARS service will now be installed (with the Windows 2000 default configuration).

This service and the Windows clients are all pre-configured to use a well-known ATM address. The first thing that the server does is to register this address with the ATM switch. Windows 2000 uses the following default pre-configured address:

4700790001020000000000000000A03E00000200

This number is a well-known address that Microsoft has reserved and uses to reduce and simplify configuration and interoperability of ATM ARP/MARS service with other Windows 2000 computers that are also running Windows ATM Services.

The ATM ARP/MARS service includes a pre-configured default list of IP address ranges for which broadcast and multicast forwarding will be provided by the service acting as an MCS.

When operating in this mode, the ARP/MARS service will provide its own ATM addresses to requesting clients in the form of a multicast server (MCS) list value. Where clients are provided this list, the ARP/MARS service on this computer will then be used as the MCS by clients to provide active forwarding of all multicast and broadcast traffic destined for IP addresses contained within the ranges specified in the list. The service will then establish point—to-multipoint virtual connections on behalf of requesting clients (multicast group members) to perform the actual multicast sending to addresses described within the list.

If the list is empty, the ATM ARP/MARS service will act as a MARS server only. In this mode, the service will not perform any forwarding for multicast group clients. Instead, the service will return a dynamic listing of ATM hosts currently registered


for this multicast group address to requesting clients. Clients will then use this list information to initiate and establish their own point-to-point virtual connections with each of the group members to send the actual multicast to addresses described within the list.

To configure the list of addresses the service will support as an MCS, perform the following steps.



3. Click the Local Area Connection that corresponds to the ATM network adapter installed on this computer. The Device Name column containing the device name of the ATM adapter installed on this machine can help you to identify the correct connection. If you do not see these columns, you may need to select the Details view from the View menu.

4. Right-click this connection, and choose Properties.

5. In the list of network components used in this connection, click ATM ARP/MARS Service, and then click Properties. The following dialog will be displayed.

6. Using this dialog, you can configure the address or addresses where the service


35

will respond and the multicast address ranges for which the service will act as a MCS. Note that by default, the ATM ARP/MARS service acts as a MCS for all multicast and broadcast addresses.

The clients are configured to use the default ATM address listed above. If a different address is to be used, the client must be configured with this new server address. In a multiple switch situation, clients must also be informed of the IP/ATM server address in another way.

Windows 2000 IP/ATM server includes a standard ATM address that is the same address included in the Microsoft IP/ATM client. The administrator can use the ATMADM command line utility to discover the ATM address. To view the ATM adapter address on any ATM-attached computer, type the following at the command prompt:

atmadm –a

Then, the administrator can publish the ATM address or use email to send it to the IP/ATM clients. The client has a user interface that allows you to specify a MARS and ATM ARP address. This can be configured in the following manner.



3. Select the ATM Connection that corresponds to the ATM network adapter installed on this computer, and then right-click Properties.

4. From the list of network components, click Internet Protocol (TCP/IP), and then click Properties.

5. In Internet Protocol (TCP/IP) properties, click Advanced.

6. Click the ATM ARP Client tab. The following dialog will be displayed.


7. If you want TCP/IP to be used only over permanent virtual circuits (PVCs) configured using the ATM call manager, select PVC Only.

8. For the ARP Server Address List, use the Add, Edit, and Remove buttons to update the list with entries for any ATM ARP servers on your network. If you add server addresses, use the up and down arrow buttons to reorder the list.

9. For the MARS Address List, use the Add, Edit, and Remove buttons to update the list with entries for any ATM Multicast Address Resolution Service (MARS) servers on your network. If you add server addresses, use the up and down arrow buttons to reorder the list.

10.use, such as multiple IP addresses, DNS servers, or WINS servers, and then click OK.

11.the default to use a DHCP server to obtain an IP address.

12.Connection properties for this connection.

By default, the ATM ARP and MARS services run on the same computer. However, you can optionally run the ATM ARP/MARS Service on multiple computers and use


37

the above steps to direct different TCP/IP clients to different computers for their ARP and MARS services. Be aware, however, that all TCP/IP clients that need to communicate with each other must be directed to the same ARP and MARS services.

Some ATM switches support ATM ARP and/or MARS services. If your ATM switch supports ATM ARP or MARS, you may not need to run the Windows ATM ARP/MARS service. In this case, direct your TCP/IP clients to the ATM address assigned to the ATM ARP or MARS services resident on the ATM switch. Note however that some ATM switches support MARS support IP multicast only, and do not support IP broadcast. If this is the case, you may not want to use the ATM switch-resident MARS service since some network applications, such as Windows File and Print Services, require IP broadcast.

As with networks that use LANE, in a multiple switch situation you need to configure routability. IP/ATM only provides two discovery mechanisms. One is similar to the well-known address, and routability must be configured for it to work properly. The other method of discovery is to manually configure each client with the IP/ATM server (Windows NT server box) ATM address. You can use the ATMADM utility to discover the address, and then publish the address or cut and paste it into email and send it to the clients.

Note: TCP/IP can be bound to the IP/ATM adapter (the ATM adapter as IP) and NetBEUI can be bound to the LANE adapter (the ATM adapter as Enet), all at the same time.

The ATMADM UtilityThe ATMADM is provided with Windows ATM Services to assist in troubleshooting. This utility can be used to retrieve information about the operation of ATM in your system. It will display ATM address information, ATM Statistics, and the current state of all ATM connections. For options available type:

atmadm -? <enter>

Other tools and utilities are planned but not yet completed.

Using PVCsA client needs to have the following information before it can use a PVC.

It needs to know how to identify the PVC; therefore, it needs the VPI and VCI. It needs to know the QoS attributes so that the ATM adapter can shape

outgoing network traffic accordingly. It needs to know what application or process is going to use the PVC. This

equates to the process ID, or more generically, the service access point (SAP).

The key component to PVC usage is the ATM call manager. It reads the Registry to discover PVCs at initialization. It also checks for matches when an application registers its SAP. If a match occurs, the call manager immediately sends an


incoming call to the application. This is a manufactured incoming call and only serves to tell the application that the PVC exists. Note that the application doesn’t really know whether it is a PVC or an SVC.

The application can make use of a PVC by registering its SAP using a RegisterSAP call. However, It can also make use of a PVC by using the NDIS provided MakeCall function. There are several ways a PVC can be identified in MakeCall.

MakeCall contains both local SAP and destination SAP parameters. It also provides a PVC flag. If the flag is set, then the call manager knows that it is dealing with a PVC and will register the VC in its table accordingly.

If either of the SAPs in MakeCall match one of the PVCs in its tables, the call manager can identify it as a PVC as well.

An application can use a PVC under any of the following conditions:

The application doesn’t know about the PVC. The call manager knows about the PVC and knows the local SAP. When the application registers its local SAP, the call manager matches the SAP, and sends an incoming call to the application.

The application doesn’t know about the PVC. The application sends a MakeCall that identifies both its local SAP and the destination SAP. The call manager finds a match and immediately returns an IncomingCall to the application.

The application knows about the PVC. It sends a MakeCall with the PVC flag set, and the call manager acts accordingly.

In Windows 98 there is no user interface (UI) for configuring PVCs. However, Windows NT does provide such a UI. It comes with several predefined PVC types, such as IP/ATM and an option to define a custom PVC. If you used a prepackaged type, you shouldn’t have to supply much configuration information. However, if you choose a custom PVC, then you have the option of entering in all the information you want: VPI, VCI, QoS, upstream and downstream SAPs, and so on.

While Windows 98 does not provide a UI for configuring a PVC, it does allow you to use standard Win32 programming interfaces to configure a PVC. Note that PVC information is stored in the Registry. Although Microsoft does not recommend that you manually configure the Registry, the PVC Registry entry format is included here for your information.

Registry Parameters – Windows 98On Windows 98, the ATMUNI parameters for a particular ATM adapter are located in the following Registry key.

HKEY_LOCAL_MACHINE \Enum \Network \ATMUNI

ATMUNI contains a list of subkeys (0000, 0001, and so on) that each represent an


39

adapter to which ATMUNI is bound. Under each of these subkeys, the Driver key contains a string of the form

NetTrans\0004

This string represents the subkey under

HKEY_LOCAL_MACHINE \System \CurrentControlSet \Services \Class

that contains all ATMUNI parameters for the desired adapter. In this example, all PVC parameters for the adapter are under the key

HKEY_LOCAL_MACHINE \System \CurrentControlSet \Services \Class \NetTrans \0004 \PVC

For each PVC, a subkey must be created under the PVC section. The name of the subkey is not relevant. For example, on Windows 98, you could create two PVC subkeys as follows.

On Windows 98:

HKLM\System\CurrentControlSet\Services\Class\NetTrans\0004\PVC\PVC0\/* All parameters for PVC # 0 */HKLM\System\CurrentControlSet\Services\Class\NetTrans\0004\PVC\PVC1\/* All parameters for PVC # 1 */PVC Parameters

You would then need to define the parameters for each PVC. These parameters are listed in the following table. PVC parameters are stored as Registry keys under each PVC subkey (PVCi in the preceding example). See structure Q2931_ADD_PVC in atm.h for more information.

Note that (O) is an optional parameter and (M) is mandatory. Optional fields are those that need not be present in the Registry. For these, the call manager uses defaults as indicated below.


Key Name Data Type Comments

(O)VPI REG_DWORD VPI Default: 0(M)VCI REG_DWORD VCIMedia Parameters(O)AALType REG_DWORD 8 for AAL 5 (see

AAL_TYPE_AALx in atm.h) Default: 8

(O)TransmitPeakCellRate REG_DWORD Cells per secondDefault: Maximum outbound line rate for the adapter


(O)TransmitAvgCellRate REG_DWORD Cells per second Default: Maximum outbound line rate for the adapter

(O)TransmitCellBurstLength REG_DWORD Cells Default: Maximum packet size supported by adapter

(O)TransmitMaxSduSize REG_DWORD Bytes Default: Maximum packet size supported by adapter

(O)TransmitServiceCategory REG_DWORD ATM Service Category (see below) Default: 4 (UBR)

(O)ReceivePeakCellRate REG_DWORD Cells per secondDefault: Maximum inbound line rate for the adapter

(O)ReceiveAvgCellRate REG_DWORD Cells per second Default: Maximum inbound line rate for the adapter

(O)ReceiveCellBurstLength REG_DWORD Cells Default: Maximum packet size supported by adapter

(O)ReceiveMaxSduSize REG_DWORD Bytes Default: Maximum packet size supported by adapter

(O)ReceiveServiceCategory REG_DWORD ATM Service Category (see below) Default: receive defaults

Addresses(O)CalledParty REG_SZ Called ATM address to match

NdisClMakeCall Default: wild-card (matches any address)

(O)CallingParty REG_SZ Calling ATM address to match registered SAP


41

Default: Wild card (matches any address)

Broadband Low Layer Information (BLLI)(O)LocalLayer2Protocol REG_DWORD BLLI field for local SAP

Default: SAP_FIELD_ABSENT (0xfffffffe)



(O)LocalUserSpecLayer2 REG_DWORD BLLI field for local SAP Default: 0

(O)LocalLayer3Protocol REG_DWORD BLLI field for local SAP Default: SAP_FIELD_ABSENT (0xfffffffe)

(O)LocalUserSpecLayer3 REG_DWORD BLLI field for local SAP Default: 0

(O)LocalLayer3IPI REG_DWORD BLLI field for local SAP Default: 0

(O)LocalSnapId REG_BINARY BLLI field for local SAP (5 bytes) Default: All zeros (0)

(O)DestnLayer2Protocol REG_DWORD BLLI field for destination SAP(O)DestnUserSpecLayer2 REG_DWORD BLLI field for destination SAP(O)DestnLayer3Protocol REG_DWORD BLLI field for destination SAP(O)DestnUserSpecLayer3 REG_DWORD BLLI field for destination SAP(O)DestnLayer3IPI REG_DWORD BLLI field for destination SAP(O)DestnSnapId REG_BINARY BLLI field for destination SAPBroadband High Layer Information (BHLI)(O)LocalHighLayerInfoType REG_DWORD BHLI field for local SAP

Default: SAP_FIELD_ABSENT (0xfffffffe)

(O)LocalHighLayerInfo REG_BINARY BHLI field for local SAP Default: All zeros (0)

(O)DestnHighLayerInfoType REG_DWORD BHLI field for destination SAP Default: SAP_FIELD_ABSENT (0xfffffffe)

(O)DestnHighLayerInfo REG_BINARY BHLI field for destination SAP Default: All zeros (0)

Note: ATM Service Category values are listed below (see ATM_SERVICE_CATEGORY_XXX in atm.h)

CBR: 1 VBR: 2 UBR: 4 ABR: 8

Deployment ScenariosThe following examples describe some of the more typical ATM deployments in enterprise networks.

ATM Core with Ethernet EdgeOne of the most common initial deployments of ATM will likely be in the core or backbone of the network. This allows you to establish the groundwork for a future


43

ATM migration to the desktop. Once you have installed the core ATM services, you can use edge devices (such as routers) to connect legacy LAN segments to the core. In this configuration, Windows NT can act as a router by using the Routing and Remote Access service.

The high-speed backbone will provide a high quality, QoS-enabled infrastructure for the enterprise network. Your next step could be to enable the servers to take advantage of this increase in bandwidth. If your servers are on the other side of an edge device and the clients are behind another edge device, the data must pass through two routers before it reaches its destination. This routing is expensive in terms of additional latency added to the data path. In addition, the server will likely be on a relative low-speed pipe, perhaps 100 megabits per second (Mbps) Ethernet.

Moving your server to the core will reduce the routing needed to reach the server from any segment. In addition this move will give the server a larger data pipe to work with. You can then enable LAN Emulation and/or IP/ATM services on the server to further your connectivity options.

With multiple segments connected to the core network through individual switches, the access to that core can be controlled with QoS instrumented PVCs. This allows you to perform bandwidth management on the core, controlling how much bandwidth each segment can use.

ATM to the DesktopDeploying ATM all of the way to the desktop provides a platform for QoS application deployment. While the Windows 2000 implementation of TCP/IP will allow you to implement QoS by using RSVP, there are some limitations inherent in this solution. With the TCP/IP–RSVP solution, all components of the path must participate to ensure that QoS is maintained from end to end. Additionally, the packet scheduling is implemented in software, which can introduce some latency into the traffic. Moreover, the solution is not deterministic—it does not provide predictable, guaranteed quality of service. These issues are overcome with end-to-end ATM and hardware traffic shaping.

The Windows Sockets ATM Service provider allows many applications to work directly over ATM. Currently, applications are being written to take advantage of this provider, and existing applications can be modified to use it as well. One example of an application that uses this interface is Microsoft NetShow Theater Server, a broadcast-quality video server developed to deliver time-sensitive, low-latency video on demand.

IP/ATM makes it even easier for existing applications to make use of the QoS capabilities provided by ATM. When an application provides a Windows Sockets QoS flow specification, IP/ATM passes this information to the ATM signaling component, which can then translate the specification into call setup parameters. Both Microsoft NetShow and Microsoft NetMeeting do this today. The ATM interface is also exposed through TAPI (via the TAPI Proxy component) and DirectShow (via


the RCA filter), which greatly simplifies integration of data, voice, and video services. And because LANE Client and ATM ARP/MARS are standard components, existing applications continue to work in this environment unfettered.

Residential/SOHO Access with ATMDial-up networking using PPP has become a standard way of communicating over the Internet or with a corporate network. This support can be provided over ATM adapters connected to the public network that use xDSL technologies as the physical layer medium. The PPP/ATM support provided in Windows ensures that this functionality is provided. There are such compelling reasons for this that the working group responsible for Universal ADSL (the Universal ADSL Working Group or UAWG) has established PPP/ATM/UaDSL as their end-to-end protocol architecture standard.

By implementing content servers over native ATM through Windows Sockets, content such as Video on Demand can be provided to the home with ATM/ADSL. This opens the door to providing new varieties of commercial services requiring guaranteed QoS.

Key ConsiderationsWhen you are considering deploying ATM and Windows ATM Services, there are many questions that should be taken into consideration. Some of those questions are presented here.

What level of QoS do you need? Do you need to extend your QoS applications(s) over the WAN? To employee

homes? Do you want to integrate services (telephone, computer) on a single network? What is the existing infrastructure? Is legacy LAN support needed? Do you want to segment your network into multiple virtual LANs? Do you need to manage usage of your network backbone bandwidth?

We are at an exciting time in terms of network infrastructures. The cost of maintaining separate, specialized networks for computer, voice and video is too high. However, current technology is enabling us to integrate all of these services on a single network, and also to combine our existing networks into a single infrastructure. Although pieces of this message have been floating around for at least three years, it is only now that the different levels of necessary support are available. The telephone companies have put in place almost universal ATM support. Companies and the Internet have established infrastructure and protocols, and now the Windows operating systems can provide rich connectivity using ATM while maintaining support for legacy systems.

To support native ATM, Microsoft updated NDIS with native ATM commands. Because many applications don’t yet use native ATM services, Microsoft added LANE support for LAN applications (Ethernet and so forth). Similarly (and to


45

CONCLUSION

eliminate the additional header cost of LAN packets), Microsoft added IP/ATM support. Because many applications use Windows Sockets, Microsoft added WinSock 2.0 native ATM. And, to provide complete ATM support, Microsoft added circuit connectivity to TAPI, our connection management protocol. TAPI can now make and receive calls and can redirect them to ATM circuits or from circuits into devices or other network types. Examples of this include PPP/ATM as the dial-up/RAS on ATM, which is connected by TAPI, and DirectShow. TAPI can connect an RCA filter containing video, and send it over an ATM circuit.

These enhancements allow applications to exploit ATM services, such as QoS, and, with the use of TAPI, a high level of integration between established multimedia features and network protocols can be achieved.

For More InformationFor the latest information on Microsoft Windows, visit our World Wide Web site at http://www.microsoft.com/windows and the Windows NT Server Forum on the Microsoft Network (GO WORD: MSNTS).


http://www.microsoft.com/windows

windows atm services - itwelzel.bizgwise.itwelzel.biz/microsoft/windows 2000 server... · web...

Documents