Vous êtes sur la page 1sur 20



1. Introduction

2. Design

3. Addressing

4. AppleTalk Network Components

5. AppleTalk protocol and OSI Model

6. Physical Implementation

7. Advantage


AppleTalk, a protocol suite developed by Apple Computer in the early 1980s, was
developed in conjunction with the Macintosh computer. AppleTalk's purpose was to
allow multiple users to share resources, such as files and printers. The devices that supply
these resources are called servers, while the devices that make use of these resources
(such as a user's Macintosh computer) are referred to as clients. Hence, AppleTalk is one
of the early implementations of a distributed client/server networking system.

AppleTalk is a network with a bus topology that uses a trunk cable between connection
modules. Interfacing with the network is handled by the Serial Communications Control
chip found in every Mac. Any device (computer, peripheral, etc.) attaches to a connection
box via a short cable (called a drop cable), as shown in figure 1. This type of network is
known as a multidrop line or a multipoint link. AppleTalk is capable of supporting up to
32 nodes (devices) per network and can transmit data at a rate of 230,400 bits per second.
Nodes can be separated by a maximum cable length of 1000 feet.

Fig. 1 The Physical Connection


AppleTalk was designed with a transparent network interface—that is, the interaction
between client computers and network servers requires little interaction from the user. In
addition, the actual operations of the AppleTalk protocols are invisible to end users, who
see only the result of these operations. Two versions of AppleTalk exist: AppleTalk
Phase 1 and AppleTalk Phase 2.

AppleTalk Phase 1, which is the first AppleTalk specification, was developed in the early
1980s strictly for use in local workgroups. Phase 1 therefore has two key limitations: Its
network segments can contain no more than 135 hosts and 135 servers, and it can support
only nonextended networks.

AppleTalk Phase 2, which is the second enhanced AppleTalk implementation, was

designed for use in larger internetworks. Phase 2 addresses the key limitations of
AppleTalk Phase 1 and features a number of improvements over Phase 1. In particular,
Phase 2 allows any combination of 253 hosts or servers on a single AppleTalk network
segment and supports both nonextended and extended networks.


An AppleTalk address was a 4-byte quantity. This consisted of a two-byte network

number, a one-byte node number, and a one-byte socket number. Of these, only the
network number required any configuration, being obtained from a router. Each node
dynamically chose its own node number, according to a protocol which handled
contention between different nodes accidentally choosing the same number. For socket
numbers, a few well-known numbers were reserved for special purposes specific to the
AppleTalk protocol itself. Apart from these, all application-level protocols were expected
to use dynamically-assigned socket numbers at both the client and server end.

Because of this dynamism, users could not be expected to access services by specifying
their address. Instead, all services had names which, being chosen by humans, could be
expected to be meaningful to users, and also could be sufficiently long enough to
minimize the chance of conflicts.

Note that, because a name translated to an address, which included a socket number as
well as a node number, a name in AppleTalk mapped directly to a service being provided
by a machine, which was entirely separate from the name of the machine itself. Thus,
services could be moved to a different machine and, so long as they kept the same service
name, there was no need for users to do anything different to continue accessing the
service. And the same machine could host any number of instances of services of the
same type, without any network connection conflicts.

Contrast this with records in the DNS, where a name translates only to a machine
address, not including the port number that might be providing a service. Thus, if people
are accustomed to using a particular machine name to access a particular service, their
access will break when the service is moved to a different machine. This can be mitigated
somewhat by insistence on using CNAME records indicating service rather than actual
machine names to refer to the service, but there is no way of guaranteeing that users will
follow such a convention. (Some newer protocols, such as Kerberos and Active Directory
use DNS SRV records to identify services by name, which is much closer to the
AppleTalk model.)

AppleTalk Network Components

AppleTalk networks are arranged hierarchically. Four basic components form the basis of
an AppleTalk network: sockets, nodes, networks, and zones. Fig.1 illustrates the
hierarchical organization of these components in an AppleTalk internetwork. Each of
these concepts is summarized in the sections that follow.

Fig.1 The AppleTalk Internet work consists of a Hierarchy of Components


An AppleTalk socket is a unique, addressable location in an AppleTalk node. It is the

logical point at which upper-layer AppleTalk software processes and the network layer
Datagram Delivery Protocol (DDP) interact. These upper-layer processes are known as
socket clients. Socket clients own one or more sockets, which they use to send and
receive datagram. Sockets can be assigned statically or dynamically. Statically assigned
sockets are reserved for use by certain protocols or other processes. Dynamically
assigned sockets are assigned by DDP to socket clients upon request. An AppleTalk node
can contain up to 254 different socket numbers.

Fig. 2 Socket Clients Use Sockets to Send and Receive Datagram


An AppleTalk node is a device that is connected to an AppleTalk network. This device

might be a Macintosh computer, a printer, an IBM PC, a router, or some other similar
device. Within each AppleTalk node exist numerous software processes called sockets.
Each node in an AppleTalk network belongs to a single network and a specific zone.


An AppleTalk network consists of a single logical cable and multiple

attached nodes. The logical cable is comprised of either a single physical
cable or multiple physical cables interconnected by using bridges or routers.
AppleTalk networks can be nonextended or extended. Each is discussed
briefly in the following sections.

Nonextended Networks

A nonextended AppleTalk network is a physical network segment that is assigned only a

single network number, which can range between 1 and 1024. Network 100 and network

562, for example, are both valid network numbers in a nonextended network. Each node
number in a nonextended network must be unique, and a single nonextended network
segment cannot have more than one AppleTalk Zone configured on it. (A zone is a
logical group of nodes or networks.) AppleTalk Phase 1 supports only nonextended
networks, but as a rule, nonextended network configurations are no longer used in new
networks because they have been superseded by extended networks. Fig. 3.1 illustrates a
nonextended AppleTalk network.

Fig.3.1 A Nonextended Networks is assigned only one network number

Extended Networks

An extended AppleTalk network is a physical network segment that can be assigned

multiple network numbers. This configuration is known as a cable range. AppleTalk
cable ranges can indicate a single network number or multiple consecutive network
The cable ranges network 3-3 (unary) and network 3-6, for example, are both valid in
an extended network. Just as in other protocol suites, such as TCP/IP and IPX, each
combination of network number and node number in an extended network must be
unique, and its address must be unique for identification purposes. Extended networks
can have multiple AppleTalk zones configured on a single network segment, and nodes
on extended networks can belong to any single zone associated with the extended
network. As a rule, extended network configurations have replaced nonextended network

Fig.3.2 An Extended Network can be assigned multiple network


An AppleTalk zone is a logical group of nodes or networks that is defined when the
network administrator configures the network. The nodes or networks need not be
physically contiguous to belong to the same AppleTalk zone.

Fig. 4 Nodes or Networks in the Same Zone need not be physically Contiguous

AppleTalk Protocols and the OSI Model:

Fig. 5 AppleTalk Protocols and the OSI Model


AppleTalk Address Resolution Protocol

AARP resolves AppleTalk addresses to physical layer, usually MAC, addresses. It is

functionally equivalent to ARP.

AARP is a fairly simple system. When powered on, an AppleTalk machine broadcasts an
AARP probe packet asking for a network address, intending to hear back from controllers
such as routers. If no address is provided, one is picked at random from the "base
subnet", 0. It then broadcasts another packet saying "I am selecting this address", and
then waits to see if anyone else on the network complains. If another machine has that
address, it will pick another address, and keep trying until it finds a free one. On a
network with many machines it may take several tries before a free address is found, so
for performance purposes the successful address is "written down" in NVRAM and used
as the default address in the future. This means that in most real-world setups where
machines are added a few at a time, only one or two tries are needed before the address
effectively become constant.

AppleTalk Data System Protocol

This was a comparatively late addition to the AppleTalk protocol suite, done when it
became clear that a TCP-style reliable connection-oriented transport was needed.
Significant differences from TCP were:

• a connection attempt could be rejected

• There were no "half-open" connections; once one end initiated a tear-down of the
connection, the whole connection would be closed (i.e., ADSP is full-duplex, not
dual simplex).

Apple Filing Protocol

The Apple Filing Protocol (AFP), formerly AppleTalk Filing Protocol, is the protocol for
communicating with AppleShare file servers. Built on top of AppleTalk Session Protocol,
it provides services for authenticating users (extensible to different authentication
methods including two-way random-number exchange) and for performing operations
specific to the Macintosh HFS files system. AFP is still in use in Mac OS X, even though
most other AppleTalk protocols have been deprecated.

AppleTalk Session Protocol

ASP was an intermediate protocol, built on top of ATP, which in turn was the foundation
of AFP. It provided basic services for requesting responses to arbitrary commands and
performing out-of-band status queries. It also allowed the server to send asynchronous
attention messages to the client.

AppleTalk Transaction Protocol

ATP was the original reliable transport-level protocol for AppleTalk, built on top of
DDP. At the time it was being developed, a full, reliable connection-oriented protocol
like TCP was considered to be too expensive to implement for most of the intended uses
of AppleTalk. Thus, ATP was a simple request/response exchange, with no need to set up
or tear down connections.

An ATP request packet could be answered by up to eight response packets. The requestor
then sent an acknowledgement packet containing a bit mask indicating which of the
response packets it received, so the responder could retransmit the remainder.

ATP could operate in either "at-least-once" mode or "exactly-once" mode. Exactly-once

mode was essential for operations which were not idempotent; in this mode, the
responder kept a copy of the response buffers in memory until successful receipt of a
release packet from the requestor or until a timeout elapsed. This way, it could respond to
duplicate requests with the same transaction ID by resending the same response data,
without performing the actual operation again.

Datagram Delivery Protocol

DDP was the lowest-level data-link-independent transport protocol. It provided a

datagram service with no guarantees of delivery. All application-level protocols,
including the infrastructure protocols NBP, RTMP and ZIP, were built on top of DDP.

Name Binding Protocol

NBP was a dynamic, distributed system for managing AppleTalk names. When a service
started up on a machine, it registered a name for itself on that machine, as chosen by a
human administrator. At this point, NBP provided a system for checking that no other
machine had already registered the same name. Then later, when a client wanted to
access that service, it used NBP to query machines to find that service. NBP provided
browse ability ("what are the names of all the services available?") as well as the ability
to find a service with a particular name.

As would be expected from Apple, names were truly human readable, containing spaces,
upper and lower case letters, and including support for searching.

The Name Binding Protocol (NBP) is a transport layer protocol in the AppleTalk
protocol suite that maps the addresses used at lower layers to AppleTalk names. Socket
clients within AppleTalk nodes are known as Network-Visible Entities (NVEs). An NVE
is a network-addressable resource, such as a print service, that is accessible over the
internet work. NVEs are referred to by character strings known as entity names. NVEs
also have a zone and various attributes, known as entity types, associated with them.

Two key reasons exist for using entity names rather than addresses at the upper layers.
First, network addresses are assigned to nodes dynamically and, therefore, change
regularly. Entity names provide a consistent way for users to refer to network resources
and services, such as a file server. Second, using names instead of addresses to refer to
resources and services preserves the transparency of lower-layer operations to end users.

Fig. 6 An RTMP Routing Table Contains Information about Each
Destination Network Known to the Router

Printer Access Protocol

PAP was the standard way of communicating with Postscript printers. It was built on top
of ATP. When a PAP connection was opened, each end sent the other an ATP request
which basically meant "send me more data". The client's response to the server was to
send a block of PostScript code, while the server could respond with any diagnostic
messages that might be generated as a result, after which another "send-more-data"
request was sent. This use of ATP provided automatic flow control; each end could only
send data to the other end if there was an outstanding ATP request to respond to.

PAP also provided for out-of-band status queries, handled by separate ATP transactions.
Even while it was busy servicing a print job from one client, a PAP server could continue
to respond to status requests from any number of other clients. This allowed other
Macintoshes on the LAN that were waiting to print to display status messages indicating
that the printer was busy, and what the job was that it was busy with.

Routing Table Maintenance Protocol

RTMP was the protocol by which routers kept each other informed about the topology of
the network. This was the only part of AppleTalk that required periodic unsolicited
broadcasts: every 10 seconds, each router had to send out a list of all the network
numbers it knew about and how far away it thought they were.

Zone Information Protocol

ZIP was the protocol by which AppleTalk network numbers were associated with zone
names. A zone was a subdivision of the network that made sense to humans (for example,
"Accounting Department"); but while a network number had to be assigned to a
topologically-contiguous section of the network, a zone could include several different
discontinuous portions of the network.

The Physical Layer has the responsibility of bit encoding/decoding, synchronization,

signal transmission/ reception and carrier sensing. As mentioned previously, the Serial
Communications Control chip in the Mac takes care of the AppleTalk port, which
happens to be the printer port on current Macs. As long as connection modules conform
to the signal descriptions of the Physical Layer, any transmission medium can be used for
the actual network.

The AppleTalk Link Access Protocol (ALAP) must be common to all systems on the
network bus and handles the node-to-node delivery of data between devices connected to
a single AppleTalk network. ALAP determines when the bus is free, encapsulates the
data in frames, sends its data, and recognizes when data should be received. ALAP is also
responsible for assigning node numbers to each station on a network. The ALAP software
assigns a random node number when the Mac is booted and keeps that number as long as

it does not conflict with a previously assigned node number (if it does conflict, ALAP
tries again).

The Link Access Protocol uses a method called CSMA/CA or carrier-sense multiple
accesses with collision avoidance, for access control. Carrier sense means that a sending
node first listens to the network to hear if any other node is using the bus and defers to
the ongoing transmission. Collision avoidance means that the protocol attempts to
minimize collisions between transmitted data packets. In AppleTalk CSMA/CA, all
transmitters wait until the bus is idle for a minimum time plus a random amount of added
time before transmitting (or retransmitting after a collision).

While the ALAP protocol provides delivery of data over a single AppleTalk network, the
Datagram Delivery Protocol (DDP) extends this mechanism to include a group of
interconnected AppleTalk networks, known as an internet. An internet can be formed, for
example, by using a bridge between two, or more, AppleTalk networks.

AppleTalk's address header (a part of each data packet) is used for identification of a
process on the network and consists of a socket number, node number, and network
number. A socket is a communication endpoint within a node on the network. Sockets
belong to processes or functions that are implemented within software in the node. One
Mac may have several AppleTalk connections open at one time, so the node number is
not enough to identify a network address. In addition, node numbers are unique only
within a single physical network, so DDP requires that each network be assigned a
network number. The Datagram Delivery Protocol takes care of assigning socket
numbers, as well as node numbers and network numbers, to provide a unique
identification for every process occurring on the AppleTalk network.

As we move on to the Transport Layer, several protocols exist to add different types of
functionality to the underlying services. The Routing Table Maintenance Protocol
(RTMP) allows bridges and internet routers to dynamically discover routes to the
different AppleTalk networks in an internet. The routing tables pair network numbers
with the local node number of the bridge through which the shortest path to that net

The AppleTalk Transaction Protocol, or ATP, is part of the Transport Layer and is
responsible for controlling the transactions (flow of data) between requestor and
responder sockets. This transaction-oriented protocol can be contrasted to other types of
transport layers which support a two-way link between clients that can act as though they
had an error-free hardwired link between them.

The basic function of the Name Binding Protocol (NBP) is the translation of a character
string name into the internet address of the corresponding client. A key feature of the
network is that most objects are accessible by name rather than by address (better for the
user). NBP also introduces the concept of a zone, which is an arbitrary subset of networks
in an internet where each network is in one and only one zone. The concept of zones is
provided to assist the establishment of departmental or other user-understandable
grouping of the entities of the internet. AppleTalk names consist of three fields: the
object name (e.g., Dave), the type name (e.g., printer), and the zone name (e.g., Bldg. 1).

The Echo Protocol (EP) is a simple protocol that allows any node to send data to any
other node on an AppleTalk internet and receive an echoed copy of that data in return.
The Echo Protocol is mainly meant for network maintenance functions.

The specifications for the AppleTalk Data Stream Protocol (ADSP) have not yet been
published (Inside AppleTalk, current version dated July 14, 1986). ADSP is designed to
provide byte-stream data transmission in a full duplex mode between any two sockets on
an AppleTalk internet. The Zone Information Protocol (ZIP) is used to maintain an
internet-wide mapping of networks to zone names. Most of ZIP’s services are transparent
to the normal (non-bridge) node; the majority of ZIP is implemented in the bridges of an
internet. ZIP is used by the Name Binding Protocol to determine which networks belong
to a given zone.

In the Session Layer, the AppleTalk Session Protocol (ASP) is a general protocol
designed to interact with ATP to provide for establishing, maintaining and closing
sessions. Central to ASP is the concept of a session; two network entities, one in a
workstations and the other in a server, can set up an ASP session between themselves
(identified by a unique session’s identifier). ASP is an asymmetric protocol in that the

workstation initiates the session connection and issues sequences of commands, to which
the server responds; the server may not send commands to the workstation.

The specifications for the AppleTalk Filing Protocol (AFP) have not been generally
publicized. However, AFP has been finalized with the introduction of the AppleShare file
server software from Apple, which uses AFP. AFP is a presentation layer protocol
designed to control access to remote file systems.

The Zone Information Protocol (ZIP) is a session layer protocol in the AppleTalk
protocol suite that maintains network number-to-zone name mappings in AppleTalk
routers. ZIP is used primarily by AppleTalk routers. Other network nodes, however, use
ZIP services at startup to choose their zone. ZIP maintains a zone information table (ZIT)
in each router. ZITs are lists maintained by ZIP that map specific network numbers to one
or more zone names. Each ZIT contains a network number-to-zone name mapping for
every network in the internetwork.

Fig. 7 illustrates a basic ZIT.

Physical implementation:

The initial default hardware implementation for AppleTalk was a high-speed serial
protocol known as LocalTalk that used the Macintosh's built-in RS-422 ports at 230.4
kbit/s. LocalTalk used a splitter box in the RS-422 port to provide an upstream and
downstream cable from a single port. The system was slow by today's standards, but at
the time the additional cost and complexity of networking on PC machines was such that
it was common that Macs were the only networked machines in the office.

Other physical implementations were also available. One common replacement for
LocalTalk was PhoneNet, a 3rd party solution (from a company called Farallon) that also
used the RS-422 port and was indistinguishable from LocalTalk as far as Apple's
LocalTalk port drivers were concerned, but ran over two unused wires in existing phone
cabling. PhoneNet was considerably less expensive to install and maintain. Ethernet and
Token Ring were also supported, known as Ether Talk and Token Talk respectively.
Ether Talk in particular gradually became the dominant implementation method for
AppleTalk as Ethernet became generally popular in the PC industry throughout the
1990s. An Ethernet network could also run AppleTalk and TCP/IP simultaneously


One of the advantages of AppleTalk relates to the design of these connection boxes. The
boxes are designed so that the continuity of the trunk cable and the network is maintained
even if a device is disconnected from the network by unplugging it from the connection
box. The physical layout of an AppleTalk network can therefore be designed by locating
the connection boxes where desired without worrying if a device will be initially
connected to each one of the boxes. Additional devices can be added to the network at
any time simply by plugging them into the boxes.



The seminar project submitted to
Rajiv Gandhi Proudyogiki Vishwavidhyalaya, Bhopal
Towards partial fulfillment of
the Degree of
Bachelor of Engineering
Computer Science

Submitted to: Submitted by: