ATM

The Asynchronous Transfer Mode (ATM) protocol is one of the newest protocols available that is supported by Winsock 2 on Windows 98 and Windows 2000. ATM is usually used for high-speed networking on LANs and WANs and can be used for all types of communication, such as voice, video, and data requiring high-speed communication. In general, ATM provides guaranteed quality of service (QOS) using Virtual Connections (VCs) on a network. As you will see in a moment, Winsock is capable of using VCs on an ATM network through the ATM address family. An ATM network—as shown in Figure 6-2—typically comprises endpoints (or computers) that are interconnected by switches that bridge an ATM network together.

Figure 6-2. ATM network

There are a few things to be aware of when programming for the ATM protocol. First, ATM is a media type and not really a protocol per se. That is, ATM is similar to writing Ethernet frames directly on an Ethernet network. Like Ethernet, the ATM protocol doesn't provide flow control. It is a connection-oriented protocol that provides either message or stream modes. This also means that a sending application might overrun the local buffers if data cannot be sent quickly enough. Likewise, a receiving application must post receives frequently; otherwise, when the receiving buffers become full, any additional incoming data might be dropped. If your application requires flow control, one alternative is to use IP over ATM, which is simply the IP protocol running over an ATM network. As a result, the application follows the IP address family described above. Of course, ATM does offer some advantages over IP, such as a rooted multicast scheme (described in Chapter 12); however, the protocol that best suits you depends on your application's needs.

NOTE

---

Since ATM is new to Winsock 2, the information in this section was tested against ATM implementations on Windows 2000 Beta 3 only. Windows 98 (Service Pack 1) wasn't available for testing at the time of this writing, and it is possible that some of the information might not conform to the final implementation details of both Windows 2000 and Windows 98 (Service Pack 1).

Addressing

An ATM network has two network interfaces: the user network interface (UNI) and the network node interface (NNI). The UNI interface is the communication established between an endpoint and an ATM switch, while the NNI interface is the communication established between two switches. Each of these interfaces has a related communication protocol, described below.

• UNI signaling protocol Allows an endpoint to establish communication on an ATM network by sending setup and control information between an endpoint and an ATM switch. Note that this protocol is limited to transmissions between an endpoint and an ATM switch and isn't directly transmitted over an ATM network through switches.
• NNI signaling protocol Allows an ATM switch to communicate routing and control information between two switches.

For purposes of setting up an ATM connection through Winsock, we will only discuss certain information elements in the UNI signaling protocol. Winsock on Windows 2000 and Windows 98 (service pack 1) currently supports the UNI version 3.1 signaling protocol.

Winsock allows a client/server application to communicate over an ATM network by setting up a Service Access Point (SAP) to form connections using the ATM UNI signaling protocol. ATM is a connection-oriented protocol that requires endpoints to establish virtual connections across an ATM network for communication. An SAP simply allows Winsock applications to register and identify a socket interface for communication on an ATM network through a SOCKADDR_ATM address structure. Once an SAP is established, Winsock uses the SAP to establish a virtual connection between a Winsock client and server over ATM by making calls to the ATM network using the UNI signaling protocol. The SOCKADDR_ATM structure is defined as

 typedef struct sockaddr_atm { u_short satm_family; ATM_ADDRESS satm_number; ATM_BLLI satm_blli; ATM_BHLI satm_bhli; } sockaddr_atm, SOCKADDR_ATM, *PSOCKADDR_ATM, *LPSOCKADDR_ATM; 

The satm_family field should always be set to AF_ATM. The satm_number field represents an actual ATM address represented as an ATM_ADDRESS structure using one of two basic ATM addressing schemes: E.164 and Network Service Access Point (NSAP). NSAP addresses are also referred to as an NSAP-style ATM Endsystem Address (AESA). The ATM_ADDRESS structure is defined as

 typedef struct { DWORD AddressType; DWORD NumofDigits; UCHAR Addr[ATM_ADDR_SIZE]; } ATM_ADDRESS; 

The AddressType field defines the specified addressing scheme. This should be set to ATM_E164 for the E.164 addressing scheme and ATM_NSAP for the NSAP-style addressing scheme. Additionally, the AddressType field can be set to other values defined in Table 6-2 on the following when an application tries to bind a socket to an SAP, which we will discuss in more detail later in this chapter. The NumofDigits field should always be set to ATM_ADDR_SIZE. The Addr field represents an actual ATM 20-byte E.164 or NSAP address.

The satm_blli and satm_bhli fields of the SOCKADDR_ATM structure represent Broadband Lower Layer Information (BLLI) and Broadband Higher Layer Information (BHLI) in ATM UNI signaling, respectively. In general, these structures are used to identify the protocol stack that operates over an ATM connection. Several well-known combinations of BHLI and BLLI values are described in ATM Form/IETF documents. (A particular combination of values identifies a connection as being used by LAN Emulation over ATM, another combination identifies native IP over ATM, and so on.) Complete ranges of values for the fields in these structures are given in the ATM UNI 3.1 standards book. ATM Form/IETF documents can be found at http://www.ietf.org.

