Introduction
- Introduction
- Network systems
- Protocols—What are they?
- AppleTalk
- Why did we design it?
- Key goals of the AppleTalk architecture
- The AppleTalk network system
- AppleTalk connectivity
- Routers and AppleTalk internets
- Datagrams and network visibility
- Names, addresses, routes, and zones
- AppleTalk and reliable data exchange—transactions and streams
- AppleTalk end-user services
- AppleTalk printing services
- AppleShare and AppleTalk file service
- AppleTalk protocol architecture and the ISO-OSI reference model
- Figure I-9 AppleTalk protocols and the ISO-OSI reference model
- AppleTalk Phase 2
- Thoughts of the future
- About Inside AppleTalk
- Typographic and graphic conventions used in this book
- Where to go for more information
THIS BOOK PROVIDES the internal design details of the AppleTalk® network system. As such, it is intended for those who are not content merely with being users of the system but who would like to go behind the scenes. Inside AppleTalk is designed to meet the needs of those interested in understanding AppleTalk network technology. Distinguished among this group are developers wishing to connect devices to this network system or to write computer programs that use its services.
Readers are not required to have a detailed knowledge of network systems. Those generally familiar with the design of computing systems should be able to grasp the material presented here. ■
Network systems
The basic goal of computer network systems is to eliminate access barriers that result from the geographical and physical separation of various devices and the resources they embody. Network systems are the essential basis of distributed computing.
Computer network systems consist of computing components and connectivity components. Computing components include computing devices, such as personal computers, minicomputers, and mainframe computers, and special server devices, such as file servers and print servers. These devices are connected through a variety of cables, other data channels, and routing and gateway components, which collectively are the connectivity components of the system.
Protocols—What are they?
The effective operation of any distributed system, of human beings or of devices, is based on underlying rules that prescribe the nature and form of the permitted and accepted interactions. In the world of diplomacy, these rules are known as protocols.
Similarly, computer networks operate on the basis of carefully designed and scrupulously enforced rules of interaction—also called protocols—between the network system’s interconnected devices. Internal descriptions of such systems consist mainly of discussion and specification of the protocols, their objectives, and their interactions. This collective of information is known as the protocol architecture of the network system.
Inside AppleTalk defines and describes AppleTalk’s protocol architecture. To understand AppleTalk’s design fully, one must also examine its topological architecture, which is concerned with the manner in which the connectivity of the network system is implemented.
Not all aspects of AppleTalk protocols are covered in this book. Some issues, such as network management and gateway protocols, will be examined in companion volumes. Likewise, protocols for database access and for page description are discussed elsewhere.
AppleTalk
AppleTalk is a comprehensive network system designed and developed by Apple Computer, Inc. It consists of many different kinds of computer systems and servers and a variety of cabling and connectivity products.
This system was designed as an integral part of Apple Computer’s mission to provide greater power to the individual through computer technology. The ultimate objective was to go beyond personal computers to interpersonal computing. The cornerstone of this vision is the Macintosh® family of personal computers. These computers allow users to directly manipulate and use various capabilities and resources through an elegant, aesthetic, and empowering user interface. The AppleTalk network system was envisioned as a natural and seamless extension of the Macintosh beyond the confines of the user’s desk top, allowing the individual to gain access to remote resources and to interact with other users through personal computers.
Why did we design it?
When this design activity was initiated in late 1983, many barriers prevented the widespread adoption of network technology. No one doubted networking’s vast promise; yet its acceptance was proving slower than anticipated.
It was expensive (approximately $1000 for each computer) to connect a computer to network systems. This high cost, acceptable for minicomputers and mainframes, seemed prohibitive for the personal computer (itself priced around $1000). Furthermore, the services received by users who decided to pay the high initial price were limited.
More importantly, network systems were foreign appendages, conceived independently of computers and then only as an afterthought. Networks appeared to be celebrations of technology designed with more attention to such issues as data transmission speed than to user convenience. Users of network services had to learn the idiosyncrasies of each particular network. Access to resources through the network had to be obtained in a manner different from that used for local resources resident on the user’s computer. The network constituted a hindrance when it should have extended the user’s reach.
We could not use existing network protocol architectures to achieve our goal of seamlessly extending the user’s computing experience. We chose instead to develop our own architecture in which we would utilize standard technology where appropriate and innovate freely where necessary.
Key goals of the AppleTalk architecture
AppleTalk was developed to be a general-purpose network system that pays special attention to the needs of personal computers and their users. In designing AppleTalk’s protocol architecture, we had a number of key goals.
Versatility
The system should serve as the basis for a broad variety of applications, ranging from an external bus for attaching a few peripheral devices to a single Macintosh computer, to a network system connecting thousands of computer systems dispersed over a potentially wide area. Our objective of having a general-purpose design for AppleTalk made it imperative that we carefully construct the protocols with an eye to future, as-yet-undefined applications.
Computer networks are among the most promising technologies for bridging the operating system incompatibilities of the diverse types of computers in use today. The most valuable resource in these systems is the information generated by users. Network technology should allow users to exchange and share this information without concern for the special format and internal idiosyncrasies of dissimilar computer systems.
To achieve this goal, the network system must be designed from its inception to allow any type of computer to participate as an equal—and to the best of its ability.
“Plug-and-play” capability
The user should be able to plug a computing device into a network system and use it immediately without any of the complications of configuration. This “plug-and-play” capability, pioneered in AppleTalk, has now come to be a much-sought-after convenience of network systems. Several features of AppleTalk protocols make this possible (for example, the dynamic address-acquisition capability and the use of automatic name lookup to obtain access to network resources).
Peer-to-peer architecture
The network system’s architecture should avoid centralized control. Such control would not only increase the initial entry cost of the network system but also create a single point of failure. Furthermore, centralized control can adversely impact efficiency and in several ways reduce the user’s personal control over network resources.
AppleTalk protocols are peer-to-peer in structure, and the communicating entities operate as equals when interacting.
Simplicity
The protocols should be simple and easy to implement. Simplicity is essential if small, limited-memory and limited processing-power devices are to operate successfully on the network. Furthermore, simpler protocols can reduce network overhead and thus enhance performance and efficiency.
This simplicity of design and the resultant small size of network software also make it economically feasible to build network software into all computing devices, whether or not the user intends to connect the devices to a network.
Link independence
Each computing device should be able to use future technologies without the major costs of redesigning the protocol architecture and refitting ROMs and system software. Communications technology will continue to advance rapidly, offering new, as-yet-unforeseen interconnect hardware.
The protocol architecture had to be independent of the physical link. This decision has allowed us to include in the AppleTalk system a variety of physical-link options. We have introduced, for example, the use of Ethernet, token ring, and other physical-link technologies without any change to the architecture.
Seamless extension of the user’s computer
Although the protocol architecture has not been designed for a particular type of computer, special attention was paid to the integration of the network system with the user’s computer. In particular, the Desktop interface of the Macintosh was maintained across the network system. Making the network system transparent is central to a smooth extension of the user interface of the Macintosh, especially its direct manipulation capability.
Open architecture
The protocol architecture should be kept open so that any developer, Apple or third-party, can gain access to the services of any protocol in the architecture. But, more importantly, new protocols can be added to the architecture at any point.
Openness is essential if the architecture is to be extended or modified over its lifetime. Third-party developers can add protocols to build special services not contemplated by the designers of AppleTalk. For example, although AppleTalk has not included standards for electronic messaging/mail, various third-party vendors have been able to design and add such capability independently.
The AppleTalk network system
AppleTalk is a comprehensive network system that runs on a variety of data transmission media using various data-link methods. It facilitates communication between network devices, such as users’ computers, file servers, and printers, which may be a mixture of Apple and non-Apple products. Several elements make up an AppleTalk network system: AppleTalk software and AppleTalk hardware; the latter includes computing components and connectivity components.
The AppleTalk software implements the AppleTalk protocols in each device connected to the system.
The network devices and cabling methods comprise the physical or hardware components of an AppleTalk network system. The layout of a network is called its topology, that is, the arrangement of the devices and cables of the network system (see Figure I-1).
■ Figure I-1 Network topology
On a typical network, the majority of the devices, known as network nodes, will be users’ personal computers. Other network nodes could be operating, for example, as file or print servers or as routers and gateways.
AppleTalk connectivity
The first step in designing a protocol architecture is to build its connectivity infrastructure—the communication hardware and the associated protocols for controlling access to the hardware links.
AppleTalk’s design allows users to include a variety of data-link and cabling methods in a network system. In fact, an AppleTalk network can be set up using any of the widely available cabling and data-link technologies. Current widely used AppleTalk data-link and cabling methods include LocalTalk™ ; EtherTalk® , using standard Ethernet media; TokenTalk, using token ring; and LANSTAR AppleTalk, using Meridian LANSTAR media.
These different links can be interconnected in the AppleTalk system via routers to build very large local or geographically dispersed internets. The different links used in any particular portion of an AppleTalk internet can be chosen by the user according to the expected traffic, distance, and desired response characteristics in that portion of the internet.
Users can install low-cost, twisted-pair LocalTalk cabling when 230.4 Kbits/second bandwidth is sufficient. Higher-cost and higher-speed EtherTalk can be installed when full 10 Mbits/second performance is required and when the increased cost is acceptable. Likewise, wide-area links such as telephone lines can be used to extend the geographical reach of an AppleTalk network.
The cabling used in a particular portion of an AppleTalk network system can be viewed as a data highway shared by the connected network nodes. The associated data-link technology provides the protocols necessary to share that particular highway. This data-link technology consists of two principal portions: the media-specific or physical protocol and the data-link access protocol.
The physical protocol specifies physical aspects of the data link, such as how a data bit is encoded or modulated for transmission on the particular medium. For instance, on a fiber-optic link a bit is to be converted into a pulse of light of specified waveform, wavelength, and duration. In the case of electrical links, the impedance characteristics, signal strengths, and frequencies are specified by the physical protocol.
Data-link access protocols are concerned with the logistical aspects of sending the data packet through the physical medium over a potentially shared link. These protocols have several basic goals, such as addressing, error detection (in some cases, error recovery), and medium access control.
LocalTalk
The Apple LocalTalk product connects local work groups using inexpensive (typically under $100 per computer), easily configurable cabling to link workstations and other computing devices in an AppleTalk network system. LocalTalk is ideal for small, local work groups in which modest data transfer rates are acceptable. It provides a price-performance point unmatched by any other connectivity product in the industry.
Since the transmitter and receiver hardware for LocalTalk is built into every Macintosh and Apple IIGS® computer, LaserWriter® printer, and many peripheral devices, setting up the network is a simple process of connecting the devices with appropriate user-installable cabling and connectors. LocalTalk hardware is also available for Apple® IIe and MS-DOS computers, and for ImageWriter® II and ImageWriter LQ printers.
As shown in Figure I-2, LocalTalk is laid out in a bus topology, meaning that all devices are joined in a line with no circular connections. The physical characteristics of the LocalTalk twisted-pair cable allow it to reliably support a recommended maximum of 32 devices. A single LocalTalk network can span up to 300 meters.
The operation of a single LocalTalk network is managed by the LocalTalk Link Access Protocol (LLAP). LLAP was developed with the following goals:
- to build a low-cost, physical link
- to allow plug-and-play operation
LLAP is the data-link access protocol used to deliver data packets from any node of a LocalTalk network to any other node on that network. It makes a “best effort” to deliver the packet but does not guarantee its delivery. However, LLAP does ensure that if a packet is delivered it will be free of errors. The detailed specification of LLAP is provided in Chapter 1, Appendix A, and Appendix B.
LLAP includes a dynamic address-acquisition method that is crucial to the plug-and-play nature of the AppleTalk system.
The physical protocol governing the operation of LocalTalk is summarized in Appendix A. Several third-party vendors have implemented data links based on LLAP but have used different
■ Figure I-2 LocalTalk network
physical media. Notable among these are PhoneNET from Farallon Computing and the Du Pont Electronics Fiber Optic Communication Card for the Macintosh II. PhoneNET is an alternative implementation of LocalTalk functionality on standard, twisted-pair telephone cabling connected in a star topology with a central hub; the Electronics Fiber Optic Communication Card uses LLAP but with a different physical protocol from LocalTalk.
An AppleTalk data link other than LocalTalk is implemented using additional hardware, such as an interface card, and appropriate software. Two commonly used media are Ethernet and token ring. These alternative AppleTalk links do not use LLAP. Since their addressing schemes are different from those expected by the AppleTalk protocols, it is necessary to translate the AppleTalk node addresses into the addresses used by the particular link. This translation is carried out by using the AppleTalk Address Resolution Protocol (AARP) specified in Chapter 2.
EtherTalk
The Apple EtherTalk product provides high-speed connection of computing devices in the AppleTalk network system. It uses standard Ethernet technology including thick or thin coaxial and twisted-pair cabling with data transmission at 10 Mbits/second. This high-bandwidth medium is desirable for network segments that carry heavy traffic or require very agile response characteristics.
When used in an AppleTalk system, EtherTalk’s faster transmission speed results in better performance. Furthermore, EtherTalk can support as many concurrently active AppleTalk devices as can be connected to an Ethernet network.
EtherTalk relies on an extension of the Ethernet data-link protocol that uses AARP. This extended protocol, known as the EtherTalk Link Access Protocol (ELAP), is specified in Chapter 3.
TokenTalk
The Apple TokenTalk® product provides connection to industry-standard token ring networks. It uses token ring technology to provide access to token ring networks. TokenTalk is desirable for those environments already using token ring cabling for other purposes, such as access to mainframe computers.
Like EtherTalk, TokenTalk can support as many concurrently active AppleTalk devices as can be connected to the token ring network.
TokenTalk also uses AARP to extend the underlying data link. This extended data link protocol is known as the TokenTalk Link Access Protocol (TLAP), and is described in Chapter 3.
Routers and AppleTalk internets
Large and geographically dispersed AppleTalk network systems can be built using the data-link products available for AppleTalk to interconnect the various networks through routers. The resulting system is called an AppleTalk internet, as shown in Figure I-3.
■ Figure I-3 AppleTalk internet
An AppleTalk router is a computer that is connected to each of the AppleTalk networks it interconnects. Routers operate as store-and-forward devices. Each network of the internet is assigned a unique range of numbers known as its network numbers, and every AppleTalk data packet traveling across an internet includes a network number in the range of the destination network. By consulting this number, routers are able to forward the packet from router to router until it arrives at its destination network. There the appropriate data link delivers the packet to the destination node.
Routers forward data packets by consulting tables of routing information. The initial acquisition of a routing table and its continuous maintenance are carried out by routers using the Routing Table Maintenance Protocol (RTMP) specified in Chapter 5.
Datagrams and network visibility
AppleTalk extends the node-to-node packet delivery service of the various individual links and the routers to a process-to-process, best-effort delivery. Thus, the various processes operating in the nodes of an internet can exchange data packets. The basis of this service is the Datagram Delivery Protocol (DDP) specified in Chapter 4. DDP provides the processes with addressable entities known as sockets. Processes can attach themselves to one or more sockets within their respective nodes and then exchange packets with each other through these sockets. The data packets exchanged through this DDP service are known as datagrams. Datagram delivery is the key service of the AppleTalk architecture upon which other value-added services are built.
Once a process has attached itself to a socket, it is then accessible from any point in the AppleTalk network system. It is said to be a network-visible entity (NVE).
Names, addresses, routes, and zones
The identification of available network entities is fundamental to the construction of network services and distributed computing applications. Three basic concepts are germane to this discussion—names, addresses, and routes. An entity’s name can be seen as an attribute that is a location-independent, usually unique identifier of a network entity, much like names in the everyday world. An entity’s address provides information related to its location, while a route is an actual path that data will have to traverse to reach the entity.
Users are comfortable with the use of names, but they prefer that addressing and routing be attended to automatically by the network system. Thus AppleTalk provides a service to let any network-visible entity give itself one or more names. Then the user of the network can discover the existence of that entity through a standard AppleTalk mechanism. The actual conversion of the name into an address is automatically done by the appropriate software in the user’s computer, without the user’s intervention. Access to the entity is provided by the software by using this address and the routing capabilities of DDP and RTMP built into all nodes. The named-entity discovery and address conversion is provided by the Name Binding Protocol (NBP) discussed in Chapter 7.
Very large internets could present the user with long, clumsy lists of network-visible entities. To help organize these long lists, AppleTalk internets can be subdivided into AppleTalk zones. Name searching can then be done within one or more user-specified zones. This added organizational convenience is enabled by the Zone Information Protocol (ZIP) discussed in Chapter 8. The zone structure and the name-lookup process require the close interaction of end nodes and routers. This interaction is governed by NBP and ZIP.
Many network systems provide a naming service through the use of centralized repositories known as name servers. Every named entity must register its name and address with the name server. The server then helps other network nodes to discover and address the named entities of the system. An important consideration in the design of AppleTalk was that it not require dedicated name servers. Requiring such servers would dramatically increase the entry cost and installation complexity of the network system. For small network systems, name servers may not add much value. NBP neither precludes the use of name servers nor provides the services needed for their management.
AppleTalk and reliable data exchange—transactions and streams
DDP provides a best-effort packet-delivery service. Datagrams still could be lost or damaged in transit through the internet. To ensure reliable, end-to-end delivery of these packets, AppleTalk includes a variety of protocols, each with different capabilities.
The AppleTalk Transaction Protocol (ATP) provides a reliable packet exchange in the form of request-response pairs (see Chapter 9). Packet exchange transactions of this nature are central to the interaction of a user with a server such as a file server. The AppleTalk Session Protocol (ASP) extends the ATP service by allowing two processes to exchange a sequence of transactions reliably (see Chapter 11).
The AppleTalk Data Stream Protocol (ADSP) allows two processes to open a virtual data “pipe” between their sockets. Either process can write data bytes into the pipe and read data bytes from it (see Chapter 12). Data bytes written into an ADSP pipe are delivered reliably at the other end in the exact same order.
Those readers familiar with network systems have come to expect the key reliable data-transfer service of a network system to be a connection-oriented data stream or virtual circuit. AppleTalk’s heavy use of transaction protocols in lieu of stream protocols might surprise them.
stream services are implemented on packet networks at the cost of considerable protocol overhead. However, stream protocols are a natural extension of physical connections used in most data communication applications. These virtual circuit services emulate familiar capabilities and are readily accessible to and used by programmers. These users often employ such streams, however, to implement a client-server interaction, which is of a request-response transaction nature. The programmer has to add overhead to undo the stream service, in effect, and to convert it back to a transaction service. With ATP/ASP, AppleTalk avoids the double overhead of first extracting stream service from a packet-oriented system and then converting it back to a transaction service.
Stream services of ADSP are included in the architecture for two reasons: first, as a convenience to programmers familiar with such services in other network systems; second, to provide the natural data transport service for implementing capabilities such as terminal emulation and file transfer. ADSP will also prove useful for gateways that provide end-to-end connection services between AppleTalk nodes and nodes on other network systems.
AppleTalk end-user services
AppleTalk was designed to be a foundation for interpersonal computing. Two fundamental end-user services developed for this purpose are shared printing and shared filing. The key AppleTalk printing products are the ImageWriter and LaserWriter families of printers. Further printing convenience is provided by the PrintMonitor and AppleShare® print server spooling capabilities. File sharing services are implemented as a seamless extension of the Macintosh Desktop in AppleShare, which provides AppleTalk file service.
AppleShare is designed to be a sharing platform for a variety of user computers, including the Macintosh, MS-DOS, and Apple II families. In particular, it serves as the basis for Apple’s popular classroom network system used by students from kindergarten through the university.
Publication of the protocols on which these products are based has allowed third parties to add other printing and file serving devices that are compatible with Apple’s products. This compatibility ensures a uniform user experience across a range of products with different price, performance, and capability characteristics. For instance, AppleTalk users can write documents on their Macintosh computers and use an Apple LaserWriter to print them during the development process. After the document has been fully developed, the user can print it on higher-resolution typeset equipment in exactly the same manner as on the LaserWriter.
Likewise, Macintosh users can gain access to files stored on any VAX™-resident, AppleShare-compatible file server such as AlisaShare or PacerShare in exactly the same way as files stored on an AppleShare file server (or, in fact, on the user’s local disks).
AppleTalk printing services
Printing on an AppleTalk network is possible with several different hardware and software configurations. AppleTalk networks support both direct printing and printing with a spooler.
Direct printing
Direct printing occurs when a workstation sends a print job directly to a printer connected to the network system, as shown in Figure I-4.
When a user issues a command to print a document, the application begins a series of AppleTalk calls attempting to establish a connection to the printer. The calls first initiate NBP’s name-lookup process to find the currently selected printer and its AppleTalk address. Then the Printer Access Protocol (PAP) is used to open a connection with the printer.
Once the connection is established, the workstation and the printer interact over the PAP connection. PAP uses lower-level protocols, such as ATP and DDP, to provide a data-stream service for sending the print data to the printer. For a detailed specification of PAP, see Chapter 10.
Printing services on AppleTalk can also be implemented through ADSP.
■ Figure I-4 Direct printing
Printing with a print spooler
A print spooler is a hardware or software application that interacts with a printer to print documents. When a computer sends a file to be printed, the print spooler intercepts the file and handles all printer interaction, freeing the computer for other tasks. Two types of spooler implementations are used with AppleTalk: a background spooler and a spooler/server.
A background spooler is a software application that operates in the user’s computer as a background process and spools print jobs to the user’s local disk. An example of an application that allows background printing is the PrintMonitor application included with the Macintosh MultiFinder™.
A spooler/server is an application that runs on a computer set up to be a print spooler and connected to the AppleTalk network system (see Figure I-5). A spooler/server works by setting itself up as a surrogate printer; that is, when the computer tries to print, it sees the spooler/server as a printer and, in fact, cannot distinguish it from a printer. When the user prints, the user’s computer produces the print data and sends it to the spooler/server. Since the spooler/server stores the print data in its hard disk, it is able to quickly accept this information from the user’s computer, which is freed for other use. The spooler/server then takes charge of the more time-consuming task of getting the data processed by the printer.
■ Figure I-5 Printing with a spooler/server
LaserWriter and other printers accept only one job, or connection, at a time. Spooler/servers can accept several connections at a time, thereby minimizing the contention problems that occur when several workstations try to print simultaneously. AppleShare includes a spooler/server for printing on any Apple-supplied AppleTalk printers and on compatible third-party printers.
AppleTalk print spooling is more fully discussed in Chapter 14.
AppleShare and AppleTalk file service
Within an AppleTalk network system, the AppleShare file server provides a location where a user on the network can store and gain access to common files without disrupting other users’ activities.
Using AppleShare File Server software, a Macintosh computer with one or more hard disk drives can become a dedicated file server on the network. Each hard disk attached to the AppleShare file server is called a volume.
To be able to use an AppleShare file server, a user is registered on the server, given a password, and placed into one or more user groups, as appropriate. Gaining access to the file server involves a login process in which the server asks for the user’s identification, consisting of a user name and a password. Once the server has examined its registered user database and validated the user, the selected server volumes’ icons, much like a hard disk icon, appear on the user’s Macintosh Desktop.
The login process assures confidentiality; users must be registered and must enter a password before being able to gain access to protected portions of server volumes. Unregistered users can log in as guests; that is, they can obtain access to information that is unprotected.
Within a server volume, files are stored in folders. Folders on a Macintosh are analogous to directories on an MS-DOS or UNIX® computer; both folders and directories are named entities that hold files or other folders/directories. Opening and saving files and creating folders are done the same way on a file server volume as on a local disk.
Each AppleShare folder has an owner, who determines which users may have access to the folder and in what fashion. Access privileges control access to information on the file server; a folder can be kept private, shared by a group of users, or shared by all network users. The user information placed in the server’s user database allows the server to determine a user’s access privileges when he or she tries to gain access to the contents of a folder.
The access privileges for a folder or volume let the owner, the group, or guests see folders, see files, and make changes inside the folder. Users can select folders and view their access privileges for those folders. In addition, a folder’s owner can examine and change the access privilege information, which includes the owner’s name, the folder’s associated group, the owner’s privileges, the group’s privileges, and a guest’s privileges (see Figure I-6). The owner can transfer the folder’s ownership to another user.
■ Figure I-6 Access privileges
Access to an AppleShare file server is not limited to Macintosh computers. The LocalTalk PC Card allows MS-DOS-compatible personal computers to be connected to a LocalTalk network. Using this card with the AppleShare PC software, MS-DOS personal computer users can print to LaserWriter, ImageWriter II, and ImageWriter LQ printers from within an application. AppleShare PC software also allows these users to work with an AppleShare file server by means of a menu-based user interface. Additionally, AppleShare PC supports various third-party Ethernet and token ring cards, allowing MS-DOS machines to connect to EtherTalk and TokenTalk networks.
Likewise, Apple IIGS and Apple IIe computers can gain access to the printing and filing services of an AppleTalk system. LocalTalk hardware is built into the Apple IIGS, while the Apple IIe requires the use of a plug-in LocalTalk board. In fact, Apple IIe and Apple IIGS computers can operate and even start up in a diskless fashion from an AppleShare server.
The dialog between a user’s computer and an AppleShare file server is conducted using the AppleTalk Filing Protocol (AFP). AFP was central to the global vision that the AppleShare product serve as the basis for cross-system information sharing between dissimilar computers. For this reason, AFP calls were specifically designed to have enough semantic and syntactic content to allow complete servicing of each of the computer families. Most importantly, these calls provide sophisticated services for managing a shared Desktop view of the file server’s volumes. Changes made by the user of one Macintosh computer will automatically be reflected on the Desktop view of any other Macintosh computer viewing the same folder or volume.
The AFP file server environment encourages the development of applications that can themselves be shared as well as those that allow the sharing of data. To use applications within the server’s shared storage environment, special considerations are necessary for file management, particularly when the applications allow multi-user and multilaunch capabilities. Multi-user applications let two or more users make changes to the same file concurrently. Multilaunch applications let two or more users simultaneously open and work with one copy of an application. AFP includes calls that allow applications to control the concurrent file access required by such applications. The complete specification of AFP is provided in Chapter 13.
Why did Apple decide to design a new filing protocol? Why did we not use an existing, de facto or industry-standard protocol? The design of AFP was started at Apple in 1984. Two other file service protocols were then in various stages of completion, PC-net’s SMB and Sun Microsystem’s NFS.
SMB and NFS were each designed to serve a particular computer family. Specifically, MS-DOS was the target system for SMB and UNIX for NFS. SMB was later extended to accommodate some versions of the UNIX file system. NFS is currently being extended for use by MS-DOS computers. On the other hand, AFP was visualized from the very beginning to service equally a variety of computers.
Neither SMB nor NFS is capable of handling several significant aspects of the Macintosh hierarchical file system (HFS), such as much longer file and folder names, dual fork files, and the Desktop database. Use of SMB or NFS would not have allowed us to provide a seamless extension of the Macintosh Desktop to the file server.
AppleTalk protocol architecture and the ISO-OSI reference model
The various AppleTalk protocols draw upon the services of some other protocol(s) and deliver an enhanced service either to some other protocol or to an application. In Figure 1-7, the protocols are shown in a layered configuration, with a protocol in a higher-level layer drawing on the services of one or more protocols in lower-level layers. Layered models for network protocols are inspired by their prior use in describing various concepts (in particular, operating systems) of stand-alone computers. Today, most carefully designed network systems rely on a layered protocol architecture.
The schema shown in Figure 1-7 permits an easier understanding of the complexities of the overall system. It provides a framework for examining the interaction of the different components and for isolating functionality to certain portions of the system. This structure allows a divide-and-conquer approach to designing and building the protocol architecture.
Beyond these general observations, an examination of various network systems reveals a common pattern to the progression of services provided by the layers of these protocol architectures. This progression typically proceeds from the physical management of data communication hardware to the data-link access services discussed earlier. Beyond the data link, network-wide addressing and routing capabilities are added. Reliability of data transfer is usually the next value-added service, involving retransmission disciplines and connection/session management services.
Above the connectivity services, network systems are now beginning to address presentation issues such as data representation incompatibilities. Finally, the protocols for providing various user and application-level services such as filing and electronic messaging are added.
Figure I-7 AppleTalk protocol architecture
graph TD
AFP["AppleTalk Filing Protocol (AFP)"]
PS["PostScript"]
ASP["AppleTalk Session Protocol (ASP)"]
PAP["Printer Access Protocol (PAP)"]
ADSP["AppleTalk Data Stream Protocol (ADSP)"]
ZIP["Zone Information Protocol (ZIP)"]
RTMP["Routing Table Maintenance Protocol (RTMP)"]
AEP["AppleTalk Echo Protocol (AEP)"]
ATP["AppleTalk Transaction Protocol (ATP)"]
NBP["Name Binding Protocol (NBP)"]
DDP["Datagram Delivery Protocol (DDP)"]
TLAP["TokenTalk Link Access Protocol (TLAP)"]
ELAP["EtherTalk Link Access Protocol (ELAP)"]
LLAP["LocalTalk Link Access Protocol (LLAP)"]
TR_HW["Token ring hardware"]
ETH_HW["Ethernet hardware"]
LT_HW["LocalTalk hardware"]
AFP --- ASP
PS --- PAP
ASP --- ATP
PAP --- ATP
PAP --- NBP
ADSP --- DDP
RTMP --- DDP
ZIP --- ATP
ZIP --- DDP
AEP --- DDP
ATP --- DDP
NBP --- DDP
DDP --- TLAP
DDP --- ELAP
DDP --- LLAP
TLAP --- TR_HW
ELAP --- ETH_HW
LLAP --- LT_HW
In the 1970s, the International Standards Organization (ISO) developed and published a standard framework known as the Open Systems Interconnection (OSI) reference model (the ISO-OSI reference model). This model defines in explicit terms the concepts of a protocol and a service interface. It defines a protocol architectural framework consisting of seven layers: physical, data link, network, transport, session, presentation, and application. The goal of the model was to establish a standard framework and the associated terminology for describing, studying, and comparing the protocols of network architectures. Although the ISO-OSI reference model did not define any standard protocols, it was to serve as the framework in which future activity on protocol standardization would proceed.
Protocol entities populate the layers of the ISO-OSI reference model. A protocol entity located in layer n of the model draws upon the services provided by layer n-1, and in turn provides layer n services to protocol entities located in layer n+1. A protocol entity gains access to the services of another protocol entity, located in the adjacent lower layer, through a service interface (see Figure 1-8). Protocol entities located in the same layer of the model communicate with each other through a protocol.
The AppleTalk protocols can now be placed in the framework of this model, as shown in Figure 1-9. The reader is cautioned not to read from this figure a protocol compatibility of AppleTalk with the OSI protocols currently in various stages of definition, approval, and deployment. This figure merely establishes that the architectural structure fits into the standard framework of the ISO-OSI model.
■ Figure 1-8 Interfaces and protocols
Figure I-9 AppleTalk protocols and the ISO-OSI reference model
flowchart TD
subgraph L7 [7. Application]
end
subgraph L6 [6. Presentation]
AFP[AppleTalk Filing Protocol AFP]
PS[PostScript]
end
subgraph L5 [5. Session]
ADSP[AppleTalk Data Stream Protocol ADSP]
ZIP[Zone Information Protocol ZIP]
ASP[AppleTalk Session Protocol ASP]
PAP[Printer Access Protocol PAP]
end
subgraph L4 [4. Transport]
RTMP[Routing Table Maintenance Protocol RTMP]
AEP[AppleTalk Echo Protocol AEP]
ATP[AppleTalk Transaction Protocol ATP]
NBP[Name Binding Protocol NBP]
end
subgraph L3 [3. Network]
DDP[Datagram Delivery Protocol DDP]
end
subgraph L2 [2. Data link]
TLAP[TokenTalk Link Access Protocol TLAP]
ELAP[EtherTalk Link Access Protocol ELAP]
LLAP[LocalTalk Link Access Protocol LLAP]
end
subgraph L1 [1. Physical]
TRH[Token ring hardware]
EH[Ethernet hardware]
LTH[LocalTalk hardware]
end
AFP --- ADSP
AFP --- ASP
PS --- PAP
ADSP --- DDP
ZIP --- ATP
ZIP --- DDP
ASP --- ATP
PAP --- ATP
PAP --- NBP
RTMP --- DDP
AEP --- DDP
ATP --- DDP
NBP --- DDP
DDP --- TLAP
DDP --- ELAP
DDP --- LLAP
TLAP --- TRH
ELAP --- EH
LLAP --- LTH
| OSI Layer | AppleTalk Protocols |
|---|---|
| 7. Application | (No specific protocols listed) |
| 6. Presentation | AppleTalk Filing Protocol (AFP), PostScript |
| 5. Session | AppleTalk Data Stream Protocol (ADSP), Zone Information Protocol (ZIP), AppleTalk Session Protocol (ASP), Printer Access Protocol (PAP) |
| 4. Transport | Routing Table Maintenance Protocol (RTMP), AppleTalk Echo Protocol (AEP), AppleTalk Transaction Protocol (ATP), Name Binding Protocol (NBP) |
| 3. Network | Datagram Delivery Protocol (DDP) |
| 2. Data link | TokenTalk Link Access Protocol (TLAP), EtherTalk Link Access Protocol (ELAP), LocalTalk Link Access Protocol (LLAP) |
| 1. Physical | Token ring hardware, Ethernet hardware, LocalTalk hardware |
AppleTalk Phase 2
AppleTalk Phase 2, introduced in June 1989, provides compatible extensions to the AppleTalk network system that enable it to function better in large network environments. Such environments often include thousands of concurrently active devices and multiple concurrent network protocols and data links. AppleTalk Phase 2 removed the restriction of a maximum of 254 concurrently active AppleTalk devices on one network. In addition, AppleTalk Phase 2 was designed to minimize the interference of AppleTalk protocols with other non-AppleTalk devices in the same environment.
Changes introduced with Phase 2 do not affect non-routing LocalTalk devices. In addition, none of the higher-level protocols have changed. These include ADSP, ASP, PAP, and AFP. Only one small enhancement (the TRel timer in exactly-once transactions can be set by the requestor) was added to ATP. Most of the changes are to ELAP, DDP, RTMP, NBP, and ZIP. These changes need only be implemented in routers and in EtherTalk devices (TokenTalk was introduced as a part of AppleTalk Phase 2).
The single most important protocol change in AppleTalk Phase 2 is that a single AppleTalk network can now be assigned more than one network number. The size of the range of network numbers assigned to a network determines the maximum number of concurrently active AppleTalk devices that can be supported on that network (253 devices per network number). LocalTalk networks are assigned only a single network number, as they need support no more than 254 devices.
A key component of AppleTalk Phase 2 is the AppleTalk Internet Router product. In addition to serving as the first router to implement the Phase 2 protocols, the AppleTalk Internet Router allows up to eight AppleTalk networks (of any data-link type) to be interconnected. The router software runs on a Macintosh and thus provides the familiar Macintosh user interface for router setup and for monitoring of the internet. The router supports LocalTalk, EtherTalk, and TokenTalk and can be extended to support other data links as they are added to the AppleTalk network system.
Thoughts of the future
The initial installation of AppleTalk was spurred on by a trio of products—the Macintosh computer, the LaserWriter printer, and LocalTalk connectivity. AppleTalk played a significant role in the ensuing desktop publishing revolution. In the first place, it provided shared access to an outstanding, but relatively expensive, printing device. The ability to share the printer significantly reduced the per-user cost of the LaserWriter printer to an acceptable price-performance point. Users were able to exploit this technology while focusing primarily on the outstanding quality of the printed page.
A variety of other network services helped broaden the appeal of AppleTalk. Today the AppleTalk network system is used by an installed base of more than 1 million computers and servers in network configurations that range in size from a minimum of two devices to large internets with thousands of devices. A variety of personal computer systems (including Macintosh, Apple II, MS-DOS, and UNIX computers and larger central computers such as VAXs), are connected to AppleTalk systems. A full range of servers and services is available from Apple and other vendors.
All network systems keep growing and changing over their lifetimes. AppleTalk is no exception. In the future, AppleTalk is expected to grow in both scope (size) and reach (variety).
Scope
Large organizations and their subsidiaries are making increasing use of networking technology, thus creating the need for very large network systems. These systems will connect hundreds of thousands of computers of all sizes and types. As organizations span the globe, their networks will be required to extend over wide geographical areas.
Large networks will require more sophisticated routing and management capabilities. Special issues related to slow or intermittently available links will require resolution. Naming and authentication services will become important issues for organizations wishing to provide a more uniform control of these aspects.
Reach
The growing use of network systems has made users aware of the cumbersome integration of networks into their computers. This difficulty is exacerbated by the variety of network technologies and protocol families in use today.
A response to this growing qualitative complexity has been a drive to establish international protocol standards. Notable among these movements are the efforts of various national and international organizations under the auspices of ISO to define and ratify a single family of standard protocols.
This standardization activity will help as these protocols find wider acceptance. However, it appears that the network systems of tomorrow will continue to use a variety of protocol families. This increasingly complex network system, if not properly designed, could be extremely difficult to use. An important goal for AppleTalk is to extend the user’s reach into this polyglot environment with an immediacy of service and elegance of interface modeled on today’s AppleShare. This will require the use of a variety of new products, such as gateways and entirely new technologies still being developed.
Gateways are software and/or hardware devices that are interposed between two dissimilar network systems. The gateway serves a role akin to that of a simultaneous interpreter between people speaking different languages. This analogy might explain why gateways have long been considered an important networking technology. However, the use of gateways has so far been relatively limited. The complexity of full, seven-layer gateways between dissimilar protocol families has, in general, rendered them impossible to design and build.
Specialized gateways have been quite effective. For instance, gateways between different electronic mail systems are now finding increased use. The development of a variety of application-level gateway services will extend the reach of AppleTalk into non-AppleTalk systems and will bring important resources and services to the desk tops of AppleTalk users.
Companion volumes to Inside AppleTalk will be published to provide the specifications of these extensions and modifications.
About Inside AppleTalk
Inside AppleTalk is divided into five parts. The book is further divided into fourteen chapters (an in-depth, chapter-specific, table of contents begins each chapter within the five parts) and four appendixes. A glossary of terms and an index complete Inside AppleTalk.
Part I covers the physical and data-link alternatives that can be used in an AppleTalk network system. This part includes a summary of the LocalTalk Link Access Protocol (LLAP); procedural details for this protocol can be found in Appendix B. In addition, Part 1 includes a detailed description of the AppleTalk Address Resolution Protocol (AARP) and discussions of how AARP is used by the EtherTalk Link Access Protocol (ELAP) and the TokenTalk Link Access Protocol (TLAP).
Part II describes the AppleTalk protocols that facilitate end-to-end transmission of data across the network, specifying in detail the Datagram Delivery Protocol (DDP), the Routing Table Maintenance Protocol (RTMP), and the AppleTalk Echo Protocol (AEP).
Part III covers the AppleTalk protocols that handle naming, providing detailed descriptions of the Name Binding Protocol (NBP) and the Zone Information Protocol (ZIP).
Part IV describes the AppleTalk protocols that guarantee reliable data delivery over the network and includes detailed information about the AppleTalk Transaction Protocol (ATP), the Printer Access Protocol (PAP), the AppleTalk Session Protocol (ASP), and the AppleTalk Data Stream Protocol (ADSP).
Part V describes the protocols that provide end-user services and includes a complete description of the AppleTalk Filing Protocol (AFP). In addition, Part 5 discusses the specification for print spooling in an AppleTalk network.
The appendixes provide electrical specifications, LLAP procedural details, and a summary of the AppleTalk protocol parameters.
Typographic and graphic conventions used in this book
Throughout this book, all numerical quantities are given as decimal numbers, except where otherwise noted. A dollar sign preceding a number (for example, $3E) indicates hexadecimal (base 16) notation. Bit sequences and binary numbers are written as strings of 1s and 0s beginning with a 0.
Words and phrases in boldface are described in the Glossary.
In figures depicting packet formats, the following graphical conventions are followed:
- Each simple rectangle represents 1 byte (8 bits). Vertical tick marks or solid lines delineate each bit. The rightmost bit is the least-significant bit and is numbered bit 0. The leftmost bit is the most-significant bit and is numbered bit 7.
- Each rectangle with one or more pairs of horizontal tick marks represents 2 or more bytes. Within the multibyte field, the bottom-right bit is the least-significant bit and is numbered bit 0. The top-left bit is the most-significant bit.
- A pair of vertical ellipses represents a field of variable length.
- In most cases, the figure will show the format of the protocol being described and will omit the formats of the other encapsulating protocols.
Where to go for more information
Readers wishing more detail about networking concepts mentioned in this chapter are encouraged to consult the following references.
AppleTalk
- General (available from Addison-Wesley Publishing Company, Inc.):
- AppleTalk Network System Overview
- Inside Macintosh, Vol. II, Chap. 10
- Inside Macintosh, Vol. V, Chap. 30
- AppleTalk system (available from Apple Programmer’s and Developer’s Association [APDA]):
- AppleShare Programmer’s Guide for the Apple IIGS
- AppleTalk for VMS Documentation Suite:
- AppleTalk for VMS Architecture and Implementation
- AppleTalk for VMS Bridge Control Program Guide
- AppleTalk for VMS Installation and Operation Guide
- AppleTalk for VMS Protocol Support Library Reference Manual
- Asynchronous LaserWriter Driver Developer’s Guide
- Macintosh AppleTalk Connections Programmer’s Guide
- LocalTalk PC Card and Driver Preliminary Notes
- Software Applications in a Shared Environment
General networking
- Tanenbaum, Andrew S. Computer Networks. Englewood Cliffs, NJ: Prentice-Hall, Inc., 1981.
Data links
-
Inside AppleTalk does not specifically address Ethernet or token ring cabling and protocols. For more information on these physical and data-link protocols, refer to:
-
The Ethernet, A Local Area Network: Data Link Layer and Physical Layer Specifications, Version 2.0, November 1982 [specification document jointly published by Digital Equipment Corporation, Intel Corporation, and Xerox Corporation].
-
802.2 Logical Link Control. IEEE, Inc., October 1985.
-
802.3 Carrier Sense Multiple Access with Collision Detection. IEEE, Inc. May 1986.
-
802.5 Token Ring Access Method. IEEE, Inc. 1985.
Connection-oriented protocols
-
For TCP/IP, please consult: Cerf, V. G. and Kahn R. E. “A Protocol for Packet Network Interconnection.” IEEE Trans. Commun. COM-22:637–648 (May 1974).
-
The Xerox Network Systems (XNS) internet protocols are specified in: Internet Transport Protocols. Xerox Systems Integration Standard X.S.I.S. 028112, December 1981.
-
The X.25 access standard is specified in the following publication of the CCITT: Data Communication Networks Interfaces: Recommendations X.20–X.32, Red Book, Volume VIII-Fascicle VIII.3. Geneva: International Telecommunications Union-CCITT, 1985.
PostScript
PostScript® is the document representation/page description protocol used for communication with LaserWriter printers. The widely used standard was first made available as a product in the AppleTalk system, in Apple’s LaserWriter printers. For a detailed discussion of PostScript, refer to:
- Adobe Systems Incorporated. PostScript Language Reference Manual. Reading, Mass.: Addison-Wesley Publishing Company, Inc., 1985.
ISO-OSI reference model
- Zimmermann, H. “OSI Reference Model—The ISO Model of Architecture for Open Systems Interconnection.” IEEE Trans. Commun. COM-28:425–432 (April 1980).
Database access
- CI/1 Connectivity Language: Language Description, Network Innovations, August 1988.