AppleTalk and AppleTalk over IP

AppleTalk and AppleTalk over IP
When Apple introduced the Macintosh in 1984, the Mac included networking software. This networking software used a protocol known as AppleTalk and a cabling system known as LocalTalk. It is a very simple and elegant protocol in that the computer takes care of most of the configuration. You simply plug it in and it works. Because of its simplicity and popularity with Mac users, and because the Mac users wanted a faster version, Apple developed Apple- Talk version 2 with support for Ethernet (EtherTalk). Figure 2.20 illustrates the interrelationships between these components of AppleTalk, as well as others we’ll discuss. Table 2.5 descibes the protocols shown in Figure 2.20.

FIGURE 2 . 2 0 The AppleTalk protocol model

TABLE 2 . 5 AppleTalk Protocols Defined

Protocol	Description
Datagram Delivery Protocol (DDP)	Delivers data in discrete packets. DDP is unreliable, not acknowledging data delivery or guaranteeing the order of its delivery.
Routing Table Maintenance Protocol (RTMP)	Establishes and maintains routing tables through the exchange of  routing information between routers.
AppleTalk Echo Protocol (AEP)	Provides a way to test for responsiveness and round-trip transmission times. Similar to using ICMP for Pinging remote devices.
AppleTalk Transaction Protocol (ATP)	Provides reliable data transmission, similar to the way in which TCP does so for TCP/IP.
Name Binding Protocol (NBP)	Translates an AppleTalk device name into an AppleTalk network  address.
AppleTalk Data Stream Protocol (ADSP)	Establishes an end-to-end full-duplex session to exchange data between two network applications in which both endpoints have equal control over the communication.
Zone Information Protocol (ZIP)	Maintains AppleTalk internetwork-wide mappings of zone names to network number ranges on routers. While ZIP is primarily implemented by routers, end devices implement a portion of ZIP, allowing them to obtain zone information from a router. A zone is similar, in purpose, to a VLAN in layer 2 switching, unifying nodes by departmental membership or other logical affiliations regardless of their physical LAN segment connectivity.
AppleTalk Session Protocol (ASP)	Establishes reliable sessions that provide for non-duplicate transmissions between an ASP workstation process and an ASP server process. Unlike those formed in ADSP, ASP sessions are asymmetrical in that an ASP server never initiates communication but only responds to communication initiated by the ASP workstation.
Printer Access Protocol	Handles connection setup, maintenance, and termination of reliable transmission of messages to printers.
AppleTalk Filing Protocol (AFP)	Provides the interface between an application and a file server. Allows an application on an AppleTalk workstation to access and manipulate files on an AFP file server, such as an AppleShare server or a Microsoft Windows server running AFP, in the form of Services for Macintosh.

      Apple’s Mac OS X and OS X Panther (versions 10.3.x) can communicate with any server running the AFP service, whether over TCP/IP, which is preferred by Apple, or over the legacy Apple- Talk protocol. On Macintosh servers, the AFP service is implemented as AppleShare. You can use IP to connect to Macintosh file services running on Mac OS X Server, AppleShare IP, and Windows 2000 and later servers. AppleShare IP has been an add-on service available since the Mac OS 8 days, necessary for IP connectivity with AFP resources before this functionality became available natively in Mac OS X. Of course, Mac OS X still is capable of communicating with AFP servers over AppleTalk instead of IP, supporting legacy access to older AppleShare servers and Windows NT servers that only provide Mac file services over AppleTalk. However, Apple recommends migrating to TCP/IP as the transport method between clients and AFP servers.

Note:

One note about Mac OS X and AppleTalk: While Mac OS X clients can still use
AppleTalk to communicate with older AppleShare servers, Mac OS X servers
do not support client communication to their Apple File Services (the server’s
instance of AFP) via AppleTalk. While the Mac OS X server advertises its services
over AppleTalk for older clients to be able to show the server in their
Chooser, connection to the server must be via TCP/IP.

Note:

In addition to using AppleTalk for service browsing, you can use Mac OS X
Server’s Server Admin utility to enable Apple File Service browsing via Network
Service Locator (NSL) and Rendezvous. Rendezvous is an IP-based open
service discovery protocol, allowing devices to be added to and removed from
networks without configuration. Rendezvous is mentioned in Chapter 3’s Zero-
Conf discussion. 

Services for Macintosh
Although the Windows 2000 file system is fairly different from the Macintosh file system, files on a Windows 2000 Server machine are accessible by both Windows 2000 clients and Macintosh
clients. Services for Macintosh works in the background on a Windows 2000 Server machine to make this multiclient support possible by establishing an AFP-compatible server service. Files can be made to appear as they usually do for both Macintosh and Microsoft clients. A Microsoft client sees files represented as a directory tree, while a Macintosh client sees files represented as a Macintosh folder. In this environment, files may be stored in shared folders or Macintosh volumes. Macintosh volumes that are shared to the network are seen only by Macintosh clients, not by the Windows 2000 clients. Conversely, in order for a Macintosh
client to gain access to a Microsoft shared folder, the administrator must designate the folder as a Macintosh-accessible volume. 

      For folders that are both a Microsoft shared folder and a Macintosh-accessible volume, both Microsoft clients and Macintosh clients have access to the resource. However, while Microsoft clients see folders and files as they are stored on the server’s hard disk beneath the root of the share, Macintosh clients see the volume as containing Macintosh files and folders.
     The following sections cover AppleTalk’s methods of addressing and naming as well as its ability to be routed over internetworks.

Addressing
Each station on an AppleTalk network uses an address that is 24 bits long. Sixteen of those bits are given to the network, and each network can support 254 nodes. Each network segment can
be given either a single 16-bit network number or a range of 16-bit network numbers. If a network is assigned a range of numbers, that network is considered an Extended AppleTalk network because it can support more than 254 nodes. The node address is automatically assigned by the computer itself.
      In addition to network numbers, AppleTalk networks use areas called zones. Zones allow an administrator to divide a network into logical areas for easier administration and to make it easier

for a user to find resources.

Note:

Although you can have multiple zones on an AppleTalk network, an AppleTalk node can belong to only one zone.

Routing
AppleTalk wasn’t originally designed to be routed over a WAN, but with the release of AppleTalk version 2, Apple included routing functionality with the introduction of the Routing Table Maintenance Protocol (RTMP). RTMP is a distance vector routing protocol, like RIP, for both IP and IPX.

Interoperability
The only computer that comes with AppleTalk installed by default is the Macintosh. Most Windows operating systems are able to use the AppleTalk protocol but require that additional software
be installed. By using AppleTalk over IP, it is possible to tunnel AppleTalk conversations over the very Internet itself. Two AppleTalk speakers can package their AppleTalk packets in
such a way that they are transmissible through IP intermediate systems, being stripped back down to the original AppleTalk packet by the receiving AppleTalk-speaking device.

Naming
AppleTalk uses the Name Binding Protocol (NBP) to associate the name of the computer with its network address. It is broadcast based. Every station broadcasts its name when it comes up on a network. The AppleTalk router on a network will cache these names and respond when a node requests a name resolution; the local router will answer with information it has obtained from this NBP cache.

Note:

If an AppleTalk network doesn’t have a router, each node will perform both its normal NBP requests and any NBP responses to broadcasted requests for its own AppleTalk address.