A SEMINAR REPORT ON
1
Content
1. Intr Introd oduc ucti tion on
2. Design
3. Addre ddress ssin ing g
4. AppleT AppleTalk alk Netw Network ork Compo Componen nents ts
5. AppleT AppleTalk alk prot protoco ocoll and OSI OSI Model Model
6. Physic Physical al Implem Implement entati ation on
7. Advan dvanttage age
Introduction: 2
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
Design
3
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 bo xes.
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
