The first layers of the OSI model include functions of the physical, data link, and network layers. It is important that we grasp what is going on at these layers in order to comprehend the various protocols that we often hear of. We will begin by examining the first level of interaction with the transmission medium itself - the physical layer and its specifications.

Today's popular LAN types delineate themselves by how they allow data to reach the transfer medium (coax, fiber optic, etc.). In effect they control aspects of both the physical layer of the OSI model and the data link layer. There are, however, specifications dealing with just the physical layer. These are important because they control movement of data between devices that often interact with the networks including PCs and modems.

This standard was developed by the Electronic Industries Association (EIA) to provide a reference for connecting Data Terminal Equipment (DTE) with Data Circuit-terminating Equipment or Data Communications Equipment (DCE). An example would be connecting a PC to a modem. This connection would take place over a standard type of connector and cable according to the RS-232 spec. The cabling type has changed through the years. The concepts have not.

The specification calls not only for certain cabling and connectors, it also details voltage levels on the cable and what these voltage levels represent.

RS-232 formerly described a 25 pin connector (typically a DB-25 connector) and the functions of data traveling down each pin. As this is a physical layer process, the data is simply electrical impulses. Figure 7.1 illustrates the arrangement of the pins and what they represent.

The cabling is to be no more than 50 feet in length and capable of supporting all 25 channels of impulses. The voltage levels include -3V to represent a binary 1 and +3V to represent a binary 0. The speed of the transmission is no more than 20 Kbps.

If two computers wish to communicate through modems, a standard procedure called "handshaking" takes place. Handshaking is simply a way to initiate data transmission.

PCs may communicate directly with one another without a modem if proximity allows. This is done by purchasing or making what is known as a "null modem cable". It simply alleviates the need for a modem by connecting receiving and sending pins on both devices together in an appropriate fashion. Typically this would involve cross-connecting pins 2 and 3, 4 and 5, and 6 and 8.

The RS-232 standard is very similar to the CCITT V.24 and V.28 speci-fications. It is also similar to ISO 2110.

The EIA enhanced the RS-232 standard in the mid-70s and created the RS-449 Specification. This spec describes a more resilient connection of devices with more intricate data transmission specifications and increased distance capabilities. The result was a faster but more costly and cumbersome system. A newer specification called EIA530 solves problems by allowing the RS-449 specs to be used with RS-232's common DB-25 connector.

The Consultative Committee on International Telegraphy and Telephony (CCITT) has its own set of physical layer specifications called the X series. The X series is numbered (i.e. X.25) and mainly deals with public data networks. The specs numbered 1 through 39 deal with all manner of data transmission techniques and devices. Those numbered 40 through 199 involve network activities including structure and transmission methods. CCITT's V series specifications deal with communication interfaces and speeds.

The telecommunication industry also uses its own specifications. T-1 is a designation of a specific type of transmission line capable of carrying data at 1.544 Mbps in the US and 2.048 Mbps in Europe. The T-1 can be dedicated to carry only digital data or it can carry 24 voice channels that have been digitized. The T-3 lines can carry data at 45.54 Mbps. It is the equivalent of many T-1 links. It, too, may be used for all-digital data or for digitized voice lines.

The physical layer takes care of getting data on the wire and off of it again. At the data link layer, we must take this incoming stream of data from higher or lower layers and create frames from it. Handling the data requires a solid protocol that can perform better error checking and more efficient throughputs.

The first to really address these needs was the Synchronous Data Link Control (SDLC) protocol from IBM. Developed for their Systems Network Architecture (SNA) systems, IBM created what is known as a bit-oriented protocol. This meant that specific bits themselves had meaning. Information wasn't formed just on the byte level.

SDLC supported the computer structure of the 70s with provisions for host systems. Primary devices as well as secondaries were supported. Primary devices are those that control a communications channel to themselves or other devices. The other devices are called secondaries. (See Chapter 2 - "Polling".) Later, devices were able to assume the role of either primary or secondary depending on the need. Functionality beyond this was added by the standards-setting organization who adapted and renamed SDLC. The ISO termed it as High level Data Link Control (HDLC), ANSI called it Advanced Data Communication Control Procedures (ADCCP) and CCITT later termed it Link Access Procedure - B (LAPB).

