Some administrators assign network numbers based on the geography of the environment. A campus with five buildings might have four-digit cable range numbers. The first digit could relate to the building, the second to the floor within that building, and so on. Since there are over 64,000 network numbers available, the designer should be able to develop a numbering plan that is easy to understand, which will simplify troubleshooting.

As noted previously, the node number is a unique identifier of the device on the network. As a Layer 3 protocol, the network number is the routable portion of the address space—the node number is insignificant until the packet arrives on the local segment.

In addition to the network number and node number, there is a third significant parameter to the AppleTalk address: the socket number. Socket numbers in AppleTalk are very similar to socket numbers in TCP and UDP. They provide a specific interface on the node for communications. Therefore, the network-visible entries (NVEs) are identified by three addressing parameters: the 16-bit network number, the 8-bit node number, and the 8-bit socket number. Network-visible entries are network devices—a fancy term to describe a host, server, printer, or other element that might appear to the user.

AppleTalk Naming

One of the conveniences of AppleTalk is its use of names to identify resources within the network, which is not unlike the DNS and WINS (Windows Internet Naming Service) services in the IP world. However, unlike the two IP naming techniques, AppleTalk included naming in the initial protocol.

In fact, there are actually two names in the AppleTalk arena: the zone name and the resource name. Consider the zone name in the same manner you might think of a sub-domain name in the IP DNS structure. The main difference between the two naming schemes is that AppleTalk does not incorporate the idea of sub-domains and hierarchical structures. Alternatively, for those more familiar with Windows, AppleTalk is similar to the workgroup model. Resources are members of a grouping, but the grouping is only one of many equals—names in AppleTalk are flat. The DNS structure allows for names to traverse multiple layers—for example, the file server in Marketing in the fifth building in Dallas. AppleTalk designers are limited to using names such as Marketing or Marketing_Dallas for their structures.

From a design standpoint, zone names in AppleTalk are usually implemented with two parallel viewpoints in mind. The names need to be used by both the user community and the network administrators, and fortunately, in this instance, the solution will please both groups.

	AppleTalk zone names are case sensitive. Nonetheless, there are instances when connectivity may appear to function correctly even though the router has the incorrect form of the name. Such an installation will eventually experience some problem that will require resolution. Some designers use all lowercase names to avoid this issue.

Designers ideally will select zone names that reflect the departmental grouping related to each particular network, typically resulting in names like “Marketing” for the Marketing group and “Human Resources” for the Human Resources group. This naming scheme will help users locate the services provided by devices in each zone, and typically, these groups (departments, like Human Resources) will be physically located in the same general area. Such a scheme will also further assist administrators, because troubleshooting is simplified when the Marketing zone is no longer visible in the Chooser.

	The Chooser is the service-selection tool in the Macintosh OS. It lists all zones in the network. Once the user selects a zone, all of the resources in that zone will be presented, and the user can select a resource within the zone.

One minor downside to the AppleTalk zone-naming scheme is that it relies on broadcasts to announce the presence of each zone. These names are propagated throughout the entire network, so a large network might have hundreds of broadcasts every minute to cover all of the zones. In addition, each router summarizes all of the zones it knows about and advertises this information to the rest of the network, quickly adding to the load imposed by the process. Another minor downside is the somewhat limited number of zone names permitted in an AppleTalk network. The specification permits only 255 names, which could be a factor for the network designer to consider. In practice, designers should limit the number of zones to less than 100.

	Do not place all WAN networks into a single zone. While AppleTalk supports multiple cable ranges per zone, it is best to limit each zone to a single cable range. Designers may wish to span a select number of zones for some service clusters.

	Since the Chooser lists zone names in alphabetical order, most designers use a prefix of at least one “Z” when they want to move these zones to the bottom of the list. This tactic is very appropriate for WAN segments and other nonuser-related zones.

Machine names in AppleTalk are generally a more difficult design issue, and many times they are omitted from the network design layer. This omission is a double-edged sword, as a logical naming structure would greatly assist the inventory and troubleshooting processes. However, most Macintosh workstations are named for their users or another unique characteristic. For example, Apple names its routers for famous comedians and other figures rather than using the perhaps more boring names Router_A and Router_B.

The AppleTalk naming standard introduces a larger concept that has, as of yet, remained unaddressed in this text. The naming standard under any protocol should be an important consideration for all network designers. While Daffy and Mickey might be cute names for routers, they fail to communicate their function or location. At the opposite extreme, router RC7500-B-ORD might clearly refer to Cisco router type 7500 at the second location (location B) in Chicago, but the name doesn’t exactly roll off the tongue, so to speak. Another danger with the more formal naming convention is that it might not scale as initially intended. For example, how would the designer name the router in the fifth Chicago location? ORD probably should not refer to routers in all five locations. (ORD stands for Orchard Field, the original name for Chicago O’Hare International airport.)