1

A SEMINAR REPORT ON

Content

1. Introduction

2. Design

3. Addressing

4. AppleTalk Network Components

5. AppleTalk protocol and OSI Model

6. Physical Implementation

7. Advantage

2

Introduction:

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

3

Design

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.

Addressing

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.

4

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.

5

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

Sockets

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.

6

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

Nodes

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.

Networks

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

7

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

numbers.

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

configurations.

8

Fig.3.2 An Extended Network can be assigned multiple network

numbers

Zones

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

9

AppleTalk Protocols and the OSI Model:

Fig. 5 AppleTalk Protocols and the OSI Model

10

Protocols:

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).

11

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.

12

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.

13

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.

14

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

15

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

exists.

16

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

17

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.

18

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

Advantages:

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.

19

MAHAKAL INSTITUTE OF TECHNOLGY UJJAIN

A SEMINAR REPORT

On

APPLE TALK

The seminar project submitted to

Rajiv Gandhi Proudyogiki Vishwavidhyalaya, Bhopal

Towards partial fulfillment of

the Degree of

Bachelor of Engineering

in

Computer Science

Submitted to: Submitted by:

20