A SDLC frame consists of several fields that comprise a command that is sent to secondaries. The secondaries use their own unique frame to respond to the commands. There are three different types of command frames.

The first field in the SDLC frame is the flag field. It carries a special arrangement of bits that ordinarily would not occur elsewhere within the frame. In order to make sure the flag field is unique, SDLC uses "bit stuffing", a method by which any consecutive group of more than five 1s are broken up by a 0. The receiver recognizes this and removes the 0. The same flag is used to signal the end of a frame.

The address field contains the unique address of a secondary that the SDLC frame is coming from or going to.

The control field follows with one or two bytes worth of information. It denotes whether the frame is a supervisory, a data or an unnumbered frame. Supervisory frames are mainly used to allow or disallow transmission between a secondary and primary. The control frame begins with a 10 pattern that signifies that the frame will be a supervisory one. As a response to an information frame, this field may communicate that a frame has been rejected, that a secondary is ready to receive, that a primary is polling a secondary, or that a secondary is not able to accept any more frames.

The 10 pattern is followed by a P/F (Poll/Final) bit. This bit is used to control acknowledgments. A sender may send multiple frames without requesting an acknowledgment. When it is ready to check to see of all frames have been received okay, it sets the P/F bit to 1.

Information frames' control field begins with a 0. This is followed by a send sequence number, a receive sequence number and the P/F bit. The send sequence number is the number of the frame that a sender will send next. The receive sequence number is the number of the packet that the sender has just received. If there is a problem then the receive sequence number is not changed and the packet with the error can be resent. After the P/F bit, an information field follows.

The Unnumbered frames are used to create and destroy connections between senders and receivers. The control field for an unnumbered frame begins with a 11. The frame itself contains no sequence numbers.

Each SDLC frame contains a Cyclical Redundancy Check field (CRC). This special value is created from the contents of the frame and is used in error detection. The sender places the frame contents through an equation and generates a CRC. It then sends the CRC with the frame. The receiver runs each frame through the same equation. The CRC that it comes up with must match the one in the frame, or the frame is discarded. SDLC uses a 16 bit CRC.

HDLC uses a 32 bit CRC and is very similar to SDLC. As a close cousin, its functions are virtually identical to SDLC with the exception of a few minor differences. The importance of HDLC lies in its three transfer modes that are borrowed for yet another SDLC cousin - LAPB. HDLC's transfer modes are as follows:

LAPB is very similar to SDLC and HDLC. LAPB operates only in an Asynchronous Balanced Mode fashion.

Ethernet was originally conceived of in the early 70s by Xerox designers. Its successful use in the Xerox Alto PC led two a consortium of three companies who wanted to be able to interlink various minicomputers. The companies were Digital Equipment Company (DEC), Intel Corporation and Xerox Corporation. Intel took on the task of providing the chips for NICs. Xerox wrote the software to operate it and DEC stepped in to make use of the technology for its minicomputers. The result was a high-speed connection that provided an alternative to IBM's networking architectures.

In 1980 these companies released a specification for Ethernet Version 1. This version was followed by a second version in 1982. These early versions comprise the standard we should refer to as "Ethernet" today. However, they are so close to another standard put forth by the 802.3 Committee of IEEE, that these standards are often confused and the terminology is used interchangeably. There is a difference and we will point out these in this chapter.

Version 1 Ethernet's specifications called for a contention access method to the physical cabling. This meant that machines had to monitor the LAN for an opportunity to use the wire if necessary. This technology is called Carrier Sense Multiple Access/Collision Detection or CSMA/CD. We have discussed this concept in a previous chapter.

The physical cabling was and is known as thick coaxial cable (.405 inches in diameter and fairly rigid). It supported a standard throughput of 10 Mbps and the maximum length of cable allowed between nodes of about 500 meters (about 1500 feet).

