Asynchronous Transfer Mode
Asynchronous Transfer Mode |
|
The cost of maintaining separate, specialized networks for computer, voice, and video is high. Fortunately, current technology enables integration of all of these services on a single network and the combination of existing networks into a single infrastructure. In particular, Windows operating systems 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 do not yet use native ATM services, Microsoft added LANE support for LAN applications (Ethernet and so forth). Similarly, Microsoft has added IP over ATM support, thereby eliminating the additional header cost of LAN packets. Microsoft also added Winsock 2.0 native ATM to support the many applications that use Windows Sockets (Winsock).
Furthermore, Microsoft has added circuit connectivity to TAPI (connection management protocol) in order to provide complete ATM support. TAPI can now make and receive calls and can redirect them to ATM circuits or from circuits into devices or other network types. Examples include Microsoft® DirectShow®, as well as PPP over ATM as the dial-up remote access protocol on ATM. Using the raw channel access (RCA) kernel streaming filter, TAPI can be used to connect a data stream to the RCA filter containing video, and send it over an ATM circuit, as shown in Figure 14.16.
Figure 14.16 Windows ATM Services
These enhancements allow applications to exploit ATM services (such as QoS), and with the use of TAPI, achieve a high level of integration between established multimedia features and network protocols.
The next section describes the ATM call manager and other Windows ATM services components.
The ATM signaling component, also known as the UNI call manager, handles virtual circuit creation and management. This section describes how the ATM call manager does its job, specifically with regard to the handling of both permanent and switched virtual circuits.
Permanent virtual circuits (PVCs) are almost identical to switched virtual circuits (SVCs), but each PVC must be manually configured, device by device, by an administrator. In contrast, SVCs are dynamically configured when they are established. Each device — from a starting endstation through switches to another endstation — independently 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. PVC resource allocations are set aside the moment they are first configured, whether or not they are used immediately. SVC resource allocations are allocated dynamically.
The SVC and PVC values are both stored in the internal tables of the ATM call manager, the ATM adapter, and the ATM switch, and the kind of values stored in those tables are identical. The difference between the two kinds of circuits lies in how the circuit values are handled at initialization. At that time, the ATM call manager checks the registry for any PVCs. If it finds one, 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), 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 does not know about PVCs. Until someone (usually an administrator) configures an application to use a PVC, applications are not aware of PVCs either. When an application wants to use a PVC, it issues an ATM command through its provided interfaces. The request specifies the destination address, the Quality of Service, and the virtual circuit number (among other information). Up to this point, the PVC is handled exactly as if it were a request for an SVC. The call manager receives the request and checks the information received against the entries in its internal table of VCs. If it finds a match and the match is designated as a PVC in the PVC field in its table, the call manager then handles the rest of the process a little differently than it would for an SVC request.
A normal SVC request initiates two commands; the first determines whether the adapter can handle another VC, and the second activates the VC along the path of network components. A PVC request, however, works a little differently. When the call manager receives a request specifying a PVC, it assumes that the PVC has already been established end-to-end. Therefore, it sends the two initiating calls in rapid succession to the ATM adapter. The ATM adapter never knows that it is working with a PVC. It obtains the Quality of Service and other information from the setup commands and determines how to shape the traffic. From that point, the PVC functions identically to an SVC.
LAN emulation client services are included in the Windows 2000 operating system. When Plug and Play detects an ATM adapter and installs the appropriate driver, the LANE client is also installed by default. This permits full LANE connectivity without the need for configuration, provided that:
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 Maximum Transmissible Unit (MTU), ELAN type, and LES — is obtained from the LECS. If a default ELAN is enabled in the LECS, no configuration is required.
For more information about configuring the LANE client, see Windows 2000 Server Help.
IP over ATM support is included with Windows 2000. In fact, in many ways the IP over ATM support provides more efficient network services than those provided through LANE. IP over ATM is faster than LANE for a variety of reasons, but the key difference between the two is that IP over ATM adds almost no additional header information to packets as they are handed down the protocol stack to the physical medium. The IP over ATM client, once it has established a connection, can generally transfer data without touching it. As a result, IP over ATM is a very small — and very fast — layer between the ATM protocol and the TCP/IP protocol.
IP over ATM exposes many features of ATM so that TCP/IP can make use of them directly. With this support, applications written to use TCP/IP, either through Windows Sockets or otherwise, can also make use of ATM. Applications written to use Generic QoS (GQoS) under Windows Sockets also benefit from this QoS being mapped to ATM-specific QoS parameters in IP over ATM.
In addition, the Windows 2000 ATMARP (IP over ATM) client supports multicast address resolution through MARS. This client contains an ATM ARP/MARS service that enables Windows to act as both an ATMARP server and a MARS with integrated multicast server (MCS). The MARS setup allows configuration of a ranges of addresses; the service acts as an MCS for all those addresses. For deployment and configuration information about IP over ATM, see Windows 2000 Server Help.
All of these enhancements are possible due to extensions to the operating system. The chief extension is a connection-oriented service added to NDIS version 5.0. NDIS 5.0 includes connection-oriented NDIS, or CoNDIS, a new NDIS API extension for the support of connection oriented media. These new APIs enable applications and protocols to create virtual circuits and specify Quality of Service for those virtual circuits. 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, as shown in Figure 14.17.
Figure 14.17 Supported CoNDIS Multicast Services
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 over 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.
Although NDIS 5.0 supports both connectionless and connection-oriented network adapter drivers, only the connection-oriented drivers are of use in an ATM network.
Connection-oriented miniport drivers are always deserialized; that is, they serialize the operation of their own miniport functions and queue all incoming packets internally rather than relying on NDIS to perform the same functions. This results in better full-duplex performance, provided that the driver's critical sections are kept small.
While NDIS library continues to support legacy NDIS 3.0 network adapter drivers, only NDIS 4.0 and 5.0 miniport drivers can take advantage of the enhanced functionality and performance characteristics of the current and future NDIS library support for network adapter drivers.
NDIS has several connection-oriented features; it also contains additional features of general utility to networks, such as binary compatibility, improved power management through Wake On LAN support (which enables a network adapter to power up a client from a low power state based on packet receipt), and checksum performance in hardware rather than in software. As a result, driver performance is improved over all network types.
Telephony Application Programming Interface, also known as Telephony API (TAPI), is responsible for connection setup and other operating system functions related to telephony. In Windows 2000, TAPI has been expanded to support telephony-like things over connection-oriented media such as ATM. While TAPI does not handle data directly, it can create a circuit and connect that circuit to another device.
By redirecting calls, TAPI provides more than just high bandwidth and good throughput. The TAPI component of CoNDIS maps (or proxies) the 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. For example, TAPI can redirect calls to a data handler such as the raw channel access filter, or DirectShow components. For another example of the ability of TAPI to act as a redirector, see "PPP over ATM and NDISWAN" later in this chapter.
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 a local loop, that last run of copper wire between the public telephone network and the home. In most areas, this local loop connects directly to an ATM core network run by a telephone company.
ATM over the xDSL service preserves the high-speed characteristics and QoS guarantees available in the core, without changing protocols. This creates the potential for an end-to-end ATM network to the residence or small office. This network model provides several advantages, including:
Adding the Point-to-Point Protocol (PPP) over this end-to-end architecture adds functionality and usefulness. PPP provides the following additional advantages:
These enhancements provide high bandwidth, even over a telephone line with an ATM adapter and this new level of integrated ATM support. In addition, with the adoption of PPP over ATM, little change is required at the ISP level, as telephone companies and ISPs both generally use PPP.
Finally, if each VC carrying a PPP session carries only one session, each destination has 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.
Windows 2000 supports PPP dial-up 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 operating systems, the NDISWAN component both supported operation of standard protocol stacks over WAN media and acted as the PPP engine. As explained earlier, in Windows 2000 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 dial-up networking to connect to a network, the dial-up networking module communicates with TAPI to make the phone call. When the request is made on an ATM device, TAPI does two things:
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 makes the call and then feeds the resulting connection to another process, in this case NDISWAN.
This connectability enables several new types of applications, such DVD quality streaming video, real-time process control, a common standard for both LAN and WAN, and integrated software that pulls together aspects of TV, telephony, and data streams. Many of these make use of the raw channel access filter and DirectShow technology, both described in the following section.
Microsoft developed DirectShow technology to better integrate multimedia services and to enable multimedia developers to more easily customize the operating 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. (The language used here is identical to that used to describe the Component Object Model [COM], a high-level specification for designing fully independent and object-oriented software.) TAPI connects different components, and DirectShow uses the same approach to enable filters and devices to connect to each other.
Figure 14.18 illustrates Windows COM-based DirectStreaming. A Windows 2000–based application can handle many categories of real-time inputs, as shown in Figure 14.18.
Figure 14.18 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. NDIS 5.0 can export ATM VCs as DirectShow pins.
The Windows 2000 support for raw channel access filtering comes through the CoNDIS 5.0 driver. The NDIS proxy sets up a call at the ATM layer, running from the proxy through the call manager to the client. Unlike many voice or video feeds, this connection is made using AAL5, rather than AAL1. The analog data transferred through the filter becomes digital data, which is packaged and handled identically to any other data over an AAL5 connection.
An example of using DirectShow and raw channel access support in Windows ATM services is a video streaming application that delivers up-to-date weather information over the telephone. Customers can simply dial a number and hear a recorded message.
The following steps outline this process:
Figure 14.19 shows an example of a weather report application using the DirectShow raw channel access filter. The path shows how the data is routed through the various protocols from telephony data to the application layer.
Figure 14.19 Weather Report Application Using DirectShow RCA Filter
Similarly, a user can make a telephone call that would be routed across a traditional LAN. This can enable such things as IP-based telephones. Again, TAPI handles the incoming call and uses NDIS 5.0 to connect it to a pin. DirectShow then reformats the data using a real-time protocol 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 ATM-based network integration blurs the boundaries between telephone and computer networks considerably.
