ATM and QOS

As we mentioned earlier, QOS is natively available on ATM networks. Both Windows 2000 and Windows 98 (with Service Pack 1) support native ATM programming from Winsock, as you learned in Chapter 6. QOS is natively available on an ATM network, which means that the network, application, and policy components that are necessary for QOS over IP are not required over ATM. This includes the Admission Control Service and the RSVP protocol. Instead, the ATM switch performs bandwidth allocations and prevents over-allocation of bandwidth.

In addition to the differences we've already mentioned, the Winsock API functions behave a bit differently with ATM QOS than they do with QOS over IP. The first major difference is that the QOS bandwidth request is handled as part of the connection request. This differs from QOS over IP in that the RSVP session is established separately from the connection. Also, if the bandwidth request is rejected under ATM, the connection will fail.

This leads to our next point: both of the native ATM providers are connection-oriented. As a result, you don't have the problem of setting QOS levels for a connectionless socket and then having to specify the endpoint for communication. The next major difference is that only one side sets the QOS parameters for a connection. That is, if the client wants to set QOS on a connection, both the sending and receiving FLOWSPEC structures are set within the QOS structure passed to WSAConnect. These values will then be applied to the connection, in contrast to QOS over IP, in which the sender requests certain QOS levels and the receiver then makes the actual reservation. Additionally, the listening socket might have QOS set using WSAIoctl and SIO_SET_QOS. These values will be applied to any incoming connections. This also means that QOS must be set during connection setup. You cannot set QOS on an already established connection.

This leads us to our last point: once QOS is set for a connection, you cannot renegotiate QOS by calling WSAIoctl and SIO_SET_QOS. When QOS is set on a connection, it remains until the connection is closed.

Keep in mind that RSVP is not present and no signaling occurs. This means that none of the status flags in Table 12-6 are ever generated. QOS is set when establishing the connection, and no further notifications or events occur until the connection is closed.