Ethernet's frame size and content was defined by the Version 1 standard as well. This early standard has become known as the DIX Standard. DIX is an acronym for DEC, Intel and Xerox. This frame size may be between 72 and 1526 bytes in length. The spec also called for Manchester encoding be used for the digital signal. In case you don't remember how Manchester encoding works, take a quick glance back at Chapter 5.

Soon after Ethernet Version 2 was released in 1982, the IEEE 802 Committee issued its own standard for Ethernet-type networks. Not surprisingly, the 802 spec was startlingly similar to Ethernet 2. Let's compare the frames of Ethernet and 802.3 so you can see the differences as well as the similarities.

The preamble for the Ethernet frame is 8 bytes (technically called octets) in length. It is actually the repetitive pattern of 10101010 for seven bytes followed by one byte with a 10101011 pattern. The preamble for 802.3 is identical except the final byte is called the "Start Frame Delimiter" or SFD.

The destination address follows for both frame types. This field is 6 bytes in length. It is followed by a source address field that is also six bytes in length.

In the Ethernet frame, the next field is the type field that specifies the software protocol (TCP/IP, NetWare) with which the Ethernet frame is being used. This field is typically called the Ethertype field.

In the 802.3 frame, the type field was replaced with a length field that provides the length in octets of the data field to follow.

The data field contains information bound for the higher layers in the OSI model. This structure can vary in length from 46 bytes to 1500 bytes. In IEEE framework, the data is considered to be a data unit from another layer. If that data unit is less than 46 bytes, it is padded to bring it to that minimum length. Therefore a pad field may or may not exist.

Finally, both frame types have a 32-bit (8 byte) CRC check field that is created out of information from other fields. In the Ethernet frame, CRC is computed from the address, type and data fields. In 802.3, the CRC is created from the address, length, data and pad fields.

It should be plainly evident that in spite of striking similarities between the two frame types, there are a couple of crucial differences. First, Ethernet has no length field and 802.3 has no type field. Upper layers that might use this information would obviously get confused. Second, Ethernet provides no padding to make sure its data field is at least 46 bytes in length. This task would have to be performed by another layer. There is one other difference worth noting. The oldest version of Ethernet does not use a special signal known as SQE (Signal Quality Error) so using it with more modern Ethernet-type systems presents a problem.

Since the 802.3 frame is the most commonly used today, we'll limit our discussion to it and the specifications surrounding its use. And for the sake of keeping our vernacular constant with what we experience today, we'll refer to the 802.3 frame generically as "Ethernet".

Ethernet as a protocol (packet type), deals only with the Physical and Data Link layers of the OSI model. The layers above these are involved with software protocols such as NetWare's IPX and SPX packet types or TCP/IP packets. In transmitting TCP/IP on an Ethernet LANs, the TCP/IP information is placed in the data field of the Ethernet frame. When the frame is received, the Ethernet stuff is stripped away leaving TCP/IP information for higher layers.

There is another crucial difference between Ethernet specs and 802.3 specs. Ethernet only specifies one type of physical medium - thick coax. The 802.3 standards provide for several physical media including coax, twisted pair and fiber. Each of these standards has been given a unique designation by the 802.3 subcommittee. An example of one of these designations is "10BASE5". This specifies that the LAN throughput is 10 Mbps (10). It is a baseband network, meaning only digital data is transmitted on it (BASE). Finally, the maximum length of medium acceptable between any two nodes is about 500 meters (5). Here is a breakdown of what designations there are and what they entail.

Ethernet offers distinct advantages over other popular LAN types. It is cost effective and offers very high throughput for traffic patterns that are variable and not always heavy. With light traffic loads, Ethernet performs splendidly.

ARCnet could be called the protocol that would not die. That's because although there are newer and faster networking solutions, ARCnet has a loyal following due to unrivaled interoperability among vendors and budget-oriented pricing.

The Attached Computer Resources network (ARCnet) was created by a company called Datapoint in the late 70s. Later on this technology was licensed out to SMC (Standard Microsystems Corporation) who is still manufacturing ARCnet products today.

