The call manager, or signaling module, is what enables one ATM station to establish a virtual circuit—complete with QoS guarantees—with another ATM station, all prior to the packets actually being transmitted. The call manager resides on each switch, so that each switch can respond to VC and QoS requests, which is what gives ATM its ability to guarantee bandwidth allocation.
It is the call manager that essentially says, "Establish a virtual circuit to this ATM address, and to this service access point application, with this QoS guarantee." Once the virtual circuit has been established, the signaling module is out of the picture, and the application or driver can simply tell the hardware interface to send a certain packet on a specified VC number. The hardware interface, the NIC, and the switches all know the significance of that VC number, as well as its QoS and its mapping from input port to output port.
Protocols that now run on Windows NT or Windows 95, such as TCP/IP, IPX, and NetBEUI, are unable to create virtual circuits and would require significant rewriting to understand VC technology. This is why Microsoft is working on incorporating the Call Manager into the operating system, something that will greatly simplify development for ATM card vendors. Rather than having to develop, purchase, or license a custom call manager, something which is difficult to author, they will be able to provide a simple miniport that will plug into the call manager supplied in the Windows 95 or Windows NT operating system.
As noted above, Microsoft plans to use the UNI 3.1 call manager. But to create a more open system, the NDIS 4.1 interface will provide the capability to have multiple call managers. This means a vendor can create a pluggable custom call manager to support a switch that uses a proprietary signaling protocol other than UNI 3.1.