Asynchronous Transfer Mode
Asynchronous Transfer Mode |
|
The protocol for classical IP over ATM (sometimes abbreviated as CLIP/ATM) is a well-established standard spelled out in RFC 1577 and subsequent documents. Windows 2000 provides a full implementation of this standard.
The IP over ATM approach provides several attractive advantages over ELAN solutions. The most obvious advantages are its ability to support QoS interfaces, its lower overhead (as it requires no MAC header), and its lack of a frame size limit. All of these features are discussed in the following sections.
IP over ATM is a group of components that do not 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 over ATM support, but not always. (For the purposes of this discussion, it is assumed the IP over ATM server services reside on a Windows 2000 server.)
The core components required for IP over ATM are roughly the same as those required for LANE, as both approaches require the mapping of a connectionless medium to a connection-oriented medium, and vice versa. In IP over ATM, these services are provided by an IP ATMARP server for each IP subnet. This server maintains a database of IP and ATM, and provides configuration and broadcast services, as described in the following section.
IP over 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 while simultaneously issuing native ATM commands to the ATM protocol layers underneath.
IP over ATM is often preferred to LANE because it is faster than LANE. One key reason for this performance advantage is that IP over ATM adds almost no additional header information to packets as they are handed down the stack. Once it has established a connection, the IP over ATM client can generally transfer data without modification.
As with LANE, IP over ATM is handled by two main components: the IP over ATM server and the IP over ATM client. The IP over ATM server is composed of an ATMARP server and Multicast Address Resolution Service (MARS). The ATMARP server provides services to map network layer IP unicast addresses to ATM addresses, while MARS provides similar services for broadcast and multicast addresses. Both services maintain IP address databases just as LANE services do.
The IP over ATM server can reside on more than one computer, but the ATMARP and MARS databases cannot be distributed. You can have one IP over ATM server handle ATMARP traffic, and one handle MARS. If, however, you divided the ATMARP Server between servers, it would effectively create two different IP networks. All IP over ATM clients in the same logical IP subnet (LIS) need to 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 includes fully integrated ATMARP and MARS servers. These services are described in more detail in the following sections.
The IP over ATM client and ATMARP server go through a process similar to the LANE client and the LECS when a 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 endstation to endstation. There is, however, a major difference in how the IP over ATM client discovers the ATMARP server.
Because the ATMARP server usually resides on a server rather than on an ATM switch, it is not possible to use ILMI or a well-known VC to discover its address. In fact, there is no default IP over ATM mechanism for server discovery. To start using IP over ATM, an administrator must find the ATM address of the appropriate ATMARP server and manually configure each IP over ATM client with this address. In a single ATM switch network, this is not much of a problem, but in larger networks it can become a demanding job. To ease configuration in smaller networks, Windows 2000 ATM ARP/MARS services and ATM ARP/MARS clients use a default address. For more information about deployment issues, see Windows 2000 Server Help.
After the ATMARP server has been discovered, the IP over ATM client can use this server to resolve IP to ATM address mappings and communicate with other computers. The ATMARP server supports only unicast traffic. To send packets to a broadcast address or multicast list, the IP over ATM client goes to the MARS.
Mimicking the role of the BUS in LAN emulation, 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. When 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 a list of all 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 a multicast server (MCS). The MCS registers interest in one or more multicast groups with the MARS. The MCS receives information describing the membership of that group, as well as updates when clients join or leave that group. When a client requests a group address resolution from the MARS, the 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 to all members of the group.
See Figures 14.12 and 14.13 for examples of the VCs that are created in each of these modes.
Figure 14.12 IP Multicast over ATM Connections Without MCS
Figure 14.13 IP Multicast over ATM Connections with MCS
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 virtual circuits required. The disadvantage of the second method, which uses the MCS, is that the MCS becomes both a central point of failure and a potential bottleneck because it distributes all multicast packets for all of the groups it serves.
IP over ATM faces the same problems, and relies on the same basic tools and fixes as LANE. In particular, it faces the issues of address resolution and broadcasting.
In normal ATM, SVC connections are established by sending a connection request containing the ATM address of the destination endpoint to the ATM switch. Before an IP endpoint can create an SVC in this manner, the endpoint must resolve the IP address of the destination to an ATM address.
Normally, when an Ethernet host needs to resolve an IP address to an Ethernet MAC address, it uses an ARP broadcast query frame. As explained earlier, hardware broadcasting is not done in ATM. The Address Resolution Protocol (ARP) of the ATMARP server resolve IP addresses to ATM addresses.
An ATM endpoint wishing to resolve an IP address sends an ATMARP request to the ATMARP server for their LIS. The ATMARP request contains the sender's ATM address and IP address and the requested IP address. If the ATMARP server knows the requested IP address, it sends back an ATMARP response containing the requested ATM address. If the requested IP address is not found, the ATMARP servers send back a negative ATMARP reply, unlike the procedure in an ELAN, which would send an unresolved address to the LANE BUS. This behavior allows an ARP requestor to distinguish between an unknown address and non-functioning ATMARP server.
The end result is a three-way mapping from the IP address to an ATM address to a VPI/VCI pair. The IP address and ATM address are required to create a VC. The IP address and VPI/VCI then are required to send the subsequent cells containing data across the VC.
An ATM endpoint creates SVCs to other ATM endpoints within its LIS. For an ATM endpoint to resolve an arbitrary IP address, it must be configured with the ATM address of the ATMARP server in its LIS.
Upon startup, an ATM endpoint establishes a VC with the ATMARP server using ATM signaling. As soon as the VC is opened with the server, the server sends the ATM endpoint an InATMARP request. When the ATM endpoint sends the response, the ATMARP server has the ATM and IP address of the new ATM endpoint. In this way, the ATMARP server builds its table of ATM to IP address mappings.
In Windows 2000, IP over ATM does not require the use of an Inverse ARP. Instead, the client goes directly to the server to register itself on the network. Since the process is automatic, no human intervention is required to initialize the client. Depending on whether the client address is mapped to a static address or a dynamic address, the procedure varies between the following two approaches.
The following example details each step in establishing an IP over ATM connection for a single IP over ATM client with a static IP address. First, the client initializes and gets an ATM address from the ATM switch. The client then connects to the ATM ARP/MARS server and joins the broadcast group. The client's IP to ATM address mapping is also added to the ATMARP server database. The client is now ready to contact other hosts and begin data transfer.
Establishing an IP over ATM connection for a single IP over ATM client using Dynamic Host Configuration Protocol (DHCP) is similar but not identical. First the client initializes and gets an ATM address from the ATM switch. Then the client connects to the ATM ARP/MARS server and joins the broadcast group. The client connects to the multicast server (MCS) and sends a DHCP request. The MCS broadcasts the DHCP request to all members of the broadcast group.
When the DHCP server receives the request, it sends a DHCP reply to the MCS. The MCS then broadcasts the reply to the broadcast group. The client receives the DHCP reply and then registers its IP and ATM addresses with the ATM ARP/MARS server. The client is now ready to contact other hosts and begin data transfer. For more information about DHCP, see "Dynamic Host Configuration Protocol" in the TCP/IP Core Networking Guide.
A LAN-based IP internetwork consists of a series of cabling plants separated by IP routers. The cabling plants connect the hosts of an IP network or subnet together and the routers connect the networks and subnets to each other. An IP host on a particular network can send IP packets directly to a host on the same network by addressing the packet to the media access control (MAC) address of the destination host. An IP host can send IP packets to hosts on other networks by addressing the packet to the router's MAC address. This paradigm can connect hundreds (or thousands) of hosts on the same network to hundreds (or thousands) more on other networks. While this configuration works well for connectionless, broadcast-based technologies such as Ethernet and Token Ring, it is important to exercise care when attempting to create the same situation with ATM. Figure 14.14 shows two LISs running on a single switch.
Figure 14.14 Two LISs Running on a Single Switch
Before a single IP packet can be sent, a connection must be created between the source and destination at the ATM layer. On an ATM network using SVC, the path must be negotiated between switches so that the sender has a valid VPI/VCI address to which to send the ATM cells. While possible, it is not very practical to have hundreds (or thousands) of ATM endpoints on the same IP network. A host such as a network server cannot have an arbitrarily large number of VCs to the other hosts in the network. More VCs mean more overhead and resources for the both the IP network's operating systems and its hardware (ATM adapters and switches). If connecting across an ATM service provider, more VCs also mean more cost.
The logical IP subnet (LIS) is a way of constraining the number of ATM endpoints in an IP network or subnet. The LIS is a group of IP hosts that share a common IP network number; these hosts communicate with each other directly using ATM virtual circuits. Different logical IP subnets can be created on the same ATM switch to create a virtual IP internetwork.
Note the example in the diagram above. When hosts in LIS 131.107.56.0/24 want to communicate among themselves, they establish a VC with each other (direct delivery). When hosts in LIS 131.107.56.0/24 want to communicate with hosts in LIS 131.107.68.0/24, they establish a VC with the router and send an IP packet to the router (indirect delivery). The router then establishes its own VC with the destination host and forwards the IP packet.
An IP router belongs to multiple LISs and is configured with multiple IP addresses and subnet masks. If the router has a single ATM interface (and therefore a single ATM address), it can either use the single ATM address (with the unique End System Identifier) or use multiple ATM addresses by varying the last byte in the 20-byte ATM address (the SEL field). It uses multiple addresses primarily in the case of a server failure, when a route is no longer functional, to give clients a secondary point of access.
For more information about creating a LIS, see "ATMARP Utility" later in this chapter.
The overall scheme of ATM protocols, hardware, and interconnections comes together in Figure 14.15. The hardware includes ATM clients, ATM switches, and the blades that function as edge devices between an ATM-aware device or application and another protocol or environment. The connections include SVCs and permanent virtual circuits (PVCs), all handled by the local switch shown at the center of the diagram.
In addition, Figure 14.15 shows LANE clients joining the local switch, as well as a client being redirected from Local Switch 2 by the LECS to the BUS and LES services on Local Switch 1. The bottom layer is the client section, showing all the ARP, ATM, and other clients of the local switch. (With the exception of a remote access client, which is shown dialing into the switch at the top of the diagram). The various forms of edge devices are shown in the central section, and remote connections are shown at the top.
Figure 14.15 Overview of ATM Architecture From Desktop to WAN