The interesting thing about ARCnet is that its speed was based on the fastest speeds of disk drive subsystems in the late 70s. Who would have thought at that time we'd ever need more than 2.5 Mbps throughput (about 7.5 Mbps slower than Ethernet)? Obviously this was the same line of reasoning behind our early PCs. Who would have ever thought we'd need more than 640K memory, right?

ARCnet typically uses a star topology, though it can use a bus, and supports coax, TP or fiber. ARCnet can actually combine topologies as in the case where nodes are hooked up in a bus topology radiating from a central hub device.

In order to accommodate all of the different types of mediums out there, ARCnet vendors have created just about every kind of connector you can imagine. This includes coax to TP converters as well as coax and fiber converters.

Let's look at what the ARCnet packet types look like, then we'll mention some of the limitations of this popular type of LAN.

ARCnet uses several types of packets each with a particular function. In practice, ARCnet works very much like a token ring system in that a special packet like the token visits each node giving it permission to transmit. Before a node transmits data to another node, it queries the intended receiver to see if that node can in fact receive a frame. With a positive acknowledgment (ACK) from the receiver, the sending node will began transferring data. Each data packet is acknowledged. After the data transfer is finished, the sender sends the token-like packet to the next node in line.

The "token" in ARCnet is called an ITT frame. ITT stands for Invitation To Transmit. ARCnet nodes each have a number assigned to them between 1 and 255. The ITT always travels sequentially from node to node. Therefore when node 5 is finished, node 6 gets the ITT, or whichever active node that is closest to node 5 in sequential numbering. ARCnet packets begin with what is known as an "alert burst" composed of six consecutive 1 bits. The ITT has an alert burst followed by an End of Transmission marker (EOT) and two Destination IDentifiers (DIDs) which comprise an ARCnet node identification number.

If a node needs to transmit, it must wait for the ITT. Once received the sending node transmits a special frame called an FBE (Free Buffer Enquiry) to its data's destination node. The FBE is designed to find out whether or not the destination node has enough free memory to accommodate a packet. This packet begins with an alert burst followed by an ENQuiry field containing an ASCII request to see if buffer space is available. The ENQ is followed once again with two DID fields. The destination node then responds to the FBE by sending either an acknowledgment (ACK) or a negative acknowledgment (NAK) to the sending station. If a NAK is sent then the transfer cannot take place. If a ACK is received than data is transmitted to the destination via the data packets. In the ARCnet structure, each node has a limited time in which to transmit once it has received the ITT.

The ACK and NAK packets simply contain an alert burst followed by the ASCII code for a positive or negative acknowledgment. Note that there is no source or destination information contained in the ACK or NAK. Since only one machine has been given permission to transmit, it is assumed that the ACK or NAK is to be used by the one node.

The data packet is called a PAC (short for packet). It contains an alert burst followed by 1 byte Start of Header (SOH) field. Next is the 1 byte Source IDentification field (SID) and two bytes of DID. This is followed by 1 to 2 byte count field that indicates the size of the data field to follow.

The data field of an ARCnet packet can be from 1 to 508 bytes in length. This is much smaller than Ethernet's 1500 or so bytes of data. This small packet size is advantageous if a packet has to be re-sent due to an error. It's a little faster to re-send a small packet than a larger one. However, smaller packets carry less data at one time. This means more ARCnet packets than Ethernet packets would be required to move most data. Plus, ARCnet requires an ACK to be received between each packet. This overhead adds up to slow throughput for ARCnet.

The data field is followed by two Cyclical Redundancy Check (CRC) fields used to determine the validity of the data at the destination node.

As a choice for LANs, ARCnet offers advantages in its cost efficiency and its ease of use. However, its speed has crippled it in the marketplace. Attempts have been made to beef up ARCnet. In 1989, ARCnet Plus was announced. This system uses ARCnet protocols at 20 Mbps, currently faster than Ethernet or token ring. Unfortunately, ARCnet Plus has not really gotten off the ground.

Thomas Conrad modified the ARCnet protocols and created the Thomas Conrad Network System (TCNS). This proprietary offering zips along at 100 Mbps. So far the system has proven functional on coax, fiber and shielded twisted pair cabling. The cost is still formidable yet, but this network offering was and is quite an achievement.

