Windows ATM Services 2

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 Emulation

LAN 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 Detail

LANE 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 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 Discovery

The 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 Matching

The 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.
IP over ATM

In 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 Server

The 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 Discovery

Because 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.

MARS

As 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.





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





Figure 11: IP Multicast over ATM connections using an MCS
PPP Over ATM

With 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
*

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.
Top Of Page
ATM Support In Windows 95 and Windows NT 4.0

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 driversjust 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.




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.
Top Of Page
Windows ATM Services Windows 98 and Windows 2000

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
*

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 TAPI

All 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.

TAPIthe Microsoft connection and routing APIhas 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

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 Manager

The 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 SVCs

PVCs 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 devicefrom end station through one or more switches to another end stationdetermines 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.
LANE

In 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 informationsuch as the MTU, ELAN type, and LESare 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/ATM

IP/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 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/ATM

Point-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.
DirectShow

Microsoft 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 filtergraph. (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 filtera 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 Application

An 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.
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 Access

Similarly, 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 Services

Enhancements 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 SupportThe 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.

Top Of Page
ATM Deployment

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 Emulation

By 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 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 Client

If 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 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.





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 listing instructs the client to use the default ELAN.

LANE Client Fault Tolerance

If 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/ATM

As 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 default; therefore, an administrator must install it.

To install this service, proceed as follows.

1.

On the desktop, click My Computer
2.

Click Network Connections.
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 pointto-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.

1.

On the desktop, click My Computer
2.

Click Network Connections.
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 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.

1.

On the desktop, click My Computer
2.

Click Network Connections.
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.

Configure any other advanced TCP/IP properties that this ATM connection will use, such as multiple IP addresses, DNS servers, or WINS servers, and then click OK.
11.

If needed, specify a static IP address for use with this ATM connection or accept the default to use a DHCP server to obtain an IP address.
12.

Click OK to accept your TCP/IP settings, and then click OK again to exit ATM 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 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 Utility

The 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 -?

Other tools and utilities are planned but not yet completed.
Using PVCs

A 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 98

On 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 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: ATM Service Category values are listed below (see ATM_SERVICE_CATEGORY_XXX in atm.h)

*

CBR: 1
*

VBR: 2
*

UBR: 4
*

ABR: 8

Deployment Scenarios

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

ATM Core with Ethernet Edge

One 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 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 Desktop

Deploying 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/IPRSVP 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 deterministicit 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 ATM

Dial-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 Considerations

When 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?

Top Of Page
Conclusion

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 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.