Table 6-2. ATM socket address types

ATM_ADDRESS AddressType	Setting Type of Address
ATM_E164	An E.164 address; applies when connecting to an SAP
ATM_NSAP	An NSAP-style ATM Endsystem Address (AESA); applies when connecting to an SAP
SAP_FIELD_ANY_AESA_SEL	An NSAP-style ATM Endsystem Address with the selector octet wildcarded; applies to binding a socket to an SAP
SAP_FIELD_ANY_AESA_REST	An NSAP-style ATM Endsystem Address with all the octets except for the selector octet wildcarded; applies to binding a socket to an SAP

The BHLI and BLLI data structures are defined as

 typedef struct { DWORD HighLayerInfoType; DWORD HighLayerInfoLength; UCHAR HighLayerInfo[8]; } ATM_BHLI; typedef struct { DWORD Layer2Protocol; DWORD Layer2UserSpecifiedProtocol; DWORD Layer3Protocol; DWORD Layer3UserSpecifiedProtocol; DWORD Layer3IPI; UCHAR SnapID[5]; } ATM_BLLI; 

Further details of the definition and use of these fields are beyond the scope of this book. An application that simply wants to form Winsock communication over an ATM network should set the following fields in the BHLI and BLLI structures to the SAP_FIELD_ABSENT value:

• ATM_BLLI—Layer2Protocol
• ATM_BLLI—Layer3Protocol
• ATM_BHLI—HighLayerInfoType

When these fields are set to this value, none of the other fields in both structures are used. The following pseudocode demonstrates how an application might use the SOCKADDR_ATM structure to set up an SAP for an NSAP address:

 SOCKADDR_ATM atm_addr; UCHAR MyAddress[ATM_ADDR_SIZE]; atm_addr.satm_family = AF_ATM; atm_addr.satm_number.AddressType = ATM_NSAP; atm_addr.satm_number.NumofDigits = ATM_ADDR_SIZE; atm_addr.satm_blli.Layer2Protocol = SAP_FIELD_ABSENT; atm_addr.satm_blli.Layer3Protocol = SAP_FIELD_ABSENT; atm_addr.satm_bhli.HighLayerInfoType = SAP_FIELD_ABSENT; memcpy(&atm_addr.satm_number.Addr, MyAddress, ATM_ADDR_SIZE); 

ATM addresses are normally represented as a hexadecimal ASCII string of 40 characters, which corresponds to the 20 bytes that make up either an NSAP-style or an E.164 address in an ATM_ADDRESS structure. For example, an ATM NSAP-style address might look like this:

 47000580FFE1000000F21A1D540000D10FED5800 

Converting this string to a 20-byte address can be a rather tedious task. However, Winsock provides a protocol-independent API function, WSAStringToAddress, which allows you to convert a 40-character ATM hexadecimal ASCII string to an ATM_ADDRESS structure. We describe this API function in more detail at the end of this chapter. Another way to convert a hexadecimal ASCII string to hexadecimal (binary) format is to use the function AtoH defined in Figure 6-3. This function isn't a part of Winsock. However, it is simple enough to develop, and you will see it in the samples in Chapter 7.

Figure 6-3. Conversion functions for ATM hexadecimal strings

 // // Function: AtoH // // Description: This function coverts the ATM // address specified in string (ASCII) format to // binary (hexadecimal) format // void AtoH(CHAR *szDest, CHAR *szSource, INT iCount) { while (iCount--) { *szDest++ = ( BtoH ( *szSource++ ) << 4 ) + BtoH ( *szSource++ ); } return; } // // Function: BtoH // // Description: This function returns the equivalent // binary value for an individual character specified // in ASCII format // UCHAR BtoH( CHAR ch ) { if ( ch >= '0' && ch <= '9' ) { return ( ch - '0' ); } if ( ch >= 'A' && ch <= 'F' ) { return ( ch - 'A' + 0xA ); } if (ch >= 'a' && ch <= 'f' ) { return ( ch - 'a' + 0xA ); } // // Illegal values in the address will not be // accepted // return -1; } 

Creating a Socket

In ATM, applications can create only connection-oriented sockets because ATM allows communication only over a VC. Therefore, data can be transmitted either as a stream of bytes or in a message-oriented fashion. To open a socket using the ATM protocol, call the socket function or the WSASocket function with the address family AF_ATM and the socket type SOCK_RAW, and set the protocol field to ATMPROTO_AAL5. For example:

 s = socket(AF_ATM, SOCK_RAW, ATMPROTO_AAL5); s = WSASocket(AF_ATM, SOCK_RAW, ATMPROTO_AAL5, NULL, 0, WSA_FLAG_OVERLAPPED); 