ARCnet LANs are quite limited in size. There is a finite number to the nodes that can participate in an ARCnet LAN, and that number is 255. This is limiting for larger organizations, but most large operations go with Ethernet or token ring anyway. For a smaller shop, this is manageable.

There are a couple of different hubs that can be used with ARCnet, passive and active. Passive hubs simply split signals and limit nodes to about 100 feet out from the hub device. Active hubs regenerate the signals so that nodes may be stretched up to 2000 feet from the hub.

ARCnet is considered to be deterministic in its function. That is, its throughput is somewhat predictable under load conditions. There are some cases where ARCnet LANs outperform Ethernet LANs in high traffic conditions.

There is an interesting event that occurs in ARCnet LANs. Since every node is numbered, there has to be a way to maintain the orderly flow of information from one node to the next. The ITT helps assure that everyone gets a chance to transmit, but how does the token know where to go once it is finished at a particular node?

Each node is responsible for keeping up with the node ID for its downstream neighbor (sequentially). This information is called the NID for Next IDentification. Now this works out great until a new node enters the system or a current node leaves (as in gets turned off). These conditions trigger what is known as a reconfiguration event or a "recon". During a recon, a signal is sent to all nodes instructing them to drop what they are doing and reset there NID to match their own SID (they become their own Next ID). Next, the highest numbered node begins incrementing its Next ID. When it reaches 255, the NID starts at 1 and continues to increment from there. Each time the node increments its Next ID, it sends out a packet with the NID as the DID number. Eventually, it gets an ACK from the next highest node indicating that the NID is now correct. Next the original node sends a token to the node matching its newly set NID and the other node can now go about the same process to find its downstream neighbor.

Although it would seem that the recon event would create a great deal of time overhead, it actually requires very little. Recon events occur only when necessary and only require a few seconds. In smaller systems, the event may be barely recognizable. One method advocated for getting around frequent recons during a workday, is to make sure all nodes are turned on together in the morning and left active all day. Turning machines on and off during the day should not be encouraged not only due to recons, but to strain that powering up a PC over and over again can create on the machine's internal circuitry.

Token ring systems are continuing to grow in popularity. There are probably numerous reasons why. Token ring systems are fault tolerant and deterministic. They are far superior to Ethernet in handling high traffic environments. IBM markets and continues to support token ring. The IEEE has adopted a standard for token ring systems. All these factors play in.

When IEEE 802.5 committee started working on specifications for a token passing system utilizing a ring topology, it became evident that IBM had already invested quite a bit into researching and developing the system. Consequently, the 802.5 standards are very close to IBM's token ring, though there are some differences.

IBM's Token Ring Network utilizes what appears to be a star topology (because of a central hub-like device) but is actually a ring topology. The central device is known as a MultiStation Access Unit (MAU or MSAU). The cabling may range from level 3 UTP to fiber optic. The choice of cabling will impact how many nodes may safely participate on a given ring. For instance, a token ring LAN using data grade IBM coax may support a little better than 250 nodes, while a system using UTP (level 3) may only support about 70.

Within the MAU, a ring is formed from connected nodes by relays which may also bypass a node and take it out of the ring. A ring is necessary because data flows in only one direction from node to node. Each node is responsible for taking the data transmitted to it from its upstream neighbor and passing it on to the downstream neighbor. The data travelling through a token ring card is simply repeated unless the card happens to be the one sitting in the destination machine. In this case, the data is copied into memory, then it is re-sent right on out along the ring again. Eventually the data gets back around to the source that absorbs the data off of the ring and checks to see if the message was acknowledged by the intended receiver. The ring makes this scheme possible, and, incidentally, even MAUs can be hooked together into a ring.

The 802.5 specs call for special packets in token ring systems to either control the ring's operation on the media access control (MAC) layer or send data from the logical link control (LLC) layer on up to other OSI layers. Let's take a look at what is involved with these packet types.

The token seems to be nothing more than just a three byte packet with simple function. However, each byte of the token contains important information. The starting delimiter contains non-data symbols as well as binary zeroes creating a unique pattern that in no way can be mistaken for data. The second byte, known as the access control field, contains four components - a priority mode, a token bit, a monitor count and a priority reservation.

The priority mode is 3 bits that represent priorities. A 111 combination represents the highest priority while 000 represents the lowest. Each node on the ring must be assigned a priority equal to or higher than the priority of the token before the machine will be allowed to transmit. A token bit follows indicating whether the frame is a token frame or a data frame. The token is represented by a 0 in this bit, anything else by 1.

A monitor count bit follows. If the token or data has passed by the active monitor (a node that monitors the ring), this bit is set to one. If the active monitor sees a frame with a 1 here, it assumes that for some reason the frame was not removed from the ring and then does so. Then it resets the ring and sends out another token.

The next three bits are called priority reservation bits. They allow a node to request a token of a higher priority thus only allowing certain other stations to participate in the transmissions if those other nodes have the same or higher priority.

Finally, the last byte of the token is the ending delimiter that contains non-data information that violates the Differential Manchester encoding scheme (Chapter 5) used for token ring. Plus the byte contains binary 1s. It also contains a bit that is used to signal if the frame has an error in it. This bit is flipped if the receiver's CRC doesn't match the sender's CRC.

The token ring data frame (802.5) begins with a starting delimiter, once again containing binary 0s and violations of the Differential Manchester Coding. This is followed by the access control byte containing priority information just like the token. In this case, the fourth bit is a binary 1 differentiating the data frame from a token frame.

The Frame Control byte then follows. It contains an indicator that details whether the frame is carrying data or command information. If data is being carried, then it is utilized by the LLC layer on the receiving machine. If a command is received, it executes on the MAC layer. Commands deal with setting up a ring and maintaining it with its active monitor machine.

Next the destination and source addresses follow. These addresses can be burned into the actual token ring card, or they may be assigned by a network administrator.

If IBM token ring is being used, then a routing information field is next, otherwise the information field follows with a LLC PDU contained to be passed up to higher layers on the receiving machine. The length of this field is variable because each machine has a set amount of time to broadcast data and when it must stop, the information field is complete.

The next field is the frame check sequence field. Just like other protocols, it contains a CRC created from other fields within the frame (control, destination and source addresses, and information fields). Just like the other protocols, the FCS is computed at the sender and receiver. They have to match or there is an error in the packet.

The ending delimiter is then next followed by the frame status byte. The frame status byte is composed of several bits that include reserved bits plus two types of other bits known as Address Recognized (AR) and Frame Copied (FC) bits. There are two bits of each of these types. All of these bits are set to 0 when transmitted. The destination node sets the AR bits to 1 when a packet is received and sets the FC bits to 1 also when the frame is copied into the receiving station's memory. If the frame gets back to the sender without the AR bits being flipped, then it knows the destination is not actively on the ring at that time. If only the AR bits are changed, but not the FC bits, then some error caused the receiver not to copy the data. It may have been bad, or resources might have been too limited. The sender can then attempt to re-send the packet.

Please note that Novell has used the term "Address Resolution" rather than "Address Recognition" for the AR bits.

The abort packet is sent to interrupt the normal transfer of tokens and data around the ring in cases of errors or other problems.

Token ring systems are very complex possessing advanced fault tolerance capabilities. For instance, if a card senses that something is wrong on the ring, it begins a process known as "beaconing". Beaconing starts when a node, after detecting a problem on the ring such as a break, sends out a special packet. The packet helps to isolate the problem area and causes the ring to attempt to work around the problem.

Right now, one of the major hindrances to token ring is its price. A token ring card can cost double what an Ethernet card does. And for light sporadic traffic, Ethernet can outshine token ring. However, for large LANs with a high degree of traffic, token ring may still be the best choice.

FDDI, in a nutshell, is like very fast token ring on fiber. Its throughput speed is 100 Mbps, and compared to standard token ring and Ethernet, that is fast. FDDI was designed for a couple of main reasons. First, it allows mainframe and minicomputers networks to move data at a much higher speed, or it can serve as a high speed backbone for several LANs. Second, highly processor and data intensive applications such as Computer-Aided Design (CAD) systems needed to be able to move and retrieve huge volumes of data in a rapid fashion.