By default, opening a socket (as in the example) creates a stream-oriented ATM socket. Windows also features an ATM provider that can perform message-oriented data transfers. Using the message-oriented provider requires you to explicitly specify the native ATM protocol provider to the WSASocket function by using a WSAPROTOCOL_INFO structure, as described in Chapter 5. This is necessary because the three elements in the socket call and the WSASocket call (address family, socket type, and protocol) match every ATM provider available in Winsock. By default, Winsock returns the protocol entry that matches those three attributes and that is marked as default, which in this case is the stream-oriented provider. The following pseudocode demonstrates how to retrieve the ATM message-oriented provider and establish a socket:

 dwRet = WSAEnumProtocols(NULL, lpProtocolBuf, &dwBufLen); for (i = 0; i < dwRet; i++) { if ((lpProtocolBuf[i].iAddressFamily == AF_ATM) && (lpProtocolBuf[i].iSocketType == SOCK_RAW) && (lpProtocolBuf[i].iProtocol == ATMPROTO_AAL5) && (lpProtocolBuf[i].dwServiceFlags1 & XP1_MESSAGE_ORIENTED)) { s = WSASocket(FROM_PROTOCOL_INFO, FROM_PROTOCOL_INFO, FROM_PROTOCOL_INFO, lpProtocolBuf[i], 0, WSA_FLAG_OVERLAPPED); } } 

Binding a Socket to an SAP

ATM addresses are actually quite complicated because the 20 bytes they comprise contain many informational elements. Winsock application programmers need not worry about all the specific details of these elements with the exception of the last byte. The last byte in NSAP-style and E.164 addresses represents a selector value that uniquely allows your application to define and specify a particular SAP on an endpoint. As we described earlier, Winsock uses an SAP to form communication over an ATM network.

When Winsock applications want to communicate over ATM, a server application must register an SAP on an endpoint and wait for a client application to connect on the registered SAP. For a client application, this simply involves setting up a SOCKADDR_ATM structure with the ATM_E164 or ATM_NSAP address type and supplying the ATM address associated with the server's SAP. To create an SAP to listen for connections, your application must first create a socket for the AF_ATM address family. Once the socket is created, your application must define a SOCKADDR_ATM structure using the SAP_FIELD_ANY_AESA_SEL, SAP_FIELD_ANY_AESA_REST, ATM_E164, or ATM_NSAP address type as defined in Table 6-2 on 168. For an ATM socket, an SAP will be created once your application calls the Winsock bind API function (which we describe in Chapter 7), and these address types define how Winsock creates an SAP on your endpoint.

The address type SAP_FIELD_ANY_AESA_SEL tells Winsock to create an SAP that is capable of listening for any incoming ATM Winsock connection, which is known as wildcarding an ATM address and the selector. This means that only one socket can be bound to this endpoint listening for any connection—if another socket tries to bind with this address type, it will fail with Winsock error WSAEADDRINUSE. However, you can have another socket bound explicitly to your endpoint on a particular selector. The address type SAP_FIELD_ANY_AESA_REST can be used to create an SAP that is explicitly bound to a specified selector on an endpoint. This is known as wildcarding only the ATM address and not the selector. You can have only one socket at a time bound to a particular selector on an endpoint, or the bind call will fail with error WSAEADDRINUSE. When you use the SAP_FIELD_ANY_AESA_SEL type, you should specify an ATM address of all zeros in the ATM_ADDRESS structure. If you use SAP_FIELD_ANY_AESA_REST, you should specify all zeros for the first 19 bytes of the ATM address and the last byte should indicate what selector number you plan to use.

Sockets that are bound to explicit selectors (SAP_FIELD_ANY_AESA_REST) take higher precedence than those sockets that are bound to a wildcarded selector (SAP_FIELD_ANY_AESA_SEL). Those sockets that are bound to explicit selectors (SAP_FIELD_ANY_AESA_REST) or explicit interfaces (ATM_NSAP and ATM_E164) will get first choice at connections. (That is, if a connection comes in on the endpoint and the selector that a socket is explicitly listening on, that socket gets the connection.) Only when no explicitly bound socket is available will a wildcarded selector socket get the connection. Chapter 7 further demonstrates how to set up a socket that listens for connections on an SAP.

Finally, a utility named Atmadm.exe allows you to retrieve all ATM address and virtual connection information on an endpoint. This utility can be useful when you are developing an ATM application and need to know which interfaces are available on an endpoint. The command line options listed in the following table are available.

Parameter	Description
-c	List all connections (VC). Lists the remote address and the local interface.
-a	Lists all registered addresses (i.e., all local ATM interfaces and their addresses).
-s	Prints statistics (current number of calls, number of signaling and ILMI packets sent/received, etc.).

Name Resolution

Currently no name providers are available for ATM under Winsock. This unfortunately requires applications to specify the 20-byte address ATM to establish socket communication over an ATM network. Chapter 10 discusses the Windows 2000 domain name space that can be generically used to register ATM addresses with user-friendly service names.