FDDI shares many commonalties with token ring. Its layout is similar. It uses a token. It is similarly fault-tolerant. It can be easily managed, and FDDI can be easily integrated with token ring.

As far a frame construction, FDDI is very similar to token ring in that there are token frames and data frames. Here is a breakdown:

Each node in a FDDI network has built-in clock that allows data signals to be correctly interpreted. The preamble contains a group of sixteen 1s to synchronize the receiving station's clock.

The starting delimiter is next followed by a frame control field that provides information such as whether the transmission is synchronous or asynchronous, whether a 16-bit or 48-bit address will be used, and whether the frame is used on the receiver's MAC layer or passed up to the LLC layer.

The destination and source addresses follow. They are typical addresses. If the first bit of the destination address is a 1 then the message is designed to go to every node on the ring. It is a "broadcast" message.

The data field follows with a frame check status field behind. The FCS carries a 32-bit CRC created from the frame control, address and information fields.

The end delimiter signifies whether or not the frame was a token or data frame. Finally the frame status field works just like token ring's. It signifies if a frame has been received and copied into the memory of the intended receiver.

The FDDI token has only 4 fields. It has a preamble, start delimiter, a frame control field and an end delimiter. The end delimiter contains information signifying that the frame is a token, not a data frame.

FDDI is replete with fault-tolerance offering a dual counter-rotating ring for redundancy. If the primary ring fails, the secondary ring will allow nodes to continue to operate. Machines on the ring are classified in A or B groupings. A stations are those that make use of a second ring for fault-tolerance. B stations are only on the primary ring. Thus, if the primary ring fails, all Class B nodes would be inoperative.

According to specification, FDDI rings are not supposed to have over 1000 nodes or extend beyond 200 kilometers in circumference. About every 2 km or so, a repeater is needed to boost the signal along the fiber optic cabling. Fortunately, fiber optic cable is not susceptible to EMI.

When data is not traveling around the FDDI ring, a token circulates, so there is always minimal traffic. In practice, each node sees a token and absorbs it, hanging on to it if there is a need to transmit data. Once a frame of data is transmitted, the token is then released. If that combination reaches another FDDI node, the data frame is just copied right through the node, but the token on the end signals the node that it can append any data it needs to as well. Eventually all of the data frames get reabsorbed by the sending nodes and the token is all that is left, constantly circulating on the ring.

FDDI does not use Manchester data coding like Ethernet. It does not even use Differential Manchester encoding. It uses what is called Non-return to zero encoding (NRZ-I to be precise). Coding of data on the ring is done by symbols. A digital character is changed into a FDDI symbol. For FDDI, this is typically represented by five bits. This pattern is put into NRZ-I digital coding to be moved around the ring. This encoding method was chosen because of the amount of data it can carry. In order to achieve a 100 Mbps throughput in FDDI, a 125 MHz signal is needed.

As you probably noticed, FDDI supports both synchronous and asynchronous transfers of data. In fact, it allocates bandwidth for both types of transmissions. Most of the bandwidth is reserved for the typical synchronous communications, but in the event two nodes decided to talk asynchronously, they may do so. The asynchronous bandwidth is distributed based on priorities. Two nodes could take complete control of the async bandwidth for an extended period if necessary. This state is called "restricted token mode". Here the two nodes would carry on a conversation using all the async bandwidth until one of them issued a non-restricted token thus freeing up the bandwidth for other nodes desiring async communications.

FDDI, like token ring, uses beaconing to track down errors on the ring (like a break). Once the location of the break has been established the ring attempts to reconfigure itself around the problem.

FDDI with its many features and speed will continue to grow in its acceptance as a practical backbone for most LANs. Mass production has decreased the expense of getting into FDDI. Some vendors are selling their FDDI wares at half the price they were a year ago. These trends are favorable for what is a costly system to implement. One day, FDDI may be commonplace at the desktop. The main companies supporting FDDI are Intel, Codenoll, Cisco Systems, Fibronics, Interphase, Rockwell/CMC, Advanced Micro Devices, National Semiconductor and IBM.

LocalTalk is the built-in networking systems that comes on every Apple Macintosh. It isn't heavy duty and is not designed to support a massive LAN. In fact, the LocalTalk systems are limited to 32 nodes and operate at a blinding speed of 232 Kbps. What's great is that you get this workgroup type capability on every Mac, built into the package. That's the sort of nice feature that has made Macintosh a household word.

By specification, your Mac LAN with LocalTalk can have segments up to 300 meters (about 900 feet). The encoding method for the data is called biphase encoding. The system uses a bus topology, so there is a contention system for use of the wire.

Nodes on the LocalTalk LAN select an address during power-up and check out on the LAN to see if it conflicts with anyone else's. Machines are distinguished as being servers or clients. Servers are given special allowances due to their capacity to be busy.

Let's take a look at what goes into a LocalTalk frame, then we'll discuss more specifics about LocalTalk's operations. The protocol that LocalTalk uses is known as LocalTalk's Link Access Protocol or LLAP.

The preamble is first. It contains a couple of bytes that include the 7E (hexadecimal) flags indicating a start of frame.

One byte of destination node address follows containing an address that represents a number 1 to 127 for clients and 128-254 for servers. The destination address of 255 in a packet means that the message is sent to every node on the LAN (a broadcast). A source address follows. It too is a number from 1 to 254.

A type field is next denoting whether the frame is a data frame or a command frame. There are four kinds of command frames. These include acknowledgments (ACKs), free buffer enquiries, requests to send data (RTSs) and clear to send messages (CTSs). These packet types will be detailed a little later.

The data length field precedes the data field. The data length field describes exactly what its name implies. Interestingly enough, only the low-order bits of these two bytes are used in declaring the length. The high-order bits are reserved for use in higher layers of the OSI model.

The data field can be between 2 and 600 bytes of data. In order to prevent widespread chaos that would occur if stations mistook patterns of bits in certain fields including the data field as a start frame delimiter, LocalTalk uses a technology called "bit stuffing". Bit stuffing is accomplished by preventing any more than five consecutive 1s from occurring together. A zero is inserted after five consecutive 1s to ensure uniqueness from the starting and ending trailer fields.

A frame check sequence follows with a 16-bit CRC created from all fields but the starting and ending trailer fields. The trailer flag field then follows containing the same 7E hexadecimal value as the preamble. Lastly, the abort field signals the end of the frame with a series of one bits.

LocalTalk is very similar to IEEE 802.3 Ethernet type specifications in that the Apple system utilizes CSMA technology. If you remember, this means that each device must monitor the wire to make sure it is clear before attempting to send anything. By LocalTalk rules, there must be a 200 microsecond delay between packets. The nodes wishing to access the LAN must listen for and hear at least 400 microseconds of silence before attempting to transmit (start a new dialogue).

Instead of just sending data out there like Ethernet, LocalTalk sends a Request To Send (RTS) packet to the receiver. The receiver must then send a Clear To Send (CTS) signal back. If the CTS is not received, then the sending station will assume there was a collision and will back off and wait a while before attempting again.

Unlike Ethernet, LocalTalk uses no jamming signal. It simply attempts to avoid collisions by sending out RTSs and CTSs. For this reason, LocalTalk is referred to as a CSMA/CA technology with CA standing for Collision Avoidance. By contrast, Ethernet is referred to as a CSMA/CD technology with CD standing for Collision Detection.

LocalTalk uses shielded twisted pair cabling and RS-422 connectors. Its communications are very slow compared with other LAN systems, but its shipped-with-the-product convenience is very nice. As a mechanism for linking large number of nodes, LocalTalk is impractical with a limitation of 32 nodes. However, it is a quick and easy choice for small workgroups. The software network operating system used with LocalTalk networks is called AppleTalk. It will be discussed in the next chapter.

The systems discussed in this chapter have all been ones that function on the physical and data link layers of the OSI model. This is only part of the process of allowing us to network applications. There must be a mechanism for moving data from the lower layers to the higher layers of the model. That responsibility falls to the network operating system protocols discussed at length in the next